2. 系统架构设计：OTA升级系统的整体架构
好，咱们直接进入正题。OTA升级系统说白了，就是一套让设备“在线打补丁”的机制。我做了这么多年嵌入式，见过太多因为升级失败导致设备变砖的惨案。所以架构设计这一步，千万不能马虎。
一个完整的OTA系统，通常由三部分组成：云端、终端、管理平台。这三者各司其职，又紧密配合。我习惯把它们比作“指挥中心”、“前线士兵”和“后勤仓库”。
2.1 整体架构概览
先看一张我手绘的架构图（嗯，这里用文字描述一下）：
┌─────────────────────────────────────────────────────────────┐
│ 管理平台 (Web/App) │
│ - 设备管理 - 升级策略 - 版本控制 - 日志查看 │
└──────────────────────────┬──────────────────────────────────┘
│ HTTPS/REST API
▼
┌─────────────────────────────────────────────────────────────┐
│ 云端服务 (Cloud) │
│ - 固件存储(S3/MinIO) - 设备认证 - 任务调度 │
│ - 差分算法(bspatch) - 状态监控 - 消息推送(MQTT) │
└──────────────────────────┬──────────────────────────────────┘
│ MQTT/CoAP/HTTP
▼
┌─────────────────────────────────────────────────────────────┐
│ 终端设备 (Device) │
│ - Bootloader - 主应用 - 备份分区 - 状态上报 │
└─────────────────────────────────────────────────────────────┘
你看，数据流是双向的。管理平台下发指令，云端处理逻辑，终端执行升级。反过来，终端上报状态，云端汇总，管理平台展示。这个闭环，就是OTA的核心。
2.2 各模块职责划分
咱们一个一个拆开讲。每个模块都有它存在的理由，少一个都不行。
2.2.1 云端服务
云端是大脑。它不直接跟硬件打交道，但所有决策都从这里发出。
- 固件存储：我建议用对象存储，比如AWS S3或者自建MinIO。别把固件放数据库里，那会把你数据库撑爆的。我曾经见过一个团队把固件存MySQL，结果一张表几十个G，查询慢得像蜗牛。
- 设备认证：每个设备必须有唯一ID和密钥。云端收到升级请求时，先验明正身。这一步防的是“假设备”混进来搞破坏。
- 任务调度：不是所有设备同时升级。分批、灰度、按区域，这些都是调度策略。我习惯用消息队列（比如RabbitMQ）来做任务分发，这样即使设备离线，任务也不会丢。
- 差分算法：说白了就是只传变化的部分。比如固件从v1.0升到v1.1，可能只改了10KB，那就只传这10KB。我常用bsdiff/bspatch，效果不错。
- 状态监控：每个设备升级到哪一步了？成功了还是失败了？云端要实时记录。这些数据是后续排查问题的关键。
2.2.2 终端设备
终端是执行者。它要保证升级过程安全、可靠、不掉链子。
- Bootloader：这是第一道防线。它负责校验固件签名、检查升级标志、决定启动哪个分区。我建议Bootloader尽量精简，功能越少，出bug的概率越低。
- 主应用：就是跑业务逻辑的程序。它负责下载固件、写入分区、上报进度。注意，下载过程中如果断电，要能断点续传。
- 备份分区：这是保命用的。升级前把当前固件备份一份，万一新固件跑不起来，还能回滚。我见过太多设备因为没做备份，升级失败后直接变砖。
- 状态上报：终端要定期向云端汇报“我还活着”、“我在下载”、“我写完了”。云端根据这些状态决定下一步动作。
⚠️ 注意： 终端的内存和Flash通常很有限。下载固件时，建议边下载边写入，不要等全部下载完再写。否则内存爆了，你哭都来不及。
2.2.3 管理平台
管理平台是给运维人员用的。它不参与核心逻辑，但提供了操作入口。
- 设备管理：查看所有设备列表、在线状态、当前版本。我习惯按产品线、地域、批次来分组，方便批量操作。
- 升级策略：设置升级范围（全部设备还是部分设备）、升级时间（立即升级还是定时升级）、升级方式（强制升级还是静默升级）。
- 版本控制：上传新固件、查看版本历史、标记某个版本为“稳定版”或“测试版”。
- 日志查看：每个设备的升级日志、错误码、失败原因。这些信息对排查问题至关重要。
2.3 数据流与指令流设计
这部分是重点。数据怎么流？指令怎么传？我直接画个时序图给你看。
2.3.1 数据流
数据流主要分两种：固件数据流和状态数据流。
| 数据流类型 | 方向 | 内容 | 协议 |
|---|---|---|---|
| 固件数据流 | 云端 → 终端 | 固件包（全量或差分） | HTTPS / MQTT |
| 状态数据流 | 终端 → 云端 | 升级进度、结果、错误码 | MQTT / CoAP |
| 指令数据流 | 管理平台 → 云端 → 终端 | 升级命令、取消命令、回滚命令 | HTTPS + MQTT |
你想想看，固件数据流如果走MQTT，那MQTT的payload会很大，容易把消息队列堵死。所以我个人建议：固件下载走HTTPS，状态上报走MQTT。这样各取所长，互不干扰。
2.3.2 指令流
指令流是“谁指挥谁”的问题。我举个例子：
- 运维人员在管理平台点击“升级设备A到v2.0”。
- 管理平台通过HTTPS调用云端API，创建一条升级任务。
- 云端通过MQTT向设备A推送一条指令：
{"cmd": "upgrade", "version": "v2.0", "url": "https://...", "md5": "..."} - 设备A收到指令后，开始下载固件。下载过程中，通过MQTT上报进度：
{"status": "downloading", "progress": 45} - 下载完成，设备A校验MD5，写入备份分区，然后重启。
- 重启后，Bootloader检测到升级标志，启动新固件。新固件运行正常，上报：
{"status": "success", "version": "v2.0"} - 云端更新设备状态，管理平台显示“升级成功”。
这个流程看起来简单，但每一步都可能出问题。我曾经遇到过设备下载到99%时网络断了，结果它没做断点续传，只能从头下载。后来我强制要求所有终端必须支持断点续传，才解决了这个问题。
💡 小技巧： 指令流中，云端推送指令后，终端必须回复ACK。如果云端没收到ACK，就认为指令丢失，需要重推。这个机制能有效防止指令丢失导致的“僵尸任务”。
2.4 避坑指南
最后，分享几个我踩过的坑：
- 不要用HTTP传固件：明文传输，中间人攻击分分钟改掉你的固件。必须用HTTPS，并且校验证书。
- 不要同时升级所有设备：万一新固件有bug，所有设备一起变砖，你就等着被开除吧。一定要分批、灰度。
- 不要忽略终端存储空间：有些设备Flash只有2MB，固件1.5MB，备份分区还要占1.5MB，根本放不下。这时候只能做差分升级，或者放弃备份，用“双分区交替启动”方案。
- 不要忘记超时机制：设备下载到一半没反应了怎么办？云端要设置超时时间，超时后自动标记为失败，并触发告警。
好了，架构设计就讲到这里。下一章咱们聊聊具体的协议选型和实现细节。记住，架构设计不是一次性的，它需要根据实际项目不断调整。你想想看，没有完美的架构，只有最适合当前场景的架构。