多元协议，总线归一：为何协议灵活性对 AI 智能体至关重要

本文翻译自 Matteo Merli 撰写的博文，原文参见：

https://streamnative.io/blog/one-bus-many-voices-why-protocol-flexibility-matters-for-ai-agents

AI 智能体生态大多是异质的，包含了不同的语言、框架和设备类型，每种都有自己偏好的通信协议。你可能会有使用 MQTT 的边缘 IoT 传感器、使用 REST 或 AMQP 的 Web 服务，以及基于 Kafka 构建的数据管道。如果消息基础设施不够灵活，将所有子模块集成到一个系统中将是一项艰巨的任务。

本文将探讨 Pulsar 的可插拔协议架构如何使多种协议（Pulsar、Kafka、MQTT 等）共存于单个事件总线上。进一步地，与通常需要额外附加组件的 Kafka 单协议模型相比，这种灵活性如何减少系统杂乱性并加速 AI 智能体的开发。

多样化的智能体与协议

设想一个包含多种智能体的智慧城市 AI 系统：

IoT 传感器（交通摄像头、气象站）通过 MQTT 发送数据（MQTT 是 IoT 中常见的轻量级发布/订阅协议）。
使用 Kafka 客户端库编写的后端分析微服务。
对某些消息需求使用 AMQP（RabbitMQ 和其他消息代理背后的协议）的相关系统或边缘设备。
可能还有一些通过 WebSocket 或 REST 通信的移动 App 或 Web 仪表盘。

在传统方案中，你可能需要为分析管道部署 Kafka，为 AMQP 设备部署 RabbitMQ，为传感器部署一个 MQTT 代理（如 EMQX 或 Mosquitto）。然后你需要将这些系统拼接在一起：例如，使用 Kafka Connect 或自定义桥接将 MQTT 数据导入 Kafka，反之亦然，或者让服务订阅多个系统。

这种"多系统"的方法导致了我们所说的系统杂乱性：需要运维和集成多个消息基础设施，则会在边界引入延迟、增加运维成本、插入更多的潜在故障点。

Kafka 使用自己专有的二进制协议进行客户端通信。如果你有非 Kafka 客户端（MQTT、AMQP 等），Kafka 本身无法与它们通信。你通常需要部署辅助服务：

对于 MQTT，一种方法是使用桥接或代理：例如，Confluent（Kafka 的公司）提供了一个 MQTT 代理，可以将 MQTT 转换为 Kafka；或者你运行一个独立的 MQTT 代理，并使用 Kafka Connect 源/接收器在 MQTT 和 Kafka 之间移动数据。
对于 AMQP（如 RabbitMQ），你可能需要通过自定义连接器或应用程序从 RabbitMQ 消费并重新发布到 Kafka（或反过来）。

每种额外的协议通常意味着额外一层或一个服务来进行转换。这不仅增加了复杂性，还可能限制功能。例如，如果你将 MQTT 桥接到 Kafka，MQTT 的持久会话或 Kafka 的 exactly-once 等特性可能无法完美地通过桥接转换。

简而言之，Kafka 的单协议设计意味着，如果并非所有组件都讲 Kafka，你就需要胶水代码或中间件。许多基于 Kafka 的架构最终变成了一个由多个代理拼凑而成的系统：Kafka + 一个消息队列 + 一个 MQTT 代理等，而这正是我们尽可能希望避免的。

Pulsar 的方案

Pulsar 在设计之初就考虑了可插拔协议处理器的概念，能够在同一服务器上原生支持多种协议。在实践中，这意味着你可以配置一个 Pulsar 集群来理解 Kafka 协议、MQTT、AMQP 等，同时使用 Pulsar 的后端来存储和传递消息。Pulsar 社区开发了 KoP（Kafka-on-Pulsar）、MoP（MQTT-on-Pulsar）和 AoP（AMQP-on-Pulsar）等插件。启用这些插件后，Pulsar broker 就能兼容相应的协议。

KoP

Kafka on Pulsar 允许 Kafka 客户端（使用 Kafka API 的生产者/消费者）连接到 Pulsar，就像连接到一个 Kafka broker 一样。Pulsar broker 会监听 Kafka 的端口（如 9092）并理解 Kafka 协议消息。这意味着一个现有应用程序如果编码使用了 Kafka Java 客户端，只需将其指向启用了 KoP 的 Pulsar 集群即可切换到 Pulsar，无需修改代码。它生产/消费的数据实际存储在 Pulsar 的 topic 中，而不是 Kafka 的日志里，但应用程序对此无感。

这一能力极大地简化了迁移工作，团队可以逐步迁移到 Pulsar，而无需一次性重写整个代码库。而且，一旦迁移到 Pulsar，这些应用程序就能获得 Pulsar 的特性，如多租户和在更便宜的存储层上的无限日志保留，而 Kafka 缺乏这些特性或需要附加组件才能实现。

MoP

MQTT on Pulsar 同样适用于 IoT 场景。大量 MQTT 设备可以使用标准 MQTT 协议连接到启用了 MoP 的 Pulsar broker。它们像连接普通 MQTT 代理一样发布和订阅；在底层，Pulsar 将这些消息存储在其分布式日志中。这意味着你不需要为传感器单独部署 MQTT 代理，Pulsar 就能处理。并且所有优秀的 Pulsar 特性（如持久性、地理复制、旧数据的分层存储）也同样适用于 MQTT 流。

如果消费者不在线，MQTT 通常与可能丢失数据的临时代理一起使用。Pulsar 的存储确保即使 IoT 设备离线，数据也能被保留直到设备恢复或在之后重放。

除此之外，Pulsar 的设计允许相对容易地添加其他协议。实际上，还有 WebSocket 支持，甚至与其他系统的集成实验（例如 RocketMQ-on-Pulsar 的集成）。关键在于，Pulsar 的 broker 会将任何传入协议转换为 Pulsar 内部消息格式，反之亦然。所有消息，无论通过何种方式进入，最终都位于同一个持久、可扩展的存储中，并可以被路由到任何消费者。这种统一的总线可以极大地简化 AI 架构。

为什么这对 AI 智能体很重要？

更容易集成异构组件

AI 系统正在快速发展，新的工具或服务都带有自己的接口。使用 Pulsar，你不必将每个组件都限制在一种协议上。如果你的机器人团队喜欢用 MQTT 进行设备遥测，而数据科学团队喜欢用 Spark 消费 Kafka topic，两者都可以与同一个 Pulsar 集群协同工作。

MQTT 设备（通过 MoP）发布到 Pulsar，Spark 作业（通过 KoP）可以订阅这些数据，所有操作都是实时的，无需维护桥接或在两个系统中重复数据。这意味着你可以更快地接入新的智能体组件，学习曲线也更低。开发者可以使用他们已经熟悉的客户端库（Kafka 客户端、MQTT 客户端等）与 Pulsar 交互。这降低了为智能体生态系统做出贡献的各团队的采用门槛。

减少系统杂乱性和成本

运行一个 Pulsar 集群来处理多种消息需求通常比运行 2-3 个独立的系统（Kafka + RabbitMQ + MQTT 代理）更高效，硬件开销更小，需要监控的子系统更少。对架构师而言，这意味着更少的单用途数据孤岛。

Pulsar 可以作为一个"单一事实来源"的事件总线，所有智能体的通信在此汇聚，即使它们使用不同的协议。维护和扩展工作可以聚焦于一个系统 。值得注意的是，Pulsar 的多协议支持并不会显著降低其性能；在许多情况下，与网络和 IO 成本相比，协议转换的开销很小。因此，你可以在不牺牲吞吐量的情况下简化技术栈。

无关协议的数据流

由于 Pulsar 将消息存储与协议解耦，通过一种协议产生的事件可以通过另一种协议被消费。

例如，一个 MQTT 传感器在"sensor/temperature" topic 上发布了一条消息，该消息存储在 Pulsar 中。一个 Kafka 客户端可以（通过 KoP）订阅对应的 Pulsar topic，并获取这些温度事件，就好像它们来自 Kafka 一样。在 topic 这一共同基础之上，这种跨协议的桥接在 Pulsar 中是自动完成的。

在 Kafka 的世界里，进行这样的桥接通常需要编写 Kafka Connector 或一个自定义适配器服务，从一个系统读取并写入另一个系统，这会引入额外的延迟和故障点。Pulsar 的统一方法使得跨异构智能体的数据共享更加实时和直接。

面向未来

借助 Pulsar 的插件模型，当新技术出现时，你不太可能遇到死胡同。如果明天一个新的标准协议在 AI/智能体领域流行起来，可以通过编写一个新的协议处理器来在 Pulsar 上支持它。

相比之下，使用 Kafka，你可能需要等待生态系统构建一个稳定的连接器或网关，或者单独运行那个新系统。

因此，Pulsar 的灵活性可以作为应对技术变化的对冲。这也意味着你可以逐步迁移系统：例如，运行带 KoP 的 Pulsar 来服务你现有的基于 Kafka 的应用程序，并随着时间的推移，根据需要将这些应用程序迁移到使用 Pulsar 的原生 API（以获得更多特性）。在迁移期间，它们可以继续互操作。这种"两全其美"的方法加速了新技术栈的采用，腾讯等公司已经使用 Pulsar 在某些场景下底层替换 Kafka，正是因为他们可以这样做，而无需通知所有上游/下游应用程序同时更改。

假设我们的智慧城市项目最初使用 Kafka 进行城市级别的事件聚合，并使用一个 MQTT 代理处理现场设备。随着项目发展，团队发现维护两个系统很麻烦，他们决定整合到 Pulsar 上。他们启用 MoP，将所有设备指向 Pulsar 端点（使用 MQTT 通信）；设备甚至注意不到区别，除了可能感受到更可靠的性能。他们启用 KoP，重定向现有的 Kafka 客户端（数据接收器、分析作业）到 Pulsar；这些应用程序继续像以前一样运行。

现在所有数据都流经同一个平台。来自设备的数据以更低的延迟（无需中间的桥接）提供给基于 Kafka 的消费者。当一个新的 AI 智能体服务用 Python 开发时，开发者有多种选择，他们可以使用 Pulsar 的原生 Python 客户端。无论哪种方式，他们都能接入相同的实时数据流，降低运维复杂性、提高开发敏捷性（每个团队可以在适合自己的环境中工作，而系统集成人员确保一切通过 Pulsar 连接）。

与之相对，Kafka 本身会推动团队要么编写大量集成代码，要么标准化为一种协议（通常迫使所有东西都进入 Kafka 的轨道）。有些团队最终确实将所有组件标准化为 Kafka（到处使用 Kafka 客户端）。这在某些情况下可行，但在 IoT 或边缘 AI 等场景中，Kafka 的客户端库对于小型设备可能太重，或者它可能缺乏 MQTT 的简单订阅语义或基于 HTTP 的摄取等功能。Pulsar 通过原生拥抱多种标准，避免了这种"一刀切"的陷阱。

关键要点

Pulsar 的多协议支持（KoP、MoP 等）允许单个 Pulsar 集群原生处理 Kafka、MQTT 客户端等。这意味着 AI 智能体和设备可以使用它们选择的协议进行通信，同时共享一个公共事件总线。
更容易的集成和迁移： Kafka 客户端可以无需修改代码就迁移到 Pulsar，并立即利用 Pulsar 的高级特性。MQTT 设备可以直接连接到 Pulsar，并受益于其持久存储和扩展能力。这种灵活性加速了新智能体组件的部署和遗留系统的集成。
降低复杂性： Pulsar 提供了一个统一的基础设施，而不是为 AI 平台的不同部分运行独立的消息系统（并维护它们之间的桥接）。更少的活动部件带来更低的延迟和更简单的运维。
协议透明：在 Pulsar 中，事件不关心它是如何产生或消费的。来自 MQTT 设备的消息可以被 Kafka 客户端消费，反之亦然，通过 Pulsar broker 实现跨生态系统的数据流，无需额外代码。因此，你的 AI 智能体可以更自由地共享信息，这对于构建协作的实时智能系统至关重要。
面向未来且可扩展： Pulsar 的设计预见到了技术环境的多样性。随着你的智能体架构演进，Pulsar 可以根据需要支持新的协议或标准。它给架构师带来信心：采用 Pulsar 意味着采用一个平台，而不仅仅是一个单协议工具。

总结

Pulsar 扮演了"多元协议，总线归一"的角色，提供了一个能够随着你的需求演进的坚实基础组件。它允许 AI 系统中从 IoT 传感器到大数据处理服务的所有参与者通过一个公共媒介进行通信，而无需强迫它们都"讲同一种方言"。

这减少了摩擦并加速了开发，因为你可以为每个任务选择最佳的协议或工具，并依靠 Pulsar 来弥合差距。相比之下，Kafka 更为孤岛化的方法通常意味着额外的层次，或者强制统一到 Kafka 的 API 上，而这并不总是可行的。

对于开发者和系统架构师来说，这种协议敏捷性非常便利，将多样化组件整合到实时 AI 平台中会变得很容易。想接入一个只知道如何写入 Kafka 的新第三方服务？没问题，将其指向 Pulsar KoP 即可；想从现有的 MQTT 代理网络摄取数据？Pulsar 本身就可以是那个代理。最终结果是 AI 智能体的部署周期加速：你花更少的时间编写胶水代码或部署连接器，而将更多时间用于智能体的逻辑和洞察。