2、通信机制核心：发布-订阅模型、服务-客户端模型、数据分发服务（DDS）基础概念
通信机制，说白了就是自动驾驶系统的「神经网络」。
我做了这么多年中间件，见过太多团队在通信上栽跟头。有的延迟太高，有的数据丢了，有的扩展性差到没法用。嗯，今天我们就来聊聊通信机制的三个核心模型。
2.1 发布-订阅模型：解耦的艺术
发布-订阅模型，是我个人最常用的通信方式。它的核心思想很简单：发送方和接收方不需要知道彼此的存在。
举个例子。你开车时，GPS模块不断发布位置信息。规划模块、控制模块、感知模块，谁需要谁订阅。GPS模块根本不用管谁在听，订阅者也不用管GPS模块是谁。
核心特点：
- 解耦：发布者和订阅者互不感知
- 一对多：一个发布者，多个订阅者
- 异步：发布者不用等订阅者处理完
我在项目中遇到过一个问题：某个传感器数据更新频率很高，但订阅者处理速度跟不上。结果消息队列越积越多，内存爆了。
怎么解决？加个「频率限制」或者「丢旧保新」策略。说白了，就是告诉中间件：如果订阅者忙不过来，就丢掉最旧的消息，保证实时性。
避坑指南：
我曾经在某个项目中，所有模块都用发布-订阅模型。结果调试时根本不知道消息流到哪里去了。后来我养成了一个习惯：每个消息都加个「消息ID」和「时间戳」，方便追踪。
2.2 服务-客户端模型：请求与响应
发布-订阅模型虽然好用，但有些场景它搞不定。比如：控制模块需要查询地图模块「前方100米有没有红绿灯」。
这种「一问一答」的场景，就得用服务-客户端模型。
你想想看，服务端提供能力，客户端发起请求，然后等待响应。就像你去餐厅点菜：你（客户端）点菜（请求），厨师（服务端）做菜（处理），然后端上来（响应）。
| 特性 | 发布-订阅 | 服务-客户端 |
|---|---|---|
| 通信模式 | 异步 | 同步/异步 |
| 数据流向 | 单向 | 双向 |
| 典型场景 | 传感器数据流 | 远程过程调用 |
| 超时处理 | 不需要 | 必须考虑 |
我记得有一次，某个服务响应特别慢，客户端一直阻塞等待，导致整个系统卡死。后来我加了个超时机制：如果3秒内没响应，就返回错误，客户端自己处理异常。
注意：
服务-客户端模型虽然直观，但别滥用。如果每个小功能都用服务调用，系统会变得又慢又脆弱。我建议：高频数据用发布-订阅，低频控制用服务调用。
2.3 DDS基础概念：数据分发服务
说到DDS，很多人觉得它很复杂。其实说白了，DDS就是发布-订阅模型的「豪华升级版」。
为什么需要DDS？因为自动驾驶对通信的要求太苛刻了：
- 延迟要低到毫秒级
- 可靠性要高到不丢包
- 扩展性要强到支持上百个节点
DDS的核心概念有三个：
- 域（Domain）：所有通信都在一个域内进行。不同域之间隔离，就像不同房间的人听不到对方说话。
- 主题（Topic）：每个数据流都有一个主题名。发布者和订阅者通过主题匹配。
- QoS策略：这是DDS最强大的地方。你可以控制可靠性、持久性、生命周期等。
QoS策略示例：
// 可靠性策略
RELIABILITY = RELIABLE // 保证送达
RELIABILITY = BEST_EFFORT // 尽力而为
// 持久性策略
DURABILITY = VOLATILE // 不保存历史数据
DURABILITY = TRANSIENT_LOCAL // 保存最近的数据我在项目中遇到过一个问题：两个模块用DDS通信，但一个用RELIABLE，一个用BEST_EFFORT。结果发送方以为数据可靠送达了，接收方却丢了一部分。嗯，这里要注意：QoS策略必须两端一致。
个人经验：
我建议初学者先别碰DDS的复杂配置。先用默认QoS跑通流程，再根据需求调整。我曾经一上来就调了十几个QoS参数，结果系统跑不起来，排查了三天才发现是某个参数冲突了。
2.4 三种模型的选择策略
你可能会问：这三种模型，到底该用哪个？
我的经验是：
- 传感器数据流：用发布-订阅。比如摄像头图像、激光雷达点云。
- 控制指令：用服务-客户端。比如「刹车」「转向」。
- 跨域通信：用DDS。比如不同ECU之间的数据交换。
说白了，没有银弹。每种模型都有自己的适用场景。我见过有人非要用DDS做简单的传感器数据流，结果配置复杂到没人敢维护。
最后说一句：通信机制的选择，直接影响系统的性能和可维护性。别图省事，也别过度设计。找到平衡点，才是真本事。