端云协同架构总览：端侧与云侧的分工、典型拓扑结构、通信协议选型
好，咱们进入第二章。上一章我们聊了OTA升级为什么重要，以及整个课程要解决什么问题。这一章，我想把镜头拉远一点，先看看端云协同这套架构到底长什么样。
说白了，端云协同就是把升级这件事拆成两半——云侧负责管理、分发、监控，端侧负责执行、反馈、容错。两边各司其职，但又紧密配合。我做了这么多年IoT，见过太多团队把升级搞砸，原因往往不是技术不行，而是分工没搞清楚。
一、端侧与云侧的分工：谁该干什么？
先说说我的理解。云侧的核心职责是策略与调度，端侧的核心职责是执行与安全。听起来简单，但实际落地时边界经常模糊。
云侧负责什么？
- 固件管理：版本存储、差分包生成、灰度策略配置。我记得有一次客户要求同一个设备在不同区域升级不同版本，云侧的策略引擎就派上了大用场。
- 任务调度：什么时候升级、升级多少台、要不要分批。我个人习惯把调度逻辑放在云侧，因为端侧资源有限，跑复杂策略太吃力。
- 状态监控：收集升级进度、成功率、失败原因。嗯，这里要注意，监控数据量可能很大，需要设计好采样和上报策略。
- 安全认证：签名校验、设备身份验证、防重放攻击。
端侧负责什么？
- 下载与校验：从云侧拉取固件包，做完整性校验和签名验证。我在项目中遇到过设备下载到一半断电，结果下次重启后固件损坏——所以端侧一定要有断点续传和校验机制。
- 备份与回滚：升级前备份当前固件，升级失败能自动回滚。这个我吃过亏，曾经有一批设备升级后起不来，就是因为没有做双区备份。
- 执行升级：擦写Flash、更新引导程序、切换分区。
- 结果上报：把升级结果（成功/失败/失败原因）回传给云侧。
你可能会问：为什么端侧不自己做策略？说白了，端侧资源太紧张了。MCU上跑个RTOS，内存可能就几百KB，你让它跑灰度策略、做大数据分析，不现实。云侧有弹性计算资源，做这些事更合适。
二、典型拓扑结构：三种常见模式
拓扑结构决定了你的升级链路怎么走。我根据项目经验，总结了三种最常见的模式。
| 拓扑类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 直连模式 | 设备少、网络稳定（如智能家居） | 架构简单，延迟低 | 设备多时云侧压力大 |
| 网关代理模式 | 设备多、子设备资源受限（如工业传感器） | 减轻云侧压力，子设备无需联网 | 网关成为单点瓶颈 |
| 边缘节点模式 | 大规模部署、需要本地缓存（如智慧园区） | 支持离线升级，降低带宽成本 | 架构复杂，需要维护边缘节点 |
直连模式最简单，设备直接跟云通信。但如果你有上万台设备同时请求升级，云侧扛不住。我曾经帮一个客户优化过，他们一开始用直连模式，结果升级高峰期云服务器CPU直接飙到99%。后来改成网关代理，子设备通过网关统一拉取固件，问题就解决了。
网关代理模式里，网关负责跟云通信，子设备只跟网关通信。子设备甚至不需要联网能力，通过串口、蓝牙等跟网关交互就行。嗯，这里要注意：网关本身也要考虑升级，否则网关挂了，所有子设备都升级不了。
边缘节点模式适合更大规模的场景。边缘节点可以缓存固件包，设备从最近的边缘节点下载，速度更快，也支持离线升级。我在智慧园区项目里用过这种模式，效果不错，但维护成本确实高一些。
三、通信协议选型：别选错了，否则后面全是坑
通信协议选型，说白了就是选一个「端侧能跑、云侧能接、网络能扛」的协议。我见过太多项目因为协议选错，后面改得死去活来。
先看一张对比表：
| 协议 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| MQTT | 低带宽、不稳定网络（如NB-IoT） | 轻量级、支持QoS、双向通信 | 不适合大文件传输 |
| CoAP | 资源极度受限设备（如Zigbee节点） | 基于UDP，开销极小 | 可靠性不如MQTT |
| HTTP/HTTPS | 网络稳定、设备资源充足（如Linux网关） | 生态成熟，支持断点续传 | 协议头大，功耗高 |
| 私有TCP/UDP | 特殊需求、定制化场景 | 灵活，可深度优化 | 开发成本高，维护难 |
我个人习惯：控制信令用MQTT，固件传输用HTTPS。为什么？MQTT的QoS机制能保证控制指令可靠到达，而且支持发布/订阅模式，云侧可以轻松推送升级通知。但MQTT不适合传大文件，固件包动辄几MB甚至几十MB，用MQTT传效率太低。HTTPS有成熟的断点续传和分片下载机制，更适合传固件。
避坑指南：我曾经在一个项目里只用MQTT传固件，结果设备网络不稳定，固件包传了一半就断了，MQTT又没有断点续传能力，只能从头开始。后来改成MQTT下发升级通知，HTTPS下载固件，问题才解决。
CoAP适合资源极度受限的设备，比如Zigbee节点或者低功耗蓝牙设备。但CoAP基于UDP，可靠性不如MQTT，需要自己实现重传机制。如果你设备的内存只有几十KB，CoAP可能是唯一选择。
私有协议我一般不建议用，除非你有特殊需求（比如需要加密传输、或者协议栈极度精简）。私有协议的维护成本很高，而且跟云侧对接时容易出问题。
四、端云协同的典型交互流程
最后，我画一个典型的端云协同升级流程，帮你把前面讲的内容串起来。
1. 云侧创建升级任务（指定版本、设备范围、灰度策略）
2. 云侧通过MQTT推送升级通知到设备
3. 设备收到通知后，通过HTTPS请求固件下载地址
4. 设备下载固件包（支持断点续传、分片下载）
5. 设备校验固件完整性（MD5/SHA256）
6. 设备校验签名（RSA/ECDSA）
7. 设备备份当前固件到备份分区
8. 设备擦写主分区，写入新固件
9. 设备重启，引导程序检查新固件有效性
10. 设备通过MQTT上报升级结果（成功/失败+原因）
11. 云侧更新设备状态，记录升级日志这个流程看起来简单，但每一步都可能出问题。比如第5步校验失败怎么办？第8步擦写过程中断电怎么办？这些细节我们会在后面的章节逐一展开。
注意：第7步的备份操作非常关键。我见过不少设备升级失败后变砖，就是因为没有做备份。哪怕你只备份一个分区，也比没有强。双区备份（A/B分区）是最稳妥的方案，但需要Flash空间足够。
好了，这一章我们讲了端侧和云侧的分工、三种拓扑结构、协议选型，以及一个完整的交互流程。下一章我会深入讲固件包的生成与管理，包括差分包的原理和实现。到时候见。