2. OTA系统架构设计：云端架构、终端架构与通信协议选型

OTA升级，说白了就是给设备“隔空打补丁”。但要把这件事做好，架构设计是地基。我见过太多项目，功能都跑通了，最后死在架构不合理上——要么云端扛不住并发，要么终端升级一半变砖。

这一章，咱们把OTA系统的三大块拆开揉碎了讲：云端架构管什么、终端架构怎么分、通信协议怎么选。你想想看，这三块要是没对齐，后面全是坑。

2.1 云端架构：升级包管理与设备管理

云端是OTA的大脑。我个人习惯把云端拆成两个核心模块：升级包管理和设备管理。它们各司其职，但又紧密配合。

2.1.1 升级包管理

升级包管理不只是存个文件那么简单。它要管版本、管差分、管分发策略。我在项目中遇到过最头疼的事——升级包版本号搞混了，导致一批设备刷了旧固件，全得返厂。

一个合格的升级包管理系统，至少包含以下能力：

• 版本管理：每个固件包必须有唯一版本号，支持语义化版本（如 v2.1.0）
• 差分生成：支持全量包和差分包，差分算法常用 bsdiff、hdiffpatch
• 签名校验：每个包必须用私钥签名，终端用公钥验签，防止篡改
• 灰度发布：按设备ID、地域、固件版本等维度，逐步推送
• 回滚支持：保留历史版本，升级失败能回退

2.1.2 设备管理

设备管理是云端的“户口本”。每台设备上线，云端得知道它当前固件版本、硬件型号、网络状态、升级历史。没有这个基础，升级就是盲打。

设备管理模块的关键数据模型：

字段	说明	示例
device_id	设备唯一标识	SN20240315001
current_version	当前固件版本	v2.0.3
hardware_rev	硬件版本	B2
upgrade_status	升级状态	idle / downloading / upgrading / success / failed
last_online	最后上线时间	2024-03-15 14:30:00

2.2 终端架构：Bootloader 与 App 分区

终端是OTA的执行者。架构设计的关键在于：升级失败了怎么办？ 嗯，这里要注意，终端架构必须保证“不死”。

2.2.1 Bootloader 的角色

Bootloader 是设备上电后第一个跑的程序。它的职责很简单：决定启动哪个App。在OTA场景下，Bootloader 还要负责校验新固件的完整性，以及回滚。

一个典型的 OTA Bootloader 工作流程：

1. 上电，检查启动标志位（正常启动 / 升级启动 / 回滚启动）
2. 如果标志位是“升级启动”，从下载分区读取新固件
3. 校验固件签名和CRC
4. 校验通过，擦写App分区，写入新固件
5. 校验失败，保持旧App分区不变，设置回滚标志
6. 跳转到App分区执行

2.2.2 App 分区方案

App分区方案决定了升级的可靠性。主流方案有两种：

• 单分区方案：只有一个App分区，升级时直接覆盖。优点是省Flash空间，缺点是升级失败就变砖。
• 双分区方案（A/B分区）：两个App分区，一个运行，一个备用。升级时写入备用分区，成功后切换。优点是安全，缺点是Flash占用翻倍。

我个人强烈推荐双分区方案。虽然多占一倍Flash，但换来的是“永不砖机”。

双分区的Flash布局示例：

Flash地址空间：
0x0000 - 0x3FFF: Bootloader (16KB)
0x4000 - 0x7FFF: 参数区 (16KB)
0x8000 - 0x17FFF: App A (64KB)
0x18000 - 0x27FFF: App B (64KB)
0x28000 - 0x2BFFF: 下载缓存区 (16KB)

2.3 通信协议选型

通信协议是OTA的“血管”。选错了，升级慢、容易断、还费流量。我见过有人用HTTP传固件包，结果在2G网络下传了半小时，最后超时失败。

常见的OTA通信协议对比：

协议	适用场景	优点	缺点
HTTP/HTTPS	宽带、Wi-Fi设备	简单、成熟、支持断点续传	头开销大，不适合低功耗
MQTT	物联网、低功耗设备	轻量、支持QoS、双向通信	传输大文件需分片
CoAP	资源受限设备	基于UDP、极轻量	可靠性不如TCP
私有协议	特殊行业、安全要求高	定制化强、安全性可控	开发成本高、维护难

2.4 整体架构图

下面这张图，把云端、终端和通信协议串在一起。你看一眼，就能理解整个OTA系统的数据流向。