4.2 组合式开发

4.2 组合式开发

本节摘要：默认情况下每个节点住在自己的进程里，跨进程通信要经过序列化与网络栈。组合式开发提供另一种部署形态：多个节点装进同一进程，通信走共享内存，序列化开销直接消失。本节讲清组件与普通节点的代码差异、动态加载与静态组合两种方式、进程内通信的触发条件，以及它换来的性能与付出的调试代价之间的权衡。

同一个功能的两种住法

先把一个概念辨析做掉：组件（component）不是新的节点类型，而是同一份节点代码的另一种打包方式。普通节点编译成可执行文件，组件编译成动态库，由容器进程加载。功能一模一样，区别只在"住在哪"以及由此带来的一切。本节的任务是把"住在哪"这件事的利弊算清楚。

一、组件的代码形态：去掉 main 函数

写组件的代码改动小到令人意外：把 main 函数删掉，节点类注册成可加载组件即可。

// 与普通节点唯一的代码差异：继承 rclcpp_components 注册宏
#include "rclcpp_components/register_node_macro.hpp"

class MyCameraProcessor : public rclcpp::Node {
public:
    explicit MyCameraProcessor(const rclcpp::NodeOptions& options)
        : Node("camera_processor", options) {
        sub_ = create_subscription<Image>("image_raw", 5,
            std::bind(&MyCameraProcessor::on_image, this, _1));
        pub_ = create_publisher<Image>("image_processed", 5);
    }
private:
    void on_image(const Image::SharedPtr msg) { /* 处理并发布 */ }
    rclcpp::Subscription<Image>::SharedPtr sub_;
    rclcpp::Publisher<Image>::SharedPtr pub_;
};

RCLCPP_COMPONENTS_REGISTER_NODE(MyCameraProcessor)
​

注意构造函数签名：组件必须接受 NodeOptions 参数——容器靠它传入进程内的配置。注册宏做的事是把类信息写进动态库的"目录页"，容器按名字找到并实例化。同一个节点类可以同时提供可执行入口与组件注册，部署时再决定用哪种形态，代码不用分叉。

二、加载方式：动态与静态

动态加载用现成的容器进程，运行时按名字装组件，不改一行部署代码就能调整进程划分：

# 起一个容器进程（可以同时给容器自己传参数）
ros2 run rclcpp_components component_container

# 另一终端：往容器里装两个组件
ros2 component load /ComponentManager my_pkg my_camera_processor
ros2 component load /ComponentManager my_pkg my_detector
ros2 component list          # 查看容器里已装的组件
​

静态组合把组件链接进自定义的可执行文件，适合交付形态固定的场景——好处是产物单一、启动即全部就位，坏处是改进程划分要重新编译：

// 自己的 main 里静态组装
int main(int argc, char** argv) {
    rclcpp::init(argc, argv);
    rclcpp::executors::SingleThreadedExecutor exec;
    exec.add_node(std::make_shared<MyCameraProcessor>(rclcpp::NodeOptions()));
    exec.add_node(std::make_shared<MyDetector>(rclcpp::NodeOptions()));
    exec.spin();
}
​

两种方式的选择逻辑很简单：调试期用动态加载，进程划分可以随试验随调；产线交付用静态组合，产物确定且少一个"容器进程"的间接层。两者共用同一份组件代码。

三、进程内通信：什么时候真的会走快路

组合的红利是进程内通信（intra-process）：同进程的两个节点之间，消息不再序列化、不再过网络栈，发布者把消息的共享指针直接递给订阅者——对图像这类大消息，开销从"每次几毫秒的拷贝"降到"一次指针传递"。但这条快路有触发条件，踩不准就白组合了：

• 发布与订阅的 QoS 必须兼容且使用支持进程内的选项（发布者与订阅者都默认即可，但 reliability 为 best_effort 的订阅收 reliable 的发布这类跨 QoS 组合走不了）；
• 消息必须是进程内可传递的类型——ROS2 的类型化发布订阅默认就支持；
• 订阅回调注册时要用支持进程内的接口（rclcpp 里即 NodeOptions 开启 use_intra_process_comms）。

// 开关就藏在这一行
rclcpp::NodeOptions options;
options.use_intra_process_comms(true);   // 本节点的通信优先走进程内
​

图 4-1：同一对节点的两条通信路径

四、工程取舍：性能与隔离的天平

组合不是免费午餐，天平的另一端是故障隔离。多进程形态下，识别节点崩溃只是它自己死，处理节点照常运行；同进程形态下，一次段错误带走整个容器。所以组合的适用判据不是"性能不好就组合"，而是"这两个节点本来就是一个逻辑单元吗"。相机驱动加即时的图像裁剪节点，组合是自然的——它们共享生死；驱动与远程监控节点之间，保持进程边界是明智的——监控不该有拖垮驱动的资格。

调试透明度是另一个隐性代价：进程内的通信不再出现在某些网络层的观测工具里，ros2 topic 的部分统计对进程内路径失明。遇到"数据明明在发、工具看不见"的困惑，先确认这两个节点是不是被你组合进了同一进程。

💡 关键直觉：进程是故障的防火墙，组合是拆防火墙换性能。拆哪一堵，取决于两侧的信任关系，而不是哪边慢。

本节要点回顾

• 组件是打包方式不是节点类型：去 main、接受 NodeOptions、注册宏，代码改动极小；
• 动态加载用于调试期，进程划分随时可调；静态组合用于交付，产物确定；
• 进程内快路要主动开启：use_intra_process_comms，QoS 兼容是前提；
• 组合拆掉的是故障防火墙，按"逻辑单元"决定组合边界，不按性能焦虑决定；
• 进程内通信会让部分网络观测工具失明，排查时先确认部署形态。

节点的状态与住处都定了，下一节解决最后一个编排问题：按什么顺序、用什么方式把它们拉起来。