3、差分升级系统架构：客户端-服务器模型、差分包生成流程、差分包应用流程、OTA服务器设计要点
好，咱们进入第三章。这一章我打算把差分升级的骨架给你搭起来。说白了，就是搞清楚整个系统里谁负责干什么，数据怎么流转，以及每个环节要注意哪些坑。
我刚开始做OTA方案时，总想着先把差分算法搞定，结果架构没想清楚，后面联调时改得头皮发麻。你想想看，如果客户端和服务器之间的交互模型都没定好，差分包生成得再漂亮也白搭。
3.1 客户端-服务器模型：谁该干什么
差分升级系统，本质上是一个瘦客户端 + 胖服务器的架构。为什么这么设计？因为嵌入式设备的算力和存储都有限，你不能指望MCU去干比对、压缩这些重活。
| 角色 | 核心职责 | 资源约束 |
|---|---|---|
| OTA服务器 | 版本管理、差分包生成、策略下发、日志收集 | 算力充足、存储大、网络稳定 |
| 客户端（设备端） | 固件采集、差分包下载、校验、备份、应用 | Flash小、RAM小、CPU主频低 |
我个人习惯把客户端的状态机画清楚。设备端一般跑这几个状态：
- 空闲态：等待服务器指令，或者定时轮询。
- 下载态：接收差分包，边收边校验。
- 就绪态：差分包收完了，等待用户确认或定时触发。
- 升级态：执行差分还原，写入备份区或直接覆盖。
- 回滚态：升级失败，从备份区恢复旧固件。
关键原则：客户端永远不要主动决定“我要升级哪个版本”。它只负责执行服务器下发的任务。这样你才能在服务端统一控制灰度发布和回滚策略。
3.2 差分包生成流程：服务器端怎么干活
差分包生成，是整个系统里最烧脑的一步。我见过不少团队把这一步和客户端升级混在一起写，结果代码耦合得一塌糊涂。
正确的做法是：生成流程完全在服务器端完成，生成产物就是一个二进制差分包，客户端只管“下载+应用”。
具体流程如下：
- 获取旧固件：从版本仓库里拉取目标设备当前运行的版本（v1.0）。
- 获取新固件：拉取你要升级到的目标版本（v2.0）。
- 执行差分算法：用 bsdiff、hdiffpatch 或自研算法，对比新旧固件，生成差分数据。
- 压缩差分数据：用 zlib、lzma 或 lz4 进一步压缩，减少传输量。
- 打包成差分包：在差分数据前加上包头，包含版本号、固件大小、校验值、算法标识等元信息。
- 签名：用私钥对差分包签名，防止中间人篡改。
我的经验：生成流程里最容易忽略的是“对齐处理”。新旧固件如果链接地址不同，差分算法会产生大量冗余数据。我建议在生成前先做一次地址重映射，把两个固件拉到同一个基址上再比对。
差分包的结构，我一般这样设计：
+----------------------------+
| 包头 (Header) |
| - 魔数 (Magic Number) |
| - 版本号 (v1.0 -> v2.0) |
| - 原始固件大小 |
| - 差分包大小 |
| - 校验算法标识 |
| - 签名值 |
+----------------------------+
| 差分数据 (Delta Data) |
| - 控制块 (Ctrl Block) |
| - 数据块 (Data Block) |
| - 额外块 (Extra Block) |
+----------------------------+3.3 差分包应用流程：客户端怎么还原
客户端拿到差分包后，要做的事情其实比生成简单，但容错要求更高。因为设备一旦刷挂了，可能就变砖了。
我建议的还原流程：
- 校验包头：检查魔数、版本号是否匹配，签名是否有效。
- 解压缩：如果差分包是压缩的，先解压到RAM缓冲区。
- 读取旧固件：从当前运行区或备份区读取旧固件数据。
- 执行差分还原：按照差分算法，逐块将旧固件 + 差分数据 → 新固件。
- 写入目标分区：将还原出的新固件写入Flash的升级分区。
- 完整性校验：对整个升级分区做哈希校验，确保数据无误。
- 切换启动：更新启动标志，指向新固件分区，然后复位。
曾经踩过的坑：我在一个项目里，客户端在还原过程中突然断电。重启后，旧固件被部分覆盖，新固件又不完整，设备直接变砖。从那以后，我强制要求所有客户端必须保留一个完整的旧固件备份，直到新固件校验通过才能释放。
这里有一个内存管理的要点：差分还原需要同时操作旧固件、差分数据和新固件。如果RAM不够大，就得用流式处理——边读旧固件、边还原、边写入Flash，不能一次性全加载到内存。
3.4 OTA服务器设计要点
服务器设计得好不好，直接决定了你能不能优雅地管理成千上万台设备。我见过一些团队把OTA服务器写成一个简单的文件下载服务，结果设备多了之后，版本混乱、升级失败率飙升。
下面是我总结的几个核心设计要点：
| 设计维度 | 要点说明 | 常见误区 |
|---|---|---|
| 版本管理 | 每个固件版本要有唯一ID、发布时间、兼容设备列表 | 用文件名当版本号，解析时容易出错 |
| 灰度发布 | 支持按设备ID、地域、固件版本分批推送 | 一次性全量推送，出问题无法止损 |
| 断点续传 | 客户端记录已下载偏移量，服务器支持Range请求 | 差分包较大时，网络波动导致反复重传 |
| 升级策略 | 支持静默升级、用户确认、定时升级三种模式 | 强制静默升级，用户不知情可能引发投诉 |
| 日志回传 | 客户端升级完成后上报结果码、耗时、失败原因 | 不上报日志，出问题只能靠猜 |
我个人习惯在服务器端维护一个升级任务表，每条记录包含：任务ID、目标版本、设备列表、灰度比例、状态（待执行/执行中/已完成/已暂停）。这样你可以随时暂停某个任务，或者回滚到上一个版本。
核心思想：服务器是大脑，客户端是手脚。大脑要足够聪明，手脚要足够可靠。所有复杂的决策逻辑都放在服务器端，客户端只做最精简的执行和容错。
3.5 整体架构图
下面这张图，把客户端、服务器、差分包生成和应用的关系串起来了。你可以把它当作本章的骨架图来理解。
从这张图你可以看到，整个系统分为三个层次：服务器端负责生成和调度，客户端负责下载和应用，数据流则贯穿始终。每一层都有自己独立的模块，模块之间通过明确定义的接口通信。
嗯，这一章的内容就到这里。架构搭好了，后面我们才能放心地深入差分算法和具体实现。记住一句话：架构设计决定了系统的上限，代码实现只是把上限变成现实。