消息系统是现代数字基础设施的核心枢纽。向外，它连接着数以百万计的 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 能够直接接入统一的数据流，实时感知、自主决策、即时行动。
3 月 20 日，见证一次关键发布
如果说过去十年，消息系统解决的是"连接万物"的问题；那么下一个十年，真正的挑战是：如何在一个融合的平台上，让万物、应用与 AI 协同流动。
我们在前文讨论的多模消息引擎、原生跨协议互通、云原生弹性架构、对象存储持久化以及多租户治理，并不是停留在概念层面的架构设想，而是一套已经完整落地、面向未来十年的消息平台能力。
3 月 20 日，在杭州举办的 EMQ Tech Day 上，我们将首次对外完整展示这一全新消息平台的设计理念、核心架构与关键能力。如果你正在面临多套消息系统并存的复杂架构，如果你正在为跨协议数据流转和桥接链路所困扰，或者你正在思考如何让 AI 能力更自然地融入实时数据体系，这场活动值得你到场参与。