2. OTA系统架构设计：云端升级平台、设备端升级代理、差分升级与全量升级的选型
这一章，我们来聊聊OTA系统的骨架。说白了，就是决定“谁在云端干什么”、“谁在设备上干什么”，以及“升级包到底怎么传”。
很多团队一上来就写代码，结果云端和设备端接口对不上，或者差分算法选错了，导致升级成功率惨不忍睹。我见过不止一个项目，因为架构没想清楚，后期返工的成本比重新做一套还高。
所以，咱们先把架构理清楚。我会从三个核心维度展开：云端升级平台、设备端升级代理，以及差分升级与全量升级的选型。
核心观点：OTA架构不是“拼积木”，而是“搭骨架”。骨架歪了，后面再怎么填肉都别扭。
2.1 云端升级平台：大脑与指挥中心
云端平台负责什么？简单说三件事：管理设备、管理固件、管理升级任务。
我个人习惯把云端平台拆成四个模块：
- 设备管理服务：注册、认证、分组、状态监控。你想想看，如果没有设备分组，你要给100万台设备分批升级，那得手动操作到什么时候？
- 固件管理服务：版本号、校验和、差分包生成、存储。这里有个坑——差分包的生成时机。是在上传时预生成，还是在升级任务触发时实时生成？各有优劣，后面会讲。
- 升级调度服务：灰度策略、流量控制、失败重试。我记得有一次，一个客户没做灰度，全量推送后发现有bug，结果几十万台设备同时变砖……嗯，灰度不是可选项，是必选项。
- 日志与统计服务：升级进度、成功率、失败原因。没有这个，你就像在黑暗中开车，撞了都不知道撞的是什么。
这里我画了一张架构图，帮你直观理解云端平台的模块关系：
经验之谈：云端平台的设计，我建议优先考虑“无状态化”。设备管理、固件管理这些服务，最好都能水平扩展。否则一旦设备量从10万涨到100万，你就得熬夜重构了。
2.2 设备端升级代理：前线的执行者
设备端升级代理，我习惯叫它OTA Agent。它是在设备上跑的一个独立模块，负责接收指令、下载包、校验、备份、刷写、回滚。
它的核心职责可以归纳为五个步骤：
- 心跳与轮询：定期向云端报告状态，询问“有没有新固件？”
- 下载与校验：拿到下载链接后，断点续传、校验完整性。我曾经遇到一个项目，下载到一半网络断了，没有断点续传，结果每次都得从头下，用户差点骂娘。
- 备份当前系统：刷写前，把当前可工作的固件备份到另一个分区。这是回滚的底气。
- 执行刷写：把新固件写入目标分区。这里要注意写操作的原子性——要么全写成功，要么不动原系统。
- 回滚与恢复：如果新固件启动失败，自动切回备份分区。
设备端的设计，有一个关键决策：Agent是放在用户空间，还是放在内核空间？
| 对比维度 | 用户空间 Agent | 内核空间 Agent |
|---|---|---|
| 开发难度 | 低，标准Linux应用开发 | 高，需要内核编程经验 |
| 稳定性 | 高，崩溃不影响内核 | 低，一个bug可能搞挂整个系统 |
| 刷写权限 | 需要提权或通过守护进程 | 直接操作存储设备 |
| 资源占用 | 相对较高（进程开销） | 极低 |
| 适用场景 | Linux/Android等富OS设备 | RTOS或资源极度受限设备 |
我个人习惯，除非是资源极度受限的MCU设备，否则优先选用户空间Agent。原因很简单——好调试、好维护。内核空间的Agent一旦出问题，连日志都可能抓不到。
避坑指南：我曾经在一个项目里，把Agent设计成与主业务进程耦合在一起。结果升级过程中业务进程崩溃，Agent也跟着挂了，设备直接变砖。后来我强制要求：Agent必须是一个独立的、高优先级的守护进程，与业务逻辑完全解耦。
2.3 差分升级 vs 全量升级：选型决策
这是OTA架构里最纠结的一个选择。全量升级简单粗暴，差分升级省流量但复杂。到底怎么选？
先看对比：
| 对比维度 | 全量升级 | 差分升级 |
|---|---|---|
| 升级包大小 | 完整固件（通常几十MB~几百MB） | 差异部分（通常几KB~几MB） |
| 生成复杂度 | 低，直接打包固件即可 | 高，需要差分算法（bsdiff/xdelta等） |
| 设备端计算量 | 低，直接写入 | 高，需要解压+合并+校验 |
| 网络消耗 | 高 | 低 |
| 失败风险 | 低，包完整 | 中，差分算法可能出错 |
| 适用场景 | 首次升级、大版本跨越、资源充足设备 | 小版本迭代、流量敏感、NB-IoT/2G设备 |
我的选型原则很简单：
- 如果设备是Wi-Fi/以太网连接，且固件小于50MB：全量升级就够了。别折腾差分，省那点流量不够你调试差分算法的时间成本。
- 如果设备是NB-IoT/2G/3G，或者固件超过100MB：必须上差分。否则一次升级就能把用户的流量套餐干光。
- 如果设备是MCU，Flash只有几MB：差分几乎是唯一选择。全量包可能比Flash还大。
差分算法方面，我常用的几个：
| 算法 | 压缩率 | 内存消耗 | 适用场景 |
|---|---|---|---|
| bsdiff | 高（通常10%~30%） | 高（需要加载新旧固件到内存） | Linux/Android大固件 |
| xdelta3 | 中（30%~50%） | 中 | 通用场景，平衡性好 |
| HDiffPatch | 高（接近bsdiff） | 低（流式处理） | 资源受限设备 |
| 自定义差分 | 取决于实现 | 可控 | 特定文件系统（如FAT、LittleFS） |
我的建议：如果团队没有差分算法专家，优先用 HDiffPatch。它压缩率接近bsdiff，但内存消耗低得多，非常适合嵌入式设备。我在三个量产项目里用了它，没出过问题。
2.4 混合策略：全量+差分的组合拳
其实，全量和差分不是非此即彼。我见过最成熟的方案是混合策略：
- 首次升级：全量推送。因为设备上没有旧固件，没法做差分。
- 小版本迭代：差分推送。比如从v2.0.1到v2.0.2，改动很小。
- 大版本跨越：全量推送。比如从v2.x到v3.x，差异太大，差分包可能比全量包还大。
- 失败回退：如果差分升级失败，自动降级为全量升级。
这个策略的好处是：平时省流量，关键时刻保成功。
一个小技巧：云端在生成差分包时，可以同时生成多个版本的差分包。比如设备从v1.0到v1.1、v1.2到v1.3，都提前算好。这样升级时直接下发，不用实时计算，减少云端压力。
2.5 架构选型决策树
最后，我整理了一个简单的决策流程，帮你快速确定架构方向：
最后提醒一句：架构设计没有银弹。不要盲目追求“最先进”的方案，而要选择“最适合你当前设备、网络、团队”的方案。我见过用bsdiff做差分，结果设备内存只有256KB，根本跑不起来——这就是典型的“技术选型脱离实际”。
好了，这一章的核心内容就是这些。记住：云端管调度，设备管执行，差分省流量，全量保成功。把这四句话刻在脑子里，你的OTA架构就不会跑偏。