1. 课程导入

Apollo Cyber RT 是百度 Apollo 自动驾驶平台自研的运行时框架，位于操作系统与上层自动驾驶应用之间，承担着节点调度、通信中间件、时间同步、资源管理与确定性执行等关键职责。它不是简单的“消息总线”，而是一套面向自动驾驶高并发、低延迟、强实时场景设计的完整运行时。理解 Cyber RT 的定位，是学习性能与可靠性工程的第一步：只有先看清它在整个系统中的位置，才能判断哪些性能指标由它决定，哪些可靠性问题需要从它入手排查。

一、Cyber RT 的定位：自动驾驶的“运行时底座”

在自动驾驶系统中，感知、定位、预测、规划、控制等模块以组件（Component）形式运行，彼此之间需要高频交换点云、图像、障碍物、轨迹等数据。Cyber RT 的核心价值在于：用统一的调度与通信机制，把这些模块组织成可预测、可观测、可调优的运行时。它向下管理线程、协处理器、共享内存与网络，向上提供节点、通道、服务、参数、定时器等抽象。

与通用机器人框架相比，Cyber RT 更强调确定性调度和零拷贝通信。例如，感知模块输出的点云数据量极大，如果每次通信都做序列化与内存拷贝，延迟和 CPU 开销会迅速累积。Cyber RT 通过共享内存与协处理器机制，让大数据在进程间以“传递句柄”的方式流转，从而把通信开销压到较低水平。

二、发展历程：从 ROS 到 Cyber RT 的演进

Apollo 早期版本基于 ROS 构建，ROS 生态丰富、开发效率高，但在自动驾驶场景下逐渐暴露出调度不确定、通信开销大、缺乏全局资源视图等问题。随着 L4 级自动驾驶对实时性和可靠性的要求提升，Apollo 团队自研了 Cyber RT，并在 Apollo 3.5 前后逐步替代 ROS 成为默认运行时。

Cyber RT 的演进大致经历了三个阶段：第一阶段解决“能跑”，提供节点、通道、服务等基础通信能力；第二阶段解决“跑得稳”，引入协处理器、共享内存、调度配置与时间同步；第三阶段解决“跑得可观测、可调优”，完善日志、监控、性能剖析与故障诊断工具链。今天我们要学习的性能与可靠性工程，正是第三阶段的核心内容。

三、性能与可靠性工程的学习目标

本课程不是泛泛介绍 Cyber RT 的 API，而是聚焦“性能”与“可靠性”两条主线。学习目标可以概括为四个层次：

• 看得懂：理解 Cyber RT 的调度模型、通信模型、时间模型与资源模型，能读懂调度配置、通道配置和协处理器配置。
• 测得出：掌握延迟、抖动、吞吐、CPU 占用、内存增长等关键指标的测量方法，能搭建可复现的性能测试环境。
• 调得动：能根据瓶颈定位结果调整调度策略、线程优先级、通信模式与共享内存配置，并验证调优效果。
• 守得住：能设计降级、熔断、超时、重试与监控告警机制，让系统在异常场景下仍能安全运行。

四、整体知识框架与实战路线

课程整体分为五个模块：基础篇、通信与调度篇、性能工程篇、可靠性工程篇、实战与复盘篇。基础篇建立运行时认知；通信与调度篇深入通道、服务、协处理器与线程模型；性能工程篇围绕延迟、吞吐、资源占用展开测量与调优；可靠性工程篇覆盖异常处理、降级策略、监控告警与故障注入；实战篇则用完整案例串联全部知识。

五、典型场景与常见误区

一个典型场景是：感知模块在拥堵路段点云数据量激增，规划模块开始出现周期性延迟抖动。表面看是规划模块“变慢”，实际可能是通信通道排队、协处理器线程被占满，或共享内存拷贝退化为序列化传输。性能工程的价值就在于把“感觉慢”变成“可定位的指标异常”。

常见误区有三个：第一，只关注平均延迟，忽略 P99 与抖动，而自动驾驶安全往往取决于最差情况；第二，盲目增加线程数，导致上下文切换和锁竞争加剧，反而降低吞吐；第三，把可靠性等同于“加 try-catch”，忽视超时、降级、熔断与监控的系统性设计。

# 典型性能观测入口示例
cyber_monitor                 # 查看通道频率与延迟
cyber_recorder info demo.record  # 查看记录文件中的通道与消息量
top -H -p $(pgrep -f mainboard)  # 查看 Cyber RT 进程内线程 CPU 占用

从本章开始，我们将沿着“定位—测量—调优—守护”的路线逐步深入。请先建立两个习惯：一是用数据说话，任何性能结论都要有指标支撑；二是用系统视角看问题，任何一个模块的延迟都可能是上下游、调度器、内核与硬件共同作用的结果。