2. OTA系统架构设计：云端架构、设备端架构、升级链路全貌
好，咱们进入第二章。这一章我打算把OTA系统的骨架给你拆开来看。说白了，就是回答三个问题：云上怎么管？设备上怎么跑？数据怎么传？
我最早做扫地机OTA的时候，犯过一个低级错误——只盯着设备端代码写，结果云端接口设计得一塌糊涂，最后联调时两边对不上，加班到凌晨三点。嗯，从那以后，我养成了一个习惯：先画架构图，再写一行代码。
2.1 云端架构：不止是文件存储
很多人以为云端就是个文件服务器，把固件包扔上去就完事了。其实远不止这么简单。一个成熟的OTA云端架构，至少包含四个核心模块：
- 固件管理服务：版本号、发布时间、适用机型、升级说明。我习惯用语义化版本号，比如
v2.1.3，主版本.次版本.补丁，一目了然。 - 设备管理服务：记录每台设备的当前版本、在线状态、设备ID。你想想看，没有这个，你怎么知道该给谁推送？
- 升级策略引擎：灰度比例、分批规则、强制升级还是可选升级。我在项目里遇到过全量推送导致服务器被打爆的情况，后来学乖了，灰度发布是底线。
- 日志与统计服务：升级成功/失败率、失败原因分布、升级耗时。这些数据是优化下一版的关键。
核心要点：云端架构的设计原则是「解耦」。固件存储、设备管理、策略控制，这三者最好拆成独立服务，方便后续扩展。
2.2 设备端架构：轻量、可靠、可回滚
设备端资源有限，MCU可能只有几百KB的Flash和几十KB的RAM。所以设备端架构必须轻量。我一般把它分成三层：
| 层级 | 职责 | 常见实现 |
|---|---|---|
| 通信层 | 与云端建立连接，收发数据 | MQTT、CoAP、HTTP |
| 升级引擎层 | 下载校验、解压、写入、回滚 | 状态机 + 差分算法 |
| 应用层 | 业务逻辑，与升级无关 | 传感器、电机控制等 |
这里有个关键点：升级引擎层必须独立于应用层。为什么？因为应用层可能在升级过程中崩溃，如果它们耦合在一起，升级就永远无法完成。我见过一个产品，升级时应用层跑飞了，结果设备变砖，只能返厂。这就是血的教训。
我的习惯：在设备端预留两个分区——A区和B区。一个跑当前固件，一个用来下载新固件。下载完成后，切换启动分区。这样即使升级失败，还能回滚到旧版本。
2.3 升级链路全貌：从云端到设备，一步都不能少
好，现在我们把云端和设备串起来，看看一条完整的升级链路长什么样。我把它拆成七个步骤：
- 设备上报状态：设备上线后，主动向云端报告当前固件版本号。
- 云端检查更新：云端比对设备版本和最新版本，决定是否需要升级。
- 下发升级指令：如果需要升级，云端下发一条指令，包含固件下载地址、校验值、版本号。
- 设备下载固件：设备通过HTTP或MQTT下载固件包。我建议用断点续传，防止网络波动导致重头再来。
- 校验完整性：下载完成后，用MD5或SHA256校验固件包。这一步不能省，我在项目中遇到过下载损坏导致升级失败的情况。
- 写入并切换：将固件写入备用分区，然后设置启动标志，重启设备。
- 上报升级结果：设备重启后，上报新版本号。云端确认升级成功。
注意：第6步和第7步之间有一个「死亡窗口」——设备重启后如果无法正常启动，云端就永远收不到确认消息。所以一定要加超时重试机制，并且保留旧分区至少一个升级周期。
2.4 链路中的关键设计决策
讲完链路，我想聊聊几个设计上的取舍。这些决策直接影响系统的稳定性和用户体验。
- 同步还是异步？ 我建议用异步。云端下发指令后，设备自己决定什么时候下载、什么时候重启。这样不会阻塞其他业务。
- 全量升级还是差分升级？ 如果网络带宽有限，差分升级能省下80%的流量。但差分算法（比如bsdiff）在MCU上跑起来有点吃力，需要权衡。
- 强制升级还是可选升级？ 安全补丁必须强制，功能更新可以可选。但强制升级一定要给用户一个倒计时提示，否则会被投诉。
你可能会问：「这些设计有没有标准答案？」说实话，没有。每个产品、每个场景都不一样。我个人的做法是：先做最小可行版本，跑通链路，再根据线上数据逐步优化。
2.5 一个简单的链路时序图（伪代码）
为了让你更直观地理解，我写一段伪代码来描述设备端的升级流程：
// 设备端OTA升级主循环
void ota_main_loop() {
// 1. 上报当前版本
mqtt_publish("device/status", "{'version':'2.1.2'}");
// 2. 等待云端指令
ota_cmd = mqtt_subscribe("device/ota/cmd");
if (ota_cmd == NULL) return;
// 3. 解析指令，获取下载地址
url = parse_url(ota_cmd);
checksum = parse_checksum(ota_cmd);
// 4. 下载固件到B分区
download_to_partition(B_PARTITION, url);
// 5. 校验完整性
if (verify_checksum(B_PARTITION, checksum) == FAIL) {
report_error("checksum mismatch");
return;
}
// 6. 切换启动分区
set_boot_partition(B_PARTITION);
// 7. 重启设备
system_reboot();
// 8. 重启后上报新版本
// 这一步在main函数中执行
}
这段代码虽然简单，但涵盖了核心逻辑。你可以在它的基础上加断点续传、加超时重试、加回滚机制。嗯，这就是一个合格的OTA升级引擎的雏形。
2.6 小结
这一章我们聊了云端架构、设备端架构，以及从云端到设备的完整升级链路。核心就三句话：
- 云端要解耦，设备要轻量。
- 链路要可靠，每一步都要有校验和回滚。
- 设计要灵活，根据实际场景做取舍。
下一章我会深入讲固件包的生成与签名，那是保证升级安全的关键一环。到时候见。