第二章：系统总体架构设计

好，咱们直接进入正题。这一章讲的是整个系统的骨架——端-边-云三层架构。说白了，就是你的灯泡、网关和服务器之间怎么分工、怎么配合。

我在做第一个智能照明项目时，犯过一个低级错误：把所有逻辑都塞到云端。结果呢？网络一断，灯就变砖了。从那以后，我对架构设计就特别较真。

2.1 端-边-云三层架构

先看整体结构。我习惯把系统拆成三层：

• 端（Device）：就是你的智能灯泡、开关、传感器。资源受限，RAM可能只有几十KB。
• 边（Edge）：通常是网关或本地控制器。负责协议转换、本地策略执行。
• 云（Cloud）：后端服务器。做设备管理、OTA固件存储、数据分析。

你想想看，为什么非要三层？直接端到云不行吗？

嗯，这里要注意。如果家里有几十个灯，每个灯都直接连云端，那网关压力会很大。而且，本地场景联动（比如“开门亮灯”）如果走云端，延迟会高到让你崩溃。

我在项目中遇到过一种情况：客户要求所有灯必须支持离线场景。那怎么办？只能把场景逻辑下沉到边缘网关。云端只负责下发场景配置，网关本地执行。这个思路，后来成了我们团队的标配。

2.2 通信协议选型

协议选型是个老生常谈的问题。我直接给结论，再解释为什么。

协议	适用场景	我的评价
MQTT	端到云、端到边	首选，轻量、支持QoS、双向通信
CoAP	资源极度受限的设备	可用，但生态不如MQTT成熟
HTTP	云端API、配置下发	适合管理面，不适合实时控制

MQTT 是我最推荐的。为什么？

• 它基于发布/订阅模式，天然适合一对多通信。
• 支持三个QoS等级。OTA升级这种关键操作，用QoS 1或2保证送达。
• 心跳机制可以检测设备离线，这对固件升级很重要——你总不想给一个离线设备发升级包吧？

CoAP 呢？它基于UDP，更轻量。但我在实际项目中踩过坑：CoAP的重传机制在弱网环境下不太稳定。如果你做的是电池供电的传感器，可以考虑；但照明设备通常有持续供电，没必要省那点流量。

HTTP 我只用在云端管理接口。比如设备注册、固件版本查询。实时控制用HTTP？别闹了，握手开销太大。

2.3 系统数据流设计

数据流设计，说白了就是数据怎么在端-边-云之间流动。我把它分成三个方向：

2.3.1 上行数据流（设备 → 云端）

设备上报的数据包括：

• 状态数据：开关状态、亮度、色温。周期性上报，比如每5分钟一次。
• 事件数据：设备上线、离线、故障。即时上报。
• OTA相关数据：当前固件版本、升级进度、升级结果。

我曾经遇到一个问题：设备上报太频繁，把MQTT broker搞挂了。后来加了限流策略——状态数据合并上报，事件数据单独走高优先级Topic。

2.3.2 下行数据流（云端 → 设备）

云端下发的指令包括：

• 控制指令：开灯、关灯、调亮度。要求低延迟。
• 配置指令：场景配置、定时任务。可以批量下发。
• OTA指令：升级通知、固件包分片下发。

这里有个坑：OTA升级时，固件包通常很大（几百KB到几MB）。如果直接通过MQTT发，会阻塞其他消息。我的做法是：MQTT只发升级通知，固件包通过HTTP分片下载。

2.3.3 边云数据流（边缘网关 ↔ 云端）

边缘网关是中间人。它需要：

• 聚合设备数据，批量上报云端。
• 缓存云端下发的配置，离线时也能执行。
• 转发OTA固件包给设备。

我记得有个项目，网关内存只有64MB。如果同时给50个灯升级，固件包缓存会撑爆。后来我们改成流式转发——网关收到一个分片，立即转发给设备，不缓存完整包。

2.4 数据流示例

看一个完整的OTA升级数据流：

1. 设备上线 → 上报当前固件版本（MQTT）
2. 云端比对版本 → 发现新固件（HTTP API）
3. 云端下发升级通知（MQTT）
4. 设备确认 → 进入升级模式（MQTT）
5. 设备通过HTTP下载固件包（分片）
6. 设备校验固件 → 写入Flash
7. 设备重启 → 上报新版本（MQTT）
8. 云端更新设备状态（数据库）

这个流程看起来简单，但每一步都有坑。比如第5步，如果下载到一半网络断了怎么办？我一般会设计断点续传——记录已下载的分片序号，重连后继续下载。

2.5 小结

这一章的内容，说白了就是三件事：

1. 架构选型：端-边-云三层，各司其职。
2. 协议选型：MQTT为主，HTTP为辅，CoAP看情况。
3. 数据流设计：上行、下行、边云，三条路径都要考虑异常。

下一章，我会讲具体的硬件选型和通信模块设计。到时候咱们聊聊ESP32、BLE Mesh和Zigbee怎么选。嗯，那也是个有意思的话题。