未来的消息应该是什么样子：我自己的一些思考

我一直在想一个问题：未来的消息基础设施应该是什么样子。

Kafka 已经统治了十年，RabbitMQ 更久。难道下一个十年还是它们吗？我始终持怀疑态度。不是说它们不好，恰恰相反，它们在各自的场景里已经做到了极致。但正因为做到了极致，才更应该问：然后呢？

如果答案是"继续在现有维度上优化"，更高的吞吐、更低的延迟、更便宜的存储，我认为这条路已经快走到头了。不是不能再优化，而是边际收益越来越小。百万 TPS、毫秒级延迟，今天谁做不到呢？只要架构不犯根本性错误，大家都能做到。这是标配，不是优势。你能做到，我也能做到，所有认真做这件事的人都能做到。再快 30% 对绝大多数场景来说没有本质区别。

所以要想看清未来的消息应该是什么样子，首先思考角度本身要变。不是在现有维度上继续卷，而是要问：当这些维度都已经被优化到极致之后，下一步该往哪走？特别是 AI 时代到来、Agent 这个变量涌入之后，整个通信的格局和以前完全不一样了。

下面是我的一些思考，不一定对，但确实是我反复想了很久的东西。

关于传统指标

Kafka 当年赢在吞吐量，百万级 TPS 碾压了同时代所有对手，性能是它的核心差异化竞争力。RabbitMQ 赢在路由灵活和可靠投递，EMQX 赢在海量连接，各有各的看家本领。

但今天再看这些指标，我觉得它们的角色变了。

硬件在过去十年发生了巨大变化。NVMe SSD 的随机写性能、百 G 网络带宽、内存单价持续下降，这些进步意味着，只要架构设计不犯根本性的错误，任何一个新系统的性能基线都不会差。性能不再是你的优势，是你必须有的。如果你今天做一个新的消息系统，还在反复强调"我比 Kafka 快 30%"，说明你还在用旧地图找路。

同样的，云时代教会了所有人关注成本。存算分离、分层存储、按量付费，这些思路已经是共识了。Kafka 的存储成本问题催生了 Pulsar 的分层存储，Confluent 做了 Kora 架构，AWS 做了 MSK Serverless。成本优化也不再是创新，是基本功。

性能、吞吐、延迟、成本、稳定性，这些在今天的技术环境下，应该是默认就有的。不是卖点，而是准入门槛。

但我发现包括我自己在内，讨论消息队列的时候，开口往往还是吞吐多少、延迟多少、成本怎么优化。不是说这些不重要，而是我们太习惯这套思维了。消息就是 Topic/Partition，消息就是 Append Only 模型，消息就是 Kafka，然后好像就到头了。

存算分离是一个进步，存储上对象存储是一个进步，那再进一步呢？当这些传统指标都变成默认值之后，真正的问题才浮出水面。

当性能和成本都不再是差异化竞争力的时候，核心出发点应该转向什么？我认为是降低企业的系统复杂度。今天企业的消息基础设施是什么状况？同时跑着 Kafka 做流处理、RabbitMQ 做业务解耦、EMQX 做 IoT 接入、NATS 做微服务通信。四套系统、四套集群运维、四套监控告警、四个技术栈的学习曲线。每个产品单独看都很好，但企业为了覆盖所有场景不得不叠加它们，这个叠加本身就是巨大的成本。而且这个成本很隐蔽，机器费用看得见，人的精力看不见。半夜三点被告警叫醒，要在三套系统之间排查消息到底丢在哪个环节，这种成本不会出现在任何报表上，但真实存在，而且随着系统叠加越来越沉重。

其实大家都在往这个方向走。不管是 Tableflow、Topic 集成 Iceberg，还是各种 Lakehouse 的尝试，本质上都是想让企业的基础设施更简单。方向是对的。但我总觉得差了点什么。差的不是技术能力，是思维方式还没完全转过来。很多尝试还是在现有框架里做整合，优化的还是性能和成本，只是换了个姿势。

所以在非传统指标的维度上，我认为"让企业少跑几套系统"才是最有价值的事情。不是做一个更快的 Kafka，而是做一个能覆盖 Kafka + RabbitMQ + MQTT Broker 场景的统一基础设施。你消除的不是性能差距，是架构复杂度。

关于多协议

业界讲多协议支持，叙事通常是"兼容你现有的 Kafka 客户端"、"支持 MQTT 3.1.1 和 5.0"。这个理解我觉得太小了。

多协议的真正意义不是兼容，是消除。A 协议进、B 协议出，意味着原来需要一个 Kafka 集群加一个 MQTT Broker 加一个消息桥接中间件的架构，现在一套就够了。IoT 设备用 MQTT 把数据接入，后端用 Kafka 协议做流处理，微服务之间用 AMQP 或 NATS 协议通信，全部跑在一个底层引擎上，共享存储，共享运维。

这件事的难度不在于"支持多个协议"，协议解析本身是确定性的工程工作。真正难的是：不同协议的语义模型差异很大。Kafka 是基于 offset 的日志追加模型，AMQP 是基于 Exchange/Queue 的路由模型，MQTT 是基于 Topic 的发布订阅模型。把这些不同的语义模型统一到一个存储引擎上，既要保证各协议的语义正确性，又要保证性能不因为抽象层增加而显著劣化，这是真正的架构难题。

但这件事值得做，因为一旦做到，企业的消息基础设施复杂度会发生质的变化。不是优化 10%、20%，是从四套系统变成一套。

关于 Agent 的加入

前面说的还是在"系统间异步通信"的框架里。如果只看到多协议统一，你做的是一个更好的消息队列，但本质上还是消息队列。

真正让我觉得需要重新审视整个赛道的，是通信的参与者在变。

传统消息队列有一组根深蒂固的假设：生产者和消费者是确定的、长期存在的服务实例。Topic 或 Queue 是架构师在系统设计阶段就规划好的。消息的流向是静态的，从 A 到 B，从 B 到 C，画在架构图上，跑在线上，几年不变。

Agent 时代打破了这些假设。

Agent 是动态创建和销毁的。一个 Agent 可能只存在几秒钟完成一个任务就消失了，也可能运行几个月处理一个长期项目。两个 Agent 之间的通信关系是即兴建立的，没有人提前规划过这条链路。一个 Agent 同时是消息的发送者和接收者，它收到的消息可能触发新 Agent 的创建，新 Agent 又会发起新的通信。更重要的是，消息不再是平等的，有些消息是普通的异步通知，有些是需要立即处理的紧急指令，有些是可以延迟但不能丢失的关键数据。

用 Topic/Queue 模型去硬套这种通信模式，能用，但别扭。因为底层抽象不对。

传统消息队列的基本抽象是"管道"，消息从一端流入，另一端流出。管道是被动的、无状态的，它不关心谁在用它。但 Agent 通信需要的可能是一种"通信实体"的抽象，每个参与者拥有自己的通信空间，消息不是流过管道，而是投递到实体的空间里。实体有生命周期，可以创建也可以销毁。消息有优先级，紧急的可以插队。通信关系是动态建立和解除的，不需要提前规划。

这不是要替代管道模型。传统的系统间解耦场景，比如订单系统发消息给库存系统、日志采集器发数据给数据管道，管道模型依然是最优解，也不需要改变。但 Agent 通信是一个全新的场景，硬用旧抽象会付出不必要的复杂度代价。

一个面向未来的消息基础设施，应该同时支持这两种模式。底层共享存储和运维体系，上层按场景提供不同的通信抽象。就像数据库既提供 SQL 接口给传统关系型查询，也提供 Document API 给灵活的文档型场景，底层是同一个引擎，上层是不同的接口。

关于做难的事

传统维度都被优化到极限了，边际效应卷没了，能优化的都优化完了。那接下来该做什么？做难的事。

容易的事情大家都在做，也都做到差不多了。接下来能做的、值得做的，都是以前被认为"太难、不划算"的事情。

比如语言选择。过去十几年，消息中间件领域的主流选择是 Java 和 Go。Kafka 是 Java + Scala，RabbitMQ 是 Erlang，NATS 是 Go，Pulsar 是 Java。选这些语言有很现实的原因：开发速度快、生态成熟、招人容易。性能上虽然不如 C/C++ 和 Rust，但"够用"了。

但"够用"是旧时代的判断标准。当性能成为默认准入门槛的时候，你应该追求的是极致，而不是够用。Rust 和 C++ 在内存管理、零拷贝、系统调用效率上的优势是语言层面决定的，不是靠 JVM 调优能弥补的。以前不选 Rust 的核心原因是"开发太慢，招不到人"。但 AI 时代这个约束条件在快速松动，AI 辅助编码在很大程度上弥补了 Rust 的开发效率劣势。当语言的学习成本和开发速度不再是硬瓶颈，为什么不追求更极致的底层性能和内存安全？

比如多协议语义统一。把 Kafka 的日志模型、AMQP 的路由模型、MQTT 的发布订阅模型统一到一个存储引擎上，这件事以前没人做，不是因为没人想到，是因为太难了。但"难"不是"不该做"的理由，恰恰相反，难的事情才有壁垒。

比如为 Agent 设计原生的通信抽象。不是在现有消息队列上加个 SDK 就完事，而是从底层重新思考通信实体的生命周期、优先级模型、动态路由。这件事甚至没有成熟的参考架构可以借鉴，需要自己蹚出来。

AI 改变了很多事情的成本结构。以前不可行的路径，现在变得可行了。以前"太难不划算"的判断，现在需要重新评估。

最后的话

我在想这些问题的过程中有一个很深的感受：如果一直抱着互联网时代、云时代的思维去看消息基础设施，是看不清楚下一步的。

因为那些思维框架里的核心变量，吞吐、延迟、成本、弹性，已经被优化到了极致。在这些维度上继续卷，你能做的只是微调。真正的突破需要跳出来，重新审视：谁在通信、怎么通信、通信的生命周期是什么。这些问题的答案和十年前不一样了。

我不否认现有产品的牛逼。我们永远是站在巨人的肩膀上往前走，成为一个更大的巨人，然后再被下一个人踩在肩膀上。这就是基础设施。一代一代往前推，没有哪个是永恒的，但每一代都把整个行业往前推了一大步。

下一步是拓宽维度本身。横向，让一个基础设施覆盖多种通信场景，真正降低企业的系统复杂度。纵向，为 Agent 时代的新通信参与者提供原生的抽象支持。

这些都是难的事情。但越难的事情越值得做。容易的事情大家都在做，最后只能卷价格和运营。难的事情少有人做，但一旦做到，壁垒就是天然的。

把自己固定在"消息"或"流"的单一视角里，是想不清楚未来的。需要退一步，用"通信基础设施"的高度重新审视这个领域。

我觉得最可怕的不是做错，而是不敢想。基础设施总要往前走的。答案也许还不完全清晰，但方向，我觉得是这个方向。