3. Cyber RT架构总览

Cyber RT 是 Apollo 面向自动驾驶场景自研的中间件，它并不是一个单纯的通信库，而是一套把“计算调度、通信传输、数据缓存、组件生命周期、参数配置、时间同步”统一封装起来的运行时框架。理解 Cyber RT 的架构，关键是先看清它的分层：上层是开发者直接使用的组件与节点，中间是调度、通信、服务发现等核心运行时，底层则依赖共享内存、网络协议栈、操作系统线程与时钟等基础能力。只有把这三层的关系理顺，才能理解为什么 Cyber RT 能在高并发、低延迟、强实时的自动驾驶任务中稳定工作。

一、整体分层架构

从纵向看，Cyber RT 可以划分为四层。最上层是应用与组件层，包括感知、定位、规划、控制等模块，它们以 Component 的形式注册到框架中，通过 Reader/Writer 收发消息。第二层是通信与调度层，包含 Node、Channel、Service、Scheduler、Transport 等，负责消息路由、线程调度和跨进程传输。第三层是核心运行时层，包括 Component 管理、参数服务、服务发现、时间与日志等基础设施。最底层是系统与硬件抽象层，依赖共享内存、UDP/TCP、epoll、CPU 亲和性以及时钟源。

这种分层的意义在于：上层业务只关心“我订阅什么、发布什么、什么时候被调度”，而不需要关心底层是共享内存还是网络传输；中间层则根据配置自动选择最优传输方式，并在调度器上做优先级与资源隔离。

二、核心模块划分

Cyber RT 的核心模块可以按职责归纳为五类。第一类是通信模块，包括 Node、Channel、Reader、Writer、Service、Client，负责点对点与发布订阅两种通信模式。第二类是调度模块，包括 Scheduler、Processor、Task，支持 CLASSIC、CHOREOGRAPHY、RT 等调度策略，用于把不同优先级的任务分配到不同线程。第三类是组件模块，Component 是业务逻辑的载体，支持定时触发、消息触发和混合触发。第四类是基础服务模块，包括参数服务、服务发现、日志、时间、Record 回放。第五类是工具与监控模块，如 cyber_monitor、cyber_recorder、cyber_visualizer。

三、数据流与控制流

Cyber RT 中同时存在两条主线。数据流是“消息驱动”的：Writer 将消息写入 Channel，Transport 根据配置选择共享内存或网络传输，Reader 收到消息后触发 Component 的回调。控制流是“调度驱动”的：Scheduler 根据任务优先级和触发条件，把回调任务放入对应 Processor 的队列，由工作线程执行。两者交汇在 Component 的 Proc 回调上。

以感知到控制为例：激光雷达驱动发布点云，感知 Component 订阅后执行检测，输出障碍物消息；规划 Component 订阅障碍物与定位，计算轨迹；控制 Component 订阅轨迹，输出底盘控制指令。整个过程由调度器保证控制链路优先级最高，避免被大计算量的感知任务阻塞。

# 查看通道数据流
cyber_monitor

# 录制关键通道
cyber_recorder record -c /apollo/perception/obstacles /apollo/planning

# 回放并观察调度
cyber_recorder play -f demo.record -l

四、与 Apollo 其他模块的集成关系

Cyber RT 位于 Apollo 软件栈的中间层，向下对接驱动与硬件抽象，向上支撑各算法模块。它与 Apollo 其他部分的集成主要体现在三方面：一是模块加载，各模块以 Component 形式注册到 Cyber RT，由框架统一启动和调度；二是消息契约，模块之间通过 proto 定义的消息在 Channel 上通信，接口清晰、可录制、可回放；三是工具链协同，Dreamview、cyber_monitor、cyber_recorder 等工具直接读取 Cyber RT 的通道与记录文件，形成调试闭环。

五、常见误区与复盘

• 误区一：把 Cyber RT 当成纯通信库。它同时承担调度、组件管理和参数服务，忽略调度会导致实时性问题。
• 误区二：所有通道都用网络传输。同机通信应优先使用共享内存，减少拷贝和延迟。
• 误区三：组件回调里做耗时操作。回调应快速返回，重计算应拆分任务或放入独立线程。
• 复盘要点：先画清数据流与控制流，再定位是通信问题还是调度问题，最后用录制回放验证。