第二章：系统架构总览——OTA升级系统的分层架构
好，咱们直接进入正题。OTA升级系统，说白了就是一套让设备“空中换血”的机制。你想想看，手环、手表这类穿戴设备，总不能每次升级都连根数据线吧？那用户体验就太差了。
我个人习惯把整个系统拆成三层来看：云端、通道层、设备端。这三层各司其职，又紧密配合。我最早做这个架构时，就吃过“层与层之间职责不清”的亏，后来重构了两版才稳定下来。
2.1 云端：大脑与仓库
云端是OTA的“总指挥部”。它负责三件事：
- 固件管理：版本号、差分包、全量包的存储与分发
- 升级策略：灰度发布、强制升级、静默升级等规则
- 状态监控：记录每台设备的升级进度、失败原因
嗯，这里要注意。云端不是简单地把文件扔给设备就完事了。我见过不少团队，云端只负责“上传-下载”，结果设备升级失败后，连个日志都查不到。所以，云端一定要有完整的升级链路追踪能力。
核心职责一句话：云端管“发什么、发给谁、发得怎么样”。
2.2 通道层：数据管道与协议适配
通道层是连接云端和设备的“桥梁”。它解决一个核心问题：怎么把固件数据可靠地送到设备上。
常见的通道层实现方式有：
| 通道类型 | 适用场景 | 典型协议 |
|---|---|---|
| 长连接 | 实时性要求高，设备常在线 | MQTT、WebSocket |
| 短连接 | 低功耗场景，设备间歇唤醒 | HTTP/HTTPS |
| 蓝牙网关 | 穿戴设备通过手机中转 | BLE GATT |
我个人建议，穿戴设备优先考虑蓝牙网关模式。为什么？因为穿戴设备本身功耗敏感，直接走蜂窝或Wi-Fi太费电。通过手机App做中转，既省电又能利用手机的稳定网络。
我曾经在一个项目中，设备直接走Wi-Fi下载固件，结果用户手表在升级过程中电量耗尽，直接变砖。后来改成蓝牙网关模式，手机下载完再推给手表，问题就解决了。
避坑指南：通道层一定要做断点续传。我曾经遇到过用户升级到一半，蓝牙断开，结果设备从头开始下载，白白浪费流量和电量。
2.3 设备端：执行者与守护者
设备端是OTA的“最后一公里”。它要完成：
- 固件接收：从通道层获取数据，校验完整性
- 存储管理：把新固件写入Flash的备用分区
- 安全校验：验签、哈希比对，防止恶意固件
- 切换与回滚：更新启动标志，失败时自动回退
这里有个关键设计——双备份区（A/B分区）。说白了，就是设备里存着两份固件：一份正在运行，一份用来接收升级。升级失败？没关系，切回旧版本继续跑。
我刚开始做时，觉得双分区太浪费Flash空间。直到有一次，升级过程中突然断电，设备再也起不来了……嗯，从那以后，我再也不敢省这个空间了。
警告：设备端一定要有“看门狗”机制。如果升级过程中系统卡死，看门狗能强制重启，并触发回滚逻辑。否则，设备可能变成一块“电子砖头”。
2.4 三层交互流程
这三层是怎么配合的？我给你画个简单的流程：
- 设备上报状态：设备启动后，通过通道层向云端报告当前固件版本
- 云端下发指令：云端判断有新版本，返回升级指令和下载地址
- 设备下载固件：设备通过通道层下载差分包或全量包
- 设备校验与安装：校验通过后，写入备用分区，更新启动标志
- 设备重启切换：重启后从新分区启动，并向云端上报升级成功
你想想看，这个流程里任何一个环节出问题，都可能导致升级失败。所以，每一层都要有超时重试和异常处理。
交互核心原则：云端不直接控制设备，只下发指令和资源。设备端自己决定“什么时候升级、怎么升级”。这叫“端侧自治”。
2.5 我的架构建议
最后，分享一点个人经验。做OTA架构时，别想着一步到位。我建议分三步走：
- 第一步：先跑通“云端-通道-设备”的最小闭环，哪怕只支持全量包升级
- 第二步：加入差分升级和断点续传，降低流量消耗
- 第三步：完善安全校验和回滚机制，保证升级不“翻车”
我曾经见过一个团队，一上来就搞复杂的灰度发布和AB测试，结果基础链路都没调通，上线第一天就崩了。所以，先让系统“能跑”，再让它“跑得好”。
好，这一章就到这里。下一章我们深入聊聊云端固件管理系统的设计细节，包括版本号规范、差分包生成策略等。到时候见。