2. OTA系统架构设计：云端架构、车端架构、通信链路设计、安全架构

好，咱们进入正题。OTA系统架构，说白了就是解决一个问题：怎么安全、可靠地把新软件送到车上，还能让它跑起来。

我做了这么多年OTA，见过太多“看起来很美”的方案。有的云端设计得花里胡哨，结果车端跑不动。有的通信链路看着挺快，一上高速就断连。嗯，这里面的坑，我一个个给你讲透。

2.1 云端架构：大脑怎么长

云端是整个OTA的指挥中心。我个人习惯把它拆成三层：

• 接入层：负责跟车端握手。说白了就是负载均衡、API网关。我建议用Kong或Nginx，别自己造轮子。
• 业务层：核心逻辑在这。包括升级包管理、车辆管理、任务调度、版本控制。
• 存储层：存升级包、存车辆信息、存升级日志。对象存储用MinIO或S3，数据库用MySQL+Redis。

这里有个避坑指南：升级包要分片存储。我曾经遇到一个2GB的升级包，直接上传到服务器，结果网络波动导致重传了3次。后来改成4MB一个分片，断点续传，问题就解决了。

2.2 车端架构：终端怎么接

车端架构，我把它分成四块：

模块	职责	我踩过的坑
OTA Client	跟云端通信，下载升级包	别用HTTP长连接，车机网络不稳定，容易断
升级管理器	校验包、解压、备份、刷写	一定要做双分区备份，否则刷死了救不回来
状态上报	实时反馈升级进度	上报频率别太高，5秒一次就够了
回滚机制	升级失败自动恢复	回滚脚本要写在ROM里，别写在可擦写区

你想想看，车端最怕什么？刷写过程中断电。我建议用A/B分区方案：A区跑当前系统，B区刷新系统。刷完了切过去，万一不行还能切回来。

2.3 通信链路设计：路怎么走

通信链路，说白了就是数据怎么从云端到车端。我建议用这个链路：

云端 → CDN → 4G/5G基站 → T-Box → 车载网关 → OTA Client → 升级管理器

为什么要加CDN？因为升级包大，直接走服务器带宽扛不住。我做过测试，1000辆车同时下载，服务器带宽直接打满。加了CDN之后，带宽成本降了70%。

这里有个细节：通信协议选MQTT还是HTTP？

• 控制指令：用MQTT。轻量、实时、支持推送。云端下发升级指令，车端秒级响应。
• 数据下载：用HTTPS。可靠、支持断点续传、安全性高。

我曾经在一个项目里全用MQTT，结果升级包传输经常丢包。后来改成MQTT传指令、HTTPS传数据，问题就解决了。说白了，别让一个协议干所有事。

2.4 安全架构：怎么防黑客

安全是OTA的命门。我见过最严重的事故，是黑客伪造了升级包，导致整车系统瘫痪。嗯，从那以后，我对安全架构就特别较真。

我建议的安全架构分四层：

1. 传输安全：TLS 1.3加密，证书双向认证。别用自签名证书，容易被中间人攻击。
2. 包体安全：升级包用RSA-2048签名，车端验签。我习惯用哈希校验+数字签名双重保护。
3. 存储安全：车端存储升级包要加密。密钥存在SE（安全芯片）里，别放文件系统。
4. 执行安全：刷写前校验签名，刷写中校验哈希，刷写后校验完整性。

最后说一个我踩过的坑：回滚也要验签。有一次我们升级了安全补丁，结果回滚到旧版本，安全漏洞又回来了。后来我规定：回滚操作必须经过云端授权，车端不能自主回滚。

好了，这就是OTA系统架构的核心。云端、车端、通信、安全，四块缺一不可。你想想看，哪个环节出了问题，升级都可能失败。下一章我们讲升级包制作，到时候再细聊。