2. OTA系统架构设计：云端架构、车端架构、通道架构（HTTP/MQTT）

好，咱们进入第二章。这一章我打算聊聊OTA系统的骨架——架构设计。

很多人一上来就写代码，结果云端和车端对不上，通道动不动就断。我早期吃过这个亏，后来才明白：架构设计没想清楚，后面全是坑。

这一章，我会把OTA架构拆成三块来讲：云端、车端、还有连接它们的通道。说白了，就是谁发指令、谁执行、怎么传数据。

2.1 云端架构：大脑和指挥中心

云端是OTA的大脑。它不直接刷写ECU，但它管着所有升级包的存储、分发、策略控制。

我个人习惯把云端拆成四个核心模块：

• 升级包管理模块：负责差分包的生成、版本管理、签名。嗯，签名这块特别容易漏，我见过有团队忘了给包签名，结果车端校验直接拒了。
• 车辆管理模块：维护每辆车的VIN、当前软件版本、ECU拓扑。说白了，你得知道哪辆车该升哪个包。
• 策略引擎：决定什么时候推、推给谁、要不要分批。比如“先推100台试跑，没问题再全量”。
• 日志与监控：收集升级结果、失败原因。我曾经靠这个模块定位过一个“升级到99%卡死”的bug，最后发现是某个ECU的flash写满了。

2.2 车端架构：执行者与看门狗

车端架构，说白了就是车上的软件怎么接住云端的指令，然后老老实实把ECU给刷了。

车端通常分三层：

1. OTA Client（主控）：跟云端通信，下载包，校验完整性，然后调度刷写。我建议这个模块跑在独立的域控制器或网关里，别跟娱乐系统混在一起——你想想看，万一车机卡死了，OTA还能继续跑。
2. 刷写代理（Update Agent）：负责跟具体ECU通信。每个ECU可能有不同的刷写协议（UDS、DoIP、甚至私有协议）。代理层把这些差异封装掉。
3. 回滚与安全模块：刷失败了怎么办？必须能回滚到上一个可用版本。我遇到过最惨的一次，刷到一半断电了，还好回滚机制救了回来。

2.3 通道架构：HTTP vs MQTT，怎么选？

通道就是云端和车端之间的“水管”。选错了，要么流量爆炸，要么延迟高到没法用。

目前主流就两种：HTTP 和 MQTT。我分别说说我的理解。

2.3.1 HTTP：简单直接，适合大包下载

HTTP是请求-响应模式。车端主动问：“有包吗？”云端答：“有，给你。”

优点很明显：

• 实现简单，HTTPS自带加密
• 支持断点续传（Range头），适合下载几百MB的升级包
• CDN加速方便，全球分发没问题

缺点呢？

• 服务器没法主动推消息。车端得轮询，费流量
• 长连接开销大，不适合频繁小数据交互

我一般建议：升级包下载用HTTP。原因很简单，大文件传输HTTP最成熟。

2.3.2 MQTT：轻量级，适合指令下发

MQTT是发布-订阅模式。云端发一条消息，所有订阅的车都能收到。

优点：

• 协议头极小（最小2字节），省流量
• 支持QoS（0/1/2），保证消息必达
• 服务器可以主动推，车端不用轮询

缺点：

• 传输大文件效率低（Payload有限制）
• 需要额外搭建Broker，运维成本高一点

我个人习惯：指令下发、状态上报用MQTT。比如“开始升级”、“升级进度30%”这种小数据，MQTT再合适不过。

2.4 混合架构：HTTP + MQTT 搭配使用

别纠结二选一。实际项目中，我几乎都是用混合架构。

场景	推荐协议	原因
升级包下载	HTTP/HTTPS	大文件、断点续传、CDN
升级指令下发	MQTT	低延迟、主动推送
升级进度上报	MQTT	小数据、频繁交互
日志上传	HTTP	文件较大，需要可靠传输

举个例子：云端通过MQTT告诉车“有新版本，去下载”。车端收到后，用HTTP去CDN拉包。下载完，再用MQTT上报“下载完成，准备刷写”。

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

最后，我总结几个架构设计时容易踩的坑：

• 要不要用CDN？ 如果车辆遍布全国甚至全球，必须用。我见过自己搭下载服务器的，结果高峰期带宽打满，升级全失败。
• 车端要不要缓存升级包？ 建议缓存。万一刷写失败，不用重新下载。但注意存储空间，别把车机存爆了。
• 通道要不要加密？ 必须。HTTPS + MQTT over TLS，这是底线。OTA被中间人攻击可不是闹着玩的。
• 要不要支持离线升级？ 如果车辆经常进地库没信号，建议车端预下载包，等有信号时再确认升级。

嗯，架构设计这块，说白了就是权衡。没有完美的方案，只有适合你项目的方案。我早期总想一步到位，结果越做越复杂。后来学乖了：先跑通核心流程，再逐步优化。

下一章，我会聊聊升级包的生成和差分算法。到时候见。