2. OTA系统架构设计：客户端-服务器模型、升级包管理、差分升级与全量升级、OTA系统核心模块划分
好，咱们进入第二章。这一章是整个OTA课程的骨架。
说白了，你如果不懂架构设计，后面写代码就是瞎忙活。我见过太多团队，一上来就写升级逻辑，结果服务器和客户端对不上号，升级包管理一团乱麻。嗯，咱们今天就把这事彻底理清楚。
2.1 客户端-服务器模型：谁该干什么？
OTA系统最经典的架构，就是客户端-服务器模型。这个模型其实不复杂，但分工必须明确。
服务器端，负责三件事：
- 升级包存储：所有固件版本都放在服务器上，按产品、按版本号组织好。
- 版本管理：记录每个设备当前版本、可升级版本、升级历史。
- 策略下发：决定哪些设备能升级、什么时候升级、灰度比例多少。
客户端，也就是你的嵌入式设备，负责另外三件事：
- 版本查询：主动或被动地询问服务器“有没有新版本？”
- 下载与校验：拿到升级包后，先校验完整性，再写入存储。
- 执行升级：重启到Bootloader，完成固件切换。
核心原则：服务器只管“管”，客户端只管“做”。千万别让客户端去决定升级策略，否则你会被碎片化问题搞疯。
我在项目中遇到过一种情况：客户端自己判断“网络好就升级”，结果半夜所有设备同时下载，把服务器带宽打满了。后来我改成服务器端统一调度，按设备ID分批下发，问题才解决。
2.2 升级包管理：版本号、差异、回滚
升级包管理，听起来简单，做起来坑很多。
版本号规范，我个人习惯用 主版本.次版本.修订版本 三段式。比如 2.1.3。为什么？因为你要支持回滚。如果版本号没有大小比较逻辑，你怎么知道哪个版本更新？
升级包命名，我建议这样：
产品名_硬件版本_当前版本_目标版本_升级类型.bin
例如：smartlock_v1.2_2.1.3_2.2.0_full.bin为什么要带硬件版本？你想想看，同一款产品可能换了Flash芯片，固件就不兼容了。我吃过这个亏，升级包没区分硬件版本，结果一批设备直接变砖。
警告：升级包必须包含元数据头。至少要有：魔数、版本号、固件大小、校验值、目标硬件版本。否则客户端无法验证包是否合法。
回滚策略，这是很多新手忽略的。我建议每个设备至少保留两个固件分区：当前运行区 + 备份区。升级时写入备份区，如果启动失败，自动切回当前区。我曾经见过一个产品，升级后WiFi驱动挂了，因为没有回滚机制，只能返厂刷机。
2.3 差分升级 vs 全量升级：怎么选？
这是OTA里最核心的技术决策之一。
| 对比项 | 全量升级 | 差分升级 |
|---|---|---|
| 升级包大小 | 整个固件（通常几百KB~几MB） | 差异部分（通常几十KB~几百KB） |
| 生成复杂度 | 简单，直接打包 | 复杂，需要bsdiff等工具 |
| 客户端资源消耗 | 低，只需写入 | 高，需要解差分、合并 |
| 适用场景 | 首次烧录、大版本升级 | 小版本迭代、流量敏感场景 |
我的建议：
- 如果设备Flash足够大（比如8MB以上），优先用全量升级。简单、稳定、不容易出错。
- 如果设备是电池供电、流量有限（比如NB-IoT），必须用差分升级。我曾经帮一个水表客户做OTA，全量包1.2MB，差分包只有80KB，省了90%的流量。
提示：差分升级的算法，我推荐bsdiff。它基于后缀排序，生成的差分包小，但合并时内存消耗大。如果你的设备RAM只有几十KB，可以考虑xdelta或者自己写简单的字节级差分。
嗯，这里要注意：差分升级不是万能的。如果两个版本之间改动太大，差分包可能比全量包还大。我遇到过这种情况，后来加了一个阈值判断：如果差分包超过全量包的80%，就直接下发全量包。
2.4 OTA系统核心模块划分
一个完整的OTA系统，至少需要以下模块。我按功能把它们分成四层：
2.4.1 通信层
- HTTP/HTTPS下载模块：负责从服务器拉取升级包。支持断点续传、超时重试。
- MQTT/CoAP控制通道：用于服务器主动推送升级通知，或者客户端上报状态。
2.4.2 升级管理层
- 版本管理模块：维护本地版本号、服务器版本列表。
- 策略执行模块：根据服务器下发的策略（立即升级、定时升级、静默升级）执行动作。
- 回滚管理模块：记录升级历史，支持手动或自动回滚。
2.4.3 固件处理层
- 校验模块：MD5/SHA256校验，防止传输错误或恶意篡改。
- 差分合并模块：如果是差分升级，负责将差分包与当前固件合并成新固件。
- Flash写入模块：将固件写入指定分区，支持擦除、写入、校验。
2.4.4 启动层
- Bootloader：负责启动时检查固件完整性，决定从哪个分区启动。
- 看门狗模块：升级过程中如果卡死，自动复位并回滚。
架构要点：这四个层次之间要解耦。通信层只管收发数据，不管数据是什么。升级管理层只管决策，不管怎么写入Flash。这样任何一个模块出问题，都不会影响其他模块。
我记得有一次，客户说升级后设备频繁重启。排查了半天，发现是Flash写入模块在写入时没有做磨损均衡，导致某个块写坏了。但因为模块之间解耦得好，我们只改了Flash写入模块，其他代码一行没动。
2.5 小结
这一章的内容，说白了就是让你脑子里有个全局图。
- 客户端-服务器模型：服务器管策略，客户端管执行。
- 升级包管理：版本号、元数据、回滚机制，一个都不能少。
- 差分 vs 全量：根据Flash大小和流量成本选，别盲目追新。
- 核心模块划分：通信层、管理层、处理层、启动层，各司其职。
下一章，咱们会深入Bootloader的设计。你会看到，一个靠谱的Bootloader，才是OTA安全的最后一道防线。