消息队列这个领域，很难有什么革命性的创新

开发 RobustMQ 这段时间，我经常在思考一个问题：消息队列还有什么创新空间？看了很多业界的新产品和技术方向后，我得出一个结论：消息队列这个领域，很难有什么革命性的创新了。不止消息队列，整个基础软件领域都是如此。

这不是悲观，而是现实。基础软件已经进入成熟期，创新更多体现在工程组合和实现优化上，而不是理论突破。

消息队列的技术版图已经很完整

仔细看消息队列领域，你会发现各个方向都有人探索过了。

内存型消息系统有 NATS，追求极致性能，单节点可以处理千万级消息每秒。高性能持久化有 Redpanda，用 C++ 重写 Kafka，声称性能提升数倍。存算分离有 Pulsar，计算和存储独立扩展。对象存储降成本有 AutoMQ 和 Ursa，利用云存储降低 90% 成本。MQTT 和 IoT 场景有 EMQX。传统消息代理有 RabbitMQ 和 RocketMQ。

这些方向基本覆盖了消息队列的所有维度：性能、成本、场景、架构模式。你很难再找到一个全新的、没人做过的方向。

即使是获得 VLDB 2025 最佳工业论文奖的 StreamNative Ursa，本质也是已有技术的组合。无领导者架构来自 Dynamo 和 Cassandra，对象存储作为持久化层 WarpStream 和 AutoMQ 在做，流数据写 Parquet 是数据湖的标准做法，流表二元性是 Kafka Streams 和 Flink 早就在讲的概念。Ursa 的价值不在于提出了新理论，而在于把这些技术工程化地组合在一起，应用到消息队列场景，解决了实际问题。

理论创新已经做得差不多了

这个现象不只存在于消息队列，整个基础软件领域都是如此。

数据库领域，关系模型、事务 ACID、SQL 这些基础已经 40 多年了。最近的"创新"是什么？分布式数据库、云原生、HTAP 混合负载、向量数据库。但本质还是在传统模型上做优化和组合。真正革命性的创新比如 NoSQL，已经是 10 多年前的事了，而且最后发现还是 SQL 好用。

OLAP 领域，列式存储、MPP 架构、向量化执行，这些技术都不新了。ClickHouse、Snowflake、Databricks，本质都是把这些技术组合得更好、实现得更优雅、云原生做得更彻底。没有什么全新的查询模型或存储结构。

API 网关也是类似。反向代理、路由、限流、认证，这些功能几十年没变。Kong、Traefik、Envoy 都是在做更好的实现、更灵活的配置、更云原生的部署，没有人发明一个全新的网关模式。

为什么会这样？因为该探索的方向都探索过了。学术界在过去几十年把基础理论打得很扎实：分布式系统的 Paxos、Raft、两阶段提交，存储系统的 LSM-Tree、B+ Tree，一致性模型的 CAP、PACELC。这些理论已经很完整，很难再有突破性的进展。

而且成熟领域的边界已经很清晰。什么场景用什么技术，业界有共识了。消息队列就是数据流转，数据库就是数据存储和查询，边界很明确。跨界的尝试基本都失败了。用户需求也稳定，基础设施的核心需求这么多年没变：可靠、快速、易用、便宜。

即使是近年来热门的云原生、AI 原生，本质上也是在现有理论基础上，去适配更底层的基础设施做架构上的革新和重新设计。比如云原生强调存算分离、弹性扩展、对象存储，但消息队列的核心理论（日志模型、分区、副本）没有变。AI 原生强调流数据快速进入数据湖仓、实时特征工程，但底层还是那些分布式存储和流处理的理论。变化的是架构设计和技术组合，不是最原始的理论部分。

现在的创新是什么

既然理论创新空间很小，那现在基础软件的创新在哪里？我理解不是工程创新而不是理论创新。主要是三个方向：组合创新、实现创新和场景创新。

组合创新是把现有技术组合得更好。Ursa 把流存储和数据湖仓组合，一份数据既能流式消费又能批量分析。这不是新技术，但解决了数据重复存储和 ETL 管道复杂的问题。这种组合创新的价值，在于简化了用户的技术栈，降低了运维成本。

实现创新是用更好的技术把老问题实现得更优秀。Redpanda 用 C++ 重写 Kafka，利用现代 C++ 的特性和更贴近硬件的优化，达到更高的性能。Iggy 用 Rust + io_uring + thread-per-core，追求单机性能的极致。虽然解决的问题和 Kafka 一样，但实现得更好。语言、运行时、I/O 模型的选择，都是实现层的创新。

场景创新是为新场景优化现有技术。AI 应用需要流数据快速进入数据湖仓做训练，传统的 Kafka + Kafka Connect + Spark 管道太重。Ursa 直接写 Parquet，简化了这个流程。边缘计算需要轻量的消息系统，NATS 的简单部署很适合。这些都是让老技术更好地服务新场景，而不是发明新技术。

工程才是核心竞争力

我个人认为，基础软件很难有革命性创新了。但这不是坏事，而是说明领域已经成熟，创新的重心在转移。

这也是为什么基础软件领域没有 AI 那么性感的原因。AI 还在理论突破阶段，每隔几个月就有新模型、新能力、新应用场景，充满了想象空间。但基础软件的理论已经成熟了，剩下的都是工程体力活：优化性能、处理边界情况、提升稳定性、完善文档、建设生态。这些工作重要但不性感，很难成为热点话题。

学术界的理论工作已经很扎实了，分布式共识、存储结构、一致性模型，这些基础理论很难再有突破。但如何把理论可靠地落地到生产环境、如何处理好各种边界情况、如何在极端条件下保持稳定，这些实践问题仍然需要大量的工程投入。

比如消息队列的核心模型是 append-only log，这个模型已经够好了。但如何把这个模型实现得更快、更稳、更便宜，这是工程问题，也是用户关心的问题。消息队列的应用场景基本就那些，不会凭空出现全新的需求。但如何让多个场景在一个系统里都做好，如何降低场景切换的成本，这是场景整合的价值。

对 RobustMQ 的思考

开发 RobustMQ 时，我也经历过这个心理过程。一开始会想"我能不能做出什么创新"，但研究了各家的方案后发现，该尝试的方向都有人做过了。这时候会有点焦虑：如果没有创新，RobustMQ 的价值在哪里？

后来想明白了，RobustMQ 的价值不需要是"提出了什么新理论"，而是"把消息队列实现得更好、覆盖得更全、用起来更爽"。

具体来说就是组合和工程实现。组合是指解决场景割裂的问题。一个公司可能同时需要 IoT 设备接入（MQTT）、后端数据管道（Kafka）、对象存储集成（降成本）。现在要部署多套系统，运维复杂。如果一个系统能统一搞定，就是组合创新的价值。

工程实现是指用更好的技术栈做得更优秀。用 Rust 保证内存安全和高性能，设计合理的存储层支持灵活扩展，保持代码简洁优雅易于长期维护。这些都是工程能力，不是理论突破，但决定了系统的质量。

我现在的两个原则也是基于这个认识：技术架构的天花板要足够高，市场场景的天花板要足够高。这两个天花板都不是靠"理论创新"来抬高的，而是靠合理的技术选择和清醒的市场定位。

总结

消息队列领域很难有革命性创新，这是现实。数据库、OLAP、网关等基础软件领域也都类似。学术界的理论创新已经做得差不多了，现在的竞争在工程实现和场景组合上。

这不意味着没有机会，恰恰相反。正因为理论已经成熟，工程实现的空间反而更大。谁能把已有技术实现得更好、组合得更合理、适配得更到位，谁就有竞争力。

对于 RobustMQ，不追求理论突破，而是追求工程优秀。用 Rust 实现得更高效，用合理的架构支持长期演进，用多协议统一解决场景割裂。这是组合创新和工程创新，虽然不够性感，但是最务实的路径。

基础软件的价值在于可靠和实用，不在于概念和突破。这是成熟领域的现实，也是长期项目应该坚持的方向。工程做到极致，本身就是创新。