2. OTA系统架构设计：云端升级平台、设备端升级代理、差分升级算法、安全通信协议

OTA升级，说白了就是一套「远程换血」的系统工程。我做了这么多年嵌入式，见过太多把OTA简单理解成「发个文件过去」的项目，结果上线后各种翻车。今天咱们就把这套架构拆开揉碎了讲清楚。

一个完整的OTA系统，核心就四个模块：云端平台、设备端代理、差分算法、安全通信。它们各司其职，缺一不可。

2.1 云端升级平台：不只是个文件服务器

很多人觉得云端就是个存固件的地方，设备来下载就行了。其实远没那么简单。一个合格的OTA云平台，至少要管这几件事：

• 设备管理：记录每台设备的型号、当前版本、硬件版本、序列号。没有这个基础，你都不知道该给谁推什么包。
• 版本管理：维护固件包的版本树，支持灰度发布、回滚、AB测试。我记得有个项目，全量推送后才发现新固件有bug，幸好有回滚能力，不然就炸了。
• 任务调度：控制升级的节奏，比如按批次、按地域、按时间段下发。避免一瞬间所有设备都来下载，把服务器打爆。
• 状态监控：实时查看每台设备的升级进度、成功/失败原因。这是排查问题的第一手数据。

我建议云平台至少提供以下API接口：

接口名称	功能描述	请求方向
/checkUpdate	设备查询是否有新版本	设备→云端
/getPackage	获取升级包下载地址	设备→云端
/reportStatus	上报升级进度和结果	设备→云端
/createTask	创建升级任务（管理端）	管理端→云端
/getTaskDetail	查看任务执行详情	管理端→云端

2.2 设备端升级代理：守好最后一公里

设备端是OTA的「最后一公里」，也是最容易出问题的地方。升级代理（Update Agent）通常跑在一个独立分区或安全环境中，负责：

• 下载管理：支持断点续传、分片下载、校验完整性。网络不稳定的场景下，这个功能能救命。
• 版本校验：检查下载的包是否完整、签名是否合法、是否匹配当前硬件。我遇到过有人拿错固件包刷进去，设备直接变砖。
• 备份与回滚：升级前备份当前系统，升级失败能自动回滚。这是最后一道防线。
• 状态上报：实时向云端反馈下载进度、校验结果、升级阶段。

设备端的存储布局，我习惯这样设计：

Flash Layout (典型双备份方案):
+------------------+
| Bootloader       |  // 引导加载器，负责启动选择和回滚
+------------------+
| Slot A (Active)  |  // 当前运行的系统
+------------------+
| Slot B (Standby) |  // 升级目标位置
+------------------+
| Update Agent     |  // 升级代理，独立于系统运行
+------------------+
| Config/Data      |  // 配置参数、升级状态记录
+------------------+

2.3 差分升级算法：省流量、省时间、省带宽

差分升级，说白了就是只传输「变化的部分」。你想想看，一个固件包可能10MB，但每次升级可能只改了100KB的代码。全量下发太浪费了。

常用的差分算法有几种：

算法	原理	适用场景	压缩率
bsdiff	基于后缀排序的二进制差分	通用固件，差异较大时效果好	高
hdiffpatch	基于哈希匹配的差分	大文件，内存受限设备	中高
xdelta	基于VCDIFF标准的差分	通用场景，兼容性好	中
自定义差分	针对特定文件系统优化	资源极度受限的MCU	视情况

差分升级的流程大致是这样的：

1. 云端生成差分包：用旧版本和新版本做对比，生成patch文件。
2. 设备下载patch：只下载patch，不下载完整固件。
3. 设备本地合成：用旧固件 + patch，合成新固件。
4. 校验并切换：校验合成后的固件完整性，然后切换到新版本。

2.4 安全通信协议：别让升级变成「送人头」

OTA升级如果安全没做好，等于把设备的控制权拱手让人。我见过最离谱的项目，固件包直接明文传输，连个校验都没有。攻击者只要中间人篡改一下，设备就成肉鸡了。

安全通信协议至少要覆盖这几个层面：

• 传输加密：使用TLS/DTLS加密通信链路，防止窃听和篡改。
• 固件签名：云端用私钥对固件包签名，设备端用公钥验签。确保固件来源可信。
• 防重放攻击：在请求中加入时间戳或随机数，防止攻击者截获旧请求重复发送。
• 身份认证：设备与云端双向认证，确保双方都是合法的。

我常用的安全通信架构是这样的：

安全通信流程:
1. 设备连接云端，建立TLS通道
2. 设备发送设备证书，云端验证
3. 云端下发固件包描述信息（版本、大小、哈希值、签名）
4. 设备下载固件包，边下载边校验哈希
5. 下载完成后，用预置公钥验签
6. 验签通过，才允许写入升级分区

2.5 整体架构图：把四个模块串起来

下面这张图展示了OTA系统的整体架构和核心流程。我习惯用这种分层的方式画架构图，每一层职责清晰，接口明确。

2.6 架构设计中的几个关键决策点

做OTA架构设计时，有几个问题我建议你提前想清楚：

• 全量还是差分？如果设备网络带宽充足、流量不限，全量升级更简单可靠。差分升级虽然省流量，但增加了设备端的计算复杂度和出错概率。
• 双备份还是单备份？双备份（A/B分区）安全性高，但占用双倍存储空间。单备份加回滚分区是折中方案，适合存储受限的设备。
• 同步还是异步？同步升级（设备在线等待）流程简单，但用户体验差。异步升级（设备后台下载，下次重启生效）更友好，但状态管理更复杂。
• 云端推送还是设备拉取？推送模式实时性好，但需要维持长连接。拉取模式省资源，但有延迟。我建议关键升级用推送，普通升级用拉取。