第二章 OTA升级系统架构设计：整体架构分层
好，咱们进入第二章。这一章我打算聊聊OTA升级系统的整体架构。
很多人一上来就写代码，结果做到一半发现云端和终端对不上，升级包传一半丢了，版本号乱套了。嗯，我早期也踩过这个坑。后来我养成了一个习惯：先画架构图，再写代码。
OTA升级系统，说白了就是三个层面的事：云端、管道、终端。咱们一个一个拆开看。
2.1 整体架构分层
我习惯把OTA系统画成三层结构。你想想看，就像快递系统一样：
- 云端：相当于快递总仓，负责管理包裹（升级包）、制定配送计划（升级策略）
- 管道：相当于快递运输网络，负责把包裹安全送到你家门口
- 终端：相当于你家，负责签收、拆包、安装
这三层缺一不可。我在一个智能网关项目里，就因为忽略了管道层的断点续传能力，结果升级包传一半网络断了，设备变砖了。从那以后，我对管道层的设计格外重视。
核心原则：每一层只做自己的事，层与层之间通过标准接口通信。不要越俎代庖。
2.2 云端层职责
云端层，我习惯叫它OTA管理平台。它负责的事情比较多，我列一下：
- 设备管理：注册、认证、分组、版本追踪
- 升级包管理：上传、存储、校验、版本控制
- 升级策略：灰度发布、定时升级、强制升级、静默升级
- 任务调度：创建升级任务、下发指令、监控进度
- 日志与统计：收集升级结果、失败原因、成功率统计
我个人习惯把云端设计成微服务架构。为什么？因为OTA升级涉及的功能模块太多，耦合在一起后期改起来很痛苦。我曾经在一个项目里，把设备管理和升级策略写在一个服务里，结果每次改策略都要重启整个服务，设备掉线一大片。嗯，教训深刻。
云端和终端的交互，我建议用MQTT + HTTP的组合：
- MQTT：用于指令下发、状态上报，实时性强
- HTTP：用于下载升级包，支持断点续传
小技巧：云端不要直接给终端推送升级包数据，而是推送一个下载链接。终端自己去下载，这样云端压力小，也方便做CDN加速。
2.3 管道层职责
管道层，说白了就是网络传输。但这里面的门道不少。
管道层要解决的核心问题有三个：
- 可靠性：数据不能丢，不能错
- 安全性：防止中间人攻击，防止升级包被篡改
- 效率：带宽有限，要尽量快
我常用的管道方案有这几种：
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| MQTT + TLS | 指令下发、状态上报 | 实时性好，双向通信 | 大文件传输效率低 |
| HTTP/HTTPS | 升级包下载 | 支持断点续传，成熟稳定 | 需要额外处理重连 |
| CoAP + DTLS | 低功耗设备 | 协议轻量，适合NB-IoT | 生态不如MQTT成熟 |
| 私有协议 | 特殊场景（如卫星通信） | 高度定制化 | 开发成本高，维护难 |
我个人建议，优先选择MQTT + HTTPS的组合。这是目前CPE设备最成熟的方案，踩坑的人多，网上资料也多，遇到问题好解决。
注意：管道层一定要做加密。我曾经见过一个项目，升级包明文传输，结果被中间人篡改，设备被植入了恶意固件。嗯，从那以后，我所有项目都强制要求TLS加密。
2.4 终端层职责
终端层，就是咱们的CPE设备本身。这一层是OTA升级的最后一公里，也是最容易出问题的地方。
终端层要干的事：
- 升级代理：接收云端指令，下载升级包
- 校验机制：校验包完整性、签名验证
- 备份与回滚：升级失败能恢复
- 状态上报：实时反馈升级进度
我设计终端升级模块时，一般会分成三个子模块：
ota/
├── ota_agent.c # 升级代理，负责通信
├── ota_downloader.c # 下载器，支持断点续传
├── ota_installer.c # 安装器，负责刷写固件
└── ota_rollback.c # 回滚模块，保命用的这里有个关键点：终端一定要有双分区设计。一个分区跑当前固件，另一个分区用来写入新固件。升级完成后切换启动分区。这样即使升级失败，还能切回旧分区启动。
我记得有一次，一个同事没做双分区，直接覆盖写flash。结果写到一半断电了，设备彻底变砖。嗯，从那以后，双分区成了我项目的硬性要求。
2.5 各层交互流程
好了，三层都讲完了。咱们看看它们之间是怎么配合的。
一个典型的OTA升级流程是这样的：
- 云端创建升级任务：指定设备、升级包、策略
- 云端下发升级通知：通过MQTT告诉终端「有新版本了」
- 终端上报当前版本：确认自己是否需要升级
- 云端返回下载地址：带上token，用于鉴权
- 终端下载升级包：通过HTTPS，支持断点续传
- 终端校验包：MD5/SHA256 + 签名验证
- 终端写入固件：写入备用分区
- 终端切换分区：重启，从新分区启动
- 终端上报结果：成功或失败，失败原因
- 云端记录日志：更新设备版本状态
这个流程看起来简单，但每个环节都有坑。比如第5步，如果网络不稳定，下载到一半断了怎么办？我一般会在下载器里实现断点续传，记录已下载的偏移量，下次从断点继续。
交互设计要点：
- 所有指令都要有超时重试机制
- 所有状态上报都要有确认机制
- 所有下载都要有校验机制
- 所有失败都要有回滚机制
2.6 避坑指南
最后，我分享几个实战中遇到的坑：
- 坑一：升级包太大。有一次我传了一个200MB的固件包，结果设备内存只有64MB，直接OOM了。后来我加了分片下载，边下载边写入flash。
- 坑二：并发升级。同时给1000台设备下发升级指令，结果云端被打挂了。后来我加了速率限制，分批下发。
- 坑三：版本号混乱。设备上报的版本号和云端记录的不一致，导致重复升级。后来我统一了版本号规范，强制使用语义化版本。
嗯，这一章就到这里。架构设计是OTA升级的骨架，骨架搭好了，后面写代码才不容易跑偏。下一章咱们聊聊升级包的制作和签名，这个环节也很关键。