后端架构

架构目标

后端围绕“设备接入、业务管理、数据处理、规则联动、消息通知、视频能力”分层组织。模块之间通过接口、消息和缓存协同，既支持快速部署，也便于后续按领域拆分和扩展。

分层结构

主要模块职责

模块域	职责	典型场景
控制器层	暴露 REST 接口，完成参数校验、权限校验和响应封装	前端查询设备、产品、规则、告警
业务服务层	承接领域逻辑，处理设备、产品、物模型、租户和权限	设备创建、分配、禁用、指令下发
协议层	接入 MQTT、CoAP、HTTP、Modbus、SIP、JT808 等协议	设备上报、命令下发、网关采集
消息层	处理队列、桥接、异步任务和设备事件	削峰、转发、规则触发
规则引擎	根据设备数据、定时任务和告警状态触发动作	场景联动、告警恢复、消息重发
通知模块	统一通知模板、渠道和发送记录	短信、邮件、企微、钉钉、系统消息
视频模块	对接 ZLMediaKit，处理拉流、播放、录制和回调	视频监控、语音对讲、录像管理

设备业务链路

关键设计点

• 权限隔离：设备、产品、机构、角色和菜单权限需要统一校验，避免跨租户访问。
• 协议扩展：新增协议时优先复用协议解析、消息模型、Topic 规范和设备认证流程。
• 异步处理：设备上报、规则触发、通知发送和视频回调适合异步化，减少接口阻塞。
• 缓存策略：设备状态、物模型、Modbus 配置、OTA 任务等热点数据应使用缓存减少数据库压力。
• 可观测性：业务日志、协议日志、规则执行日志和通知发送日志应具备可追踪性。

二次开发建议

1. 新增设备能力时，先确认产品物模型和 Topic/协议约定，再实现控制器和服务逻辑。
2. 新增协议时，先完成解析和消息转换，再接入规则引擎和数据存储。
3. 新增通知渠道时，统一走通知模板、发送记录和失败重试机制。
4. 调整权限或租户逻辑时，同步验证列表、详情、批量操作和导出接口。