第二章：OTA系统架构——云端、车端与通信协议
好，咱们进入正题。OTA升级这事儿，说白了就是一套「远程送快递」的系统。你得有发货方、收货方，还得有靠谱的运输路线。今天我就把这套架构拆开，跟你聊聊我这些年踩过的坑和总结的经验。
2.1 云端架构：大脑和仓库
云端是整个OTA系统的指挥中心。我个人习惯把它分成三层：
- 业务层：负责用户管理、升级策略、权限控制。比如「只给高配车型推送」、「先让内测用户升级」这类逻辑。
- 存储层：存放固件包、差分补丁、版本历史。我建议用对象存储，比如S3或MinIO，别用数据库存大文件，血的教训。
- 分发层：处理CDN加速、断点续传、负载均衡。嗯，这里要注意，车机网络环境差，分发策略得做细。
核心要点：云端设计时，一定要考虑「灰度发布」能力。我曾经在项目里没做灰度，结果一个bug导致全量回滚，那叫一个狼狈。
2.2 车端架构：接收与执行
车端这边，我把它拆成四个模块：
- OTA Client：负责跟云端通信，下载包、校验签名。说白了就是个「快递员」。
- Update Manager：管理升级流程，比如先升级哪个ECU、要不要重启。这是「项目经理」。
- Rollback Handler：回滚机制。万一升级失败，得能退回去。我建议至少保留两个版本。
- State Machine：状态机。记录当前升级到哪一步了，防止断电后「失忆」。
你想想看，车机不像手机，它得考虑功耗、网络不稳定、甚至行驶中升级。所以车端架构一定要轻量、健壮。
避坑指南：我曾经遇到过车机升级到一半，用户熄火走人了。结果下次启动时，系统卡在「半升级」状态。后来我们加了「断电续传」和「状态持久化」，才算解决。
2.3 通信协议：HTTPS vs MQTT
这里我重点聊聊协议选择。很多新手会问：「直接用HTTP不行吗？」
我的回答是：分场景。
| 协议 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| HTTPS | 大文件下载（固件包） | 安全、可靠、支持断点续传 | 连接开销大、不适合频繁小数据 |
| MQTT | 状态上报、指令下发 | 轻量、实时、支持QoS | 不适合大文件传输 |
我个人习惯的做法是：MQTT做控制通道，HTTPS做数据通道。什么意思呢？
- 云端通过MQTT告诉车机：「有新版本了，去下载吧」。
- 车机收到指令后，用HTTPS去下载固件包。
- 下载过程中，通过MQTT上报进度：「下载到50%了」。
这样既保证了实时性，又兼顾了大文件传输的可靠性。
注意：MQTT的QoS级别要选对。QoS 0可能丢消息，QoS 2又太慢。我一般用QoS 1，配合去重逻辑，效果不错。
2.4 差分升级原理：省流量才是王道
差分升级，说白了就是「只传变化的部分」。你想想看，一个固件包可能500MB，但每次只改了几行代码。全量下载？太浪费了。
差分升级的原理其实不复杂：
- 生成差分包：在云端，用旧版本和新版本做对比，生成一个「补丁文件」。
- 传输差分包：车端只下载这个补丁，可能只有几十MB。
- 本地合并：车端用旧固件 + 补丁，合成新固件。
常用的差分算法有bsdiff、hdiffpatch等。我建议用bsdiff，它在二进制文件上表现不错。
# 生成差分包（云端执行）
bsdiff old_firmware.bin new_firmware.bin patch.bin
# 合并差分包（车端执行）
bspatch old_firmware.bin new_firmware.bin patch.bin
关键点：差分升级对车端算力有要求。合并过程需要CPU和内存，低端芯片可能吃不消。我曾经在某个项目里，车机合并差分包花了20分钟，用户都等睡着了。后来我们优化了算法，才降到5分钟以内。
2.5 我的实战建议
最后，给你几个我这些年总结的要点：
- 先做小范围验证：别一上来就全量推送。先找几台测试车，跑一轮再说。
- 做好回滚预案：升级失败不可怕，可怕的是回不去。我建议保留两个版本的备份。
- 监控要到位：升级过程中的日志、状态、异常，都得实时上报。不然出了问题你都不知道从哪查起。
- 考虑网络波动：车机网络不稳定，断点续传、重试机制是标配。
嗯，今天就聊到这儿。下一章咱们聊聊升级策略的具体设计，比如怎么分批次、怎么控制风险。到时候见。