消息平台演进之路：为什么融合是必然趋势

本文内容来自EMQ中文社区。

消息系统是现代数字基础设施的核心枢纽。向外，它连接着数以百万计的 IoT 设备、车辆和传感器；向内，它承载着微服务之间的异步通信、实时数据管道和事件驱动架构；而随着大模型时代的到来，AI Agent 正在成为消息系统需要连接的新一类参与者——它们既要实时获取设备和业务数据来感知与决策，也要将决策结果下发到设备和业务系统。可以说，消息系统直接决定了企业数据流通与智能协作的能力和效率。

经过多年的发展，市场上涌现了大量的消息系统，它们各自专注于不同的应用场景，面向不同的协议生态。然而，当一个企业同时需要多种消息能力时，各种问题便随之而来。

消息系统烟囱化

当我们回顾大多数企业的消息基础设施演进历程，大概率会看到一个熟悉的模式：

• 需要接入 IoT 设备，增加了 MQTT Broker——因为 MQTT 是 IoT 领域的事实标准，轻量、省电、支持海量长连接。
• 需要构建事件流与日志管道，增加了 Kafka——因为 Kafka 的分区模型和持久化能力是大规模流处理的最佳选择。
• 需要做业务异步与任务分发，增加了 RabbitMQ——因为 AMQP 协议的灵活路由和消息确认机制天然适合工作队列场景。

这些选择在做出的时候都是合理的。不同场景、不同时期、不同团队，基于各自的需求做出了各自最优的技术选型。

问题在于：随着业务规模增长和系统复杂度上升，这些「各自最优」的选择叠加在一起，逐渐演变成了一座座技术烟囱——各团队自建、各自运维、各自监控、各自一套权限体系。

烟囱化带来的四重痛点

当消息系统烟囱化成为既成事实，一系列深层问题开始浮现。   

数据孤岛，跨系统互通困难

不同消息系统之间难以互通，跨系统的数据打通往往依赖复杂的配置和脆弱的同步管道。

最典型的场景：IoT 设备通过 MQTT 上报遥测数据，数据分析团队需要用 Kafka 消费这些数据做分析处理。中间怎么办？写一个桥接程序，从 MQTT Broker 订阅消息，转发到 Kafka Topic。反过来，如果 Kafka 侧产生了告警需要推送到设备端，又得再建一条反向链路。

每一条桥接链路都是一个需要开发、测试、部署、监控、维护的程序。它们不创造业务价值，却往往是很多问题之源，消耗着工程团队大量的时间和精力。   

成本飙升

多套消息系统意味着多套集群、多套存储、多倍跨可用区流量。

每套系统都需要独立做高可用部署，都需要独立的容量预留。尤其是 Kafka 这样基于分区副本的系统，在多可用区部署场景下，跨 AZ 的数据复制流量本身就是一笔可观的开支。再加上为应对流量尖峰预留的冗余容量，实际的资源利用率往往远低于理想水平。

三套系统的成本，绝不只是一套系统的三倍——因为每增加一套系统，还会带来额外的网络互联、数据同步和运维人力成本。   

交付速度变慢

当一个新业务需要使用消息能力时，它面临的不仅仅是「调一个 API」这么简单。

它需要先完成技术选型（用哪套消息系统？），然后打通网络、申请权限、配置监控告警，最后才能开始写业务代码。如果涉及跨系统数据消费，还要加上桥接程序的开发与联调时间。

「发送和接收消息」这件本应简单的事情，被基础设施的复杂度严重拖慢。   

可靠性风险增大

系统越多，故障域越多。链路越长，排障越难。

桥接程序和同步任务本身就是脆弱的环节——它们通常不像核心消息系统那样有经过详尽测试的高可用保证，却承载着关键的数据流转。一旦桥接程序出现延迟或故障，上下游系统都会受到影响，而排查问题时要在多套系统之间来回切换，定位根因的成本极高。

行业趋势：从「专用系统」到「融合平台」

消息系统正在经历的变化，并不是孤例。回顾其它基础设施领域的演进，我们会发现一个共同的规律：从专用到融合统一，是基础设施成熟化的必然方向。

• 数据库领域：从早期的 OLTP 和 OLAP 严格分离，到 HTAP（混合事务与分析处理）数据库的兴起，一套系统同时承载事务处理和分析查询已经成为可能。
• 可观测性领域：从日志系统（ELK）、指标系统（Prometheus）、链路追踪（Jaeger）各自独立，到统一可观测性平台将三者整合，一套平台覆盖所有可观测性需求正在成为主流。
• AI 领域：早期的文本、图像、语音模型各自独立发展，而如今前沿的基础模型已经走向多模态融合，一个模型同时具备文本、图像、视频、音频的理解与生成能力。

消息系统也在经历同样的演进：从 MQTT、Kafka、RabbitMQ 等多种专用系统共存，走向一个融合平台统一承载多种消息范式。

融合消息平台应该长什么样？

如果我们从第一性原理出发，重新设计一个面向当下和未来的消息平台，它应该具备哪些关键特质？

它不仅要解决已有的 IoT、微服务、事件流等需求，还要能够自然地接纳 AI Agent 这类新型参与者。AI Agent 需要实时订阅设备和业务数据来感知环境、做出决策，也需要将指令和结果投递到设备和下游系统。如果为此再引入一套新的消息系统，只会让烟囱化问题雪上加霜。这进一步要求消息平台具备统一的多模型、多协议能力。   

多模消息引擎：一套系统，多种范式

统一平台的核心前提是在一个系统内同时支持多种消息范式，例如：

• Pub/Sub：多订阅者广播，实时分发，适合实时通知、事件广播等场景。
• Stream：事件流与日志管道，支持持久化存储与回放消费，适合数据管道、审计日志、事件溯源。
• Queue：竞争消费，支持 ACK、重试与死信队列，适合任务分发、削峰填谷。

更重要的是，平台的消息引擎应该是可扩展的——随着业务场景的演进和 AI 等新需求的出现，能够灵活引入新的消息范式，而不是固定在几种模型上。

要实现这种多模型与可扩展性，协议与消息模型必须解耦。用户可以用自己熟悉的协议接入（无论是 MQTT、Kafka 还是 AMQP），平台内部按业务语义选择最合适的消息模型。同一套治理能力——权限、配额、监控、审计——覆盖所有模式。   

原生跨模型/协议互通

在当前的多系统架构下，要让 MQTT 的数据流入 Kafka，或者让 Kafka 的事件推送到 MQTT 设备，往往需要部署专门的桥接程序或同步管道，配置复杂、链路脆弱。

统一消息平台应该从根本上消除这种割裂：不同协议接入的消息，天然就能互通。MQTT 设备发布的数据，Kafka Consumer 可以直接消费；Kafka 写入的告警，MQTT 订阅者可以实时接收；AI Agent 可以直接订阅设备数据流进行实时分析，并将决策结果推送到业务系统——无需桥接程序，无需同步任务，无需额外配置。   

云原生弹性架构

传统消息系统大多采用有状态分区架构，扩容或节点故障恢复时往往需要经历漫长的分区再平衡（Rebalance），运维复杂度高，故障恢复不可预测。

面向云原生时代的统一消息平台，计算层与存储层应该彻底分离、独立扩缩容。计算节点应该是无状态的，可以随时增减和替换，做到秒级弹性伸缩和快速自愈，不再受限于分区迁移和数据再平衡。   

基于对象存储的低成本持久化

传统消息系统通常依赖本地磁盘或块存储做消息持久化，容量需要提前规划，单价较高，长期保留和历史回放的成本压力尤为突出。

随着对象存储技术的成熟和成本的持续下降，消息持久化应该转向对象存储。对象存储容量按需扩展、单价远低于块存储，天然适合消息数据的长期保留与历史回放，能够大幅降低存储成本。   

原生多租户

企业级消息平台通常需要服务多个团队和业务线。多租户能力应该是平台的内建特性，而非事后附加——每个租户拥有独立的资源空间、访问控制和配额管理。平台团队统一治理，业务团队按需自助使用，既保证安全隔离，又降低使用门槛。

随着 AI Agent 大规模涌现，未来消息系统的使用者将不仅仅是当前的人和应用，还有大量自主运行的 Agent，这让多租户隔离与治理能力变得尤为重要。

融合之后，能带来什么？

当消息基础设施从多套技术烟囱整合为一个统一平台，企业将在四个维度获得显著收益。

• 更低的 TCO：降本来自三个方面的协同——弹性架构减少容量预留（架构降本）；低成本存储降低持久化开支（存储降本）；一套平台替代多套集群，统一治理（运维降本）。
• 更简单的架构：一套平台覆盖 Pub/Sub、Queue、Stream 等多种消息需求。团队用熟悉的协议接入，跨协议互通无需胶水代码和桥接程序。新业务对接消息能力的路径从「选型 – 打通 – 运维」缩短为「接入即用」。
• 更强的弹性与可靠性：云原生架构带来秒级扩缩容能力，节点故障快速自愈，故障恢复路径更短、更可预测。
• 打破数据孤岛：IoT 数据可以直接进入事件流处理管道，不再需要中间的搬运环节。业务事件可以被分析系统、告警系统、审计系统直接订阅消费。跨系统集成从「搬运数据」变为「直接订阅」。

消息基础设施的下一个十年

随着 IoT、微服务、实时数据处理等场景的爆发，以及 AI Agent 作为新一类消息参与者的快速崛起，企业对消息系统的依赖越来越深，场景越来越多样。而在这个过程中，我们也积累了大量的技术债——多套系统并存、数据孤岛林立、运维成本居高不下。

好消息是，云原生架构的成熟、存储技术的演进、以及行业对平台化治理的共识，让统一消息平台从愿景变为现实。消息基础设施正在迎来一次范式跃迁：从「多套工具各司其职」走向「一个平台统一承载」。

这不仅仅是技术架构的演进，更是企业数据流通与智能化能力的质变——让团队把时间用在业务创新上，而不是「打通消息系统」上；让 AI Agent 能够直接接入统一的数据流，实时感知、自主决策、即时行动。