2、OTA系统架构：云端升级平台、设备端升级代理、差分升级与全量升级、升级包分发策略

聊OTA，不能光盯着设备端那点事。你得把整个链路看成一个闭环——从云端怎么生成包，到设备怎么拿包，再到怎么把新固件安全地写进去。我这些年踩过的坑，十有八九都是因为只关注了其中一环。

说白了，OTA架构就四个核心模块：云端平台、设备端代理、升级策略、分发策略。咱们一个一个拆开讲。

2.1 云端升级平台

云端平台是OTA的大脑。它不光是存固件的地方，更是一个完整的生命周期管理中心。

我记得有一次，客户说他们的升级成功率只有60%。查了半天，发现是云端平台没有做设备分组——所有设备同时收到推送，服务器带宽被打满，大量设备下载超时。后来加了分组和限速，成功率直接拉到98%。

云端平台通常包含这几个子系统：

子系统	功能	我见过的坑
固件仓库	存储原始固件、差分包、元数据	差分包生成失败时没有自动回退到全量包
设备注册中心	设备身份认证、版本跟踪	设备证书过期导致升级链路中断
升级调度器	灰度发布、定时升级、断点续传	没有做幂等处理，设备重复上报导致重复推送
监控告警	实时统计、失败原因聚合	日志采样率太低，排查问题时数据不够用

2.2 设备端升级代理

设备端代理，就是跑在MCU或SoC上的那个小模块。它要足够轻量，又不能出半点差错——毕竟升级过程中一旦挂了，设备可能变砖。

我个人习惯把设备端代理分成三层：

1. 通信层——负责与云端握手、下载数据包、处理断点续传
2. 校验层——验签名、算哈希、检查包完整性
3. 执行层——把固件写入Flash、切换启动分区、回滚处理

设备端代理的典型工作流程：

1. 设备上电 → 检查升级标志位
2. 有标志 → 进入升级模式 → 连接云端
3. 云端下发升级包元数据（版本、大小、哈希、签名）
4. 设备校验元数据 → 通过则开始下载
5. 下载完成后验签 → 验哈希 → 写入备用分区
6. 写入完成 → 设置启动标志 → 重启
7. 新固件启动 → 上报升级成功 → 云端确认

2.3 差分升级与全量升级

这是OTA里最核心的技术选型之一。选对了，带宽和功耗都能省一大截；选错了，升级失败率直线上升。

全量升级：把完整的固件包发给设备。简单粗暴，兼容性好，但包体大。

差分升级：只发新旧固件之间的差异部分。包体小，省流量，但生成差分包和合并差分包都需要计算资源。

对比项	全量升级	差分升级
包体大小	大（完整固件）	小（仅差异部分）
生成复杂度	低（直接打包）	高（需要bsdiff等算法）
设备端资源消耗	低（直接写入）	高（需要内存做合并）
适用场景	首次升级、跨版本升级	小版本迭代、带宽受限场景
失败风险	低	中（合并过程可能出错）

差分升级的算法选择也很关键。我常用的几个：

• bsdiff——压缩率高，但内存占用大，适合资源丰富的设备
• hdiffpatch——平衡型，适合中等资源设备
• xdelta——轻量级，适合MCU类设备

2.4 升级包分发策略

包做好了，怎么发给成千上万的设备？这里面的门道比你想的多。

分发策略的核心目标：高成功率、低带宽占用、不影响业务。

常见的分发策略：

1. 灰度发布——先推给5%的设备，观察24小时，没问题再逐步扩大到100%。我习惯用设备ID哈希取模来做灰度分组，这样同一设备始终落在同一组，不会出现今天升了明天又被降级的情况。
2. 定时升级——凌晨2点到5点，业务低峰期推送。这个策略在物联网设备上特别重要——你不想让用户的智能门锁在早上8点升级吧？
3. 限速分发——控制同时下载的设备数量，避免CDN被打爆。我一般按设备所在区域做限速，比如华东区同时最多5000台在下载。
4. 断点续传——下载中断后从断点继续，不用重头开始。这个在弱网环境下几乎是必备功能。

下面这张图，是我自己总结的OTA系统整体架构关系。你看一眼，基本就能把前面讲的串起来。

嗯，这张图里我特意把四个模块之间的依赖关系画出来了。你看，云端平台和升级策略是紧密耦合的——你选差分还是全量，直接决定了云端怎么生成包。而分发策略是承上启下的关键，它决定了包能不能高效、安全地到达设备端。