自我审视：我们真的能成为下一代消息基础设施吗？
从项目立项那天起，我们就给 RobustMQ 定了个很大的目标：成为新一代云原生与 AI 原生消息基础设施。听起来挺牛的对吧？但老实说，最近我经常在想一个问题：我们的技术路线真的能撑得起这个目标吗？
所以这篇文章，我想把 RobustMQ 和 Kafka、Pulsar、NATS、Redpanda、Iggy 这些产品放一起，冷静地看看我们到底行不行。不吹牛，也不妄自菲薄，就实话实说。
想了很久之后，我的结论是：方向应该是对的，但能不能做成，真的很难说。
具体来说：
- 云原生这条路，我觉得能走通，但至少要 2-3 年才能看到成果
- AI 原生这个... 坦白讲，我们自己都还没想清楚到底该怎么做
- 多协议统一是核心卖点，成败就看 Kafka 协议能不能做好了
- 性能方面，Rust 确实有优势，但光有语言优势还不够，得拿数据说话
要是非让我说个关键路径的话：先把 Kafka 协议做好 → 找几个愿意尝鲜的用户 → 用 3-5 年时间慢慢建生态 → 专注在 IoT 和大数据融合这种差异化场景。听起来挺长的，但基础软件就是这样。
一、为什么我们会想做这个
先说说为什么会有"下一代"这个想法。
云原生这事儿，确实是趋势
Kafka 那一套计算存储耦合的架构，扩容真的很麻烦，而且还得依赖 ZooKeeper。Pulsar 做了存算分离，但你看它那架构，Broker、BookKeeper、ZooKeeper 三件套，运维起来也不轻松。
云上的资源，计算和存储的定价、扩展方式都不一样。分开之后，该加计算加计算，该加存储加存储，这样才合理嘛。所以我们觉得存算分离肯定是未来的方向。
多协议统一，到底有没有人要？
这个问题我们被问过很多次。我的答案是：真的有人要，而且需求挺强烈的。
你看现在的企业，IoT 设备跑 MQTT，大数据那边用 Kafka，微服务又是 AMQP。维护这么多套系统，成本高不说，数据还到处孤岛。
问题是现有的消息队列基本都是单协议的。Pulsar 是有插件（KoP/MoP/AoP），但还是得额外维护。多协议统一技术上确实难搞，协议语义不一样，性能开销也得控制，但我们觉得这个方向是有价值的。
Rust 这个选择
语言选择上，我们确实纠结了挺久：
Java/JVM（Kafka、Pulsar 在用）的问题是 GC 停顿，延迟会有毛刺。C++（Redpanda）性能确实牛，但内存安全全靠程序员自觉，一不小心就踩坑。Go（NATS）还不错，GC 延迟低，但毕竟还是有 GC。Rust 呢，编译期就能保证内存安全，性能又和 C 一个级别，但生态和招人确实是个问题。
最后我们选了 Rust，不是说它完美，而是觉得它在安全和性能之间找到了个比较好的平衡点。当然，选了 Rust 就意味着要承受生态不成熟、招人难的代价，这个我们是有心理准备的。
"AI 原生"... 说实话我也没想清楚
这是我现在最头疼的一个问题。
AI 场景对消息队列的要求倒是挺清楚：高吞吐、低延迟、存储要灵活、连接器要丰富。但"AI 原生"具体要怎么做？消息队列在 AI 里到底该扮演什么角色？就做个数据管道？还是要深度集成流处理、特征工程、模型推理这些东西？
我看了一圈，业界其实也没有特别成功的案例。Kafka 那边是通过 Streams、Connect 这些外围组件来支持 AI 场景的，这条路倒是走通了。
二、冷静看看我们自己
说完外面的趋势，该回头看看我们自己了。
哪些地方做得还行
Rust + 存算分离这个组合
Rust 给我们带来了零 GC、内存安全这些好处，但招人真的难，生态也还在建设中。
架构上我们设计了三层：Broker（协议路由）、Journal Server（持久化）、Meta Service（元数据）。跟 Pulsar 比，我们用 Raft 替代了 ZooKeeper，少了个依赖。但这套架构在生产环境里到底表现怎么样，资源效率如何，运维复不复杂，说实话还得真正跑起来才知道。
插件化存储这块，我们支持内存、SSD、S3、HDFS 好几种后端。听起来挺灵活的，但实际做起来坑不少：
首先是性能，加了抽象层肯定会有损耗。然后是一致性，S3 是最终一致性，本地磁盘是强一致性，怎么在上层统一？还有故障处理，不同存储坏的方式都不一样。最后是运维，支持这么多存储，测试和排查问题的复杂度得翻好几倍。
灵活性确实有了，但代价也实实在在。
单一二进制
这个我们还挺满意的。一个文件搞定，开发测试方便，边缘场景也能跑，生产环境部署也简单。
面临的挑战
多协议统一真的太难了
协议语义映射是最头疼的：MQTT 的 QoS、Kafka 的分区、AMQP 的路由，这些东西概念完全不一样，怎么统一？性能开销怎么控制？灵活性和高性能之间怎么平衡？
现在的进度是：MQTT 做完了，Kafka 在开发中，AMQP 和 RocketMQ 还在计划里。
但说实话，Kafka 协议真的比我们想的复杂太多了。Consumer Group、Rebalance、事务、幂等性... 每一个都不简单。这个协议要是做不好，多协议统一基本就是空谈了。
生态差距，这个最残酷
对比一下就知道差距有多大：
- Kafka：300+ 连接器，Streams API，各种工具应有尽有
- RobustMQ：8 个连接器，流处理还没有，工具链刚起步
Pulsar 花了 6-7 年才把生态建起来。我们估计也得 3-5 年。这几年怎么保持项目活力？怎么吸引贡献者？怎么找到愿意尝鲜的用户？这些都是问题。
三、"云原生 + AI 原生"这个目标，靠谱吗？
现在到了最关键的部分了。
云原生这块
架构设计上应该是契合的，存算分离、支持 K8s，单一二进制在 Serverless 场景冷启动也快。
但生态集成还差得远。Service Mesh、Observability、GitOps 这些，Kafka 和 Pulsar 都已经深度集成了，我们还刚起步。而且这套架构在生产环境到底行不行，其实还得验证。
我的判断是：方向应该是对的，但要达到 Kafka/Pulsar 那个成熟度，至少还得 2-3 年。
AI 原生... 这个我真不知道怎么办
这是我现在最迷茫的地方。
我们现在有的是一些数据连接器（MySQL、MongoDB 这些），但这和"AI 原生"有什么关系？这些连接器本质上就是通用的数据集成，谈不上针对 AI 场景优化。
而且，"AI 原生"到底该怎么做？消息队列在 AI 里该干什么？业界也没有特别成功的案例啊。
我在想，要不要干脆把这个定位改一下？不说"AI 原生"，就说"为 AI 场景优化的高性能消息队列"，专注在低延迟、高吞吐、灵活存储、连接器这些基础能力上。这样目标会更明确一些。
多协议统一，成败就看 Kafka 了
这是我们的核心卖点，也是最大的风险。
架构设计上是支持多协议的，MQTT 做出来了也证明方案是可行的。但 Kafka 协议比 MQTT 复杂太多了。要是 Kafka 做不好，多协议统一这事儿基本就黄了。
如果 2026 年能把 Kafka 做好，这个方向就算验证成功了。要是只能做个半成品，那就比较尴尬了。
性能，光说 Rust 还不够
Rust 零 GC 确实是优势，理论上延迟会更稳定。但消息队列性能不只是看语言，网络、磁盘、并发模型、序列化这些都有影响。
我们现在缺的是：
- 和 Kafka/Pulsar 在相同硬件上对比的基准测试
- 长期跑下来的 P99、P999 延迟数据
光说语言有优势没用，得拿数据说话。
四、前面还有几座山要爬
说了这么多问题，那接下来怎么办？
协议完整性
Kafka 协议真的太复杂了。Consumer Group、Rebalance、事务、幂等性... 做子集吧，重度用户不满意；做完整兼容吧，成本又太高。AMQP 那边也一样，路由模型映射、多语言 SDK 兼容性，都是硬骨头。
我们现在的想法是：迭代着来，先把核心功能做好，把自动化测试建起来，研发资源尽量往这边投。但说实话，这个过程会很漫长。
生态建设
连接器、监控（Prometheus/Grafana/Jaeger）、管理工具（Dashboard/CLI）... 这些都得一个个做。
Kafka 有 Confluent 撑腰，Pulsar 有 Apache 基金会。我们要是能进 Apache 孵化，品牌会好一些，但最终还是得靠项目本身有吸引力。
计划是：核心功能先做好，然后慢慢扩展，建社区激励机制，持续投入。但这个周期会很长。
生产案例
这个是鸡生蛋蛋生鸡的问题：没案例企业不敢用，企业不用就没案例。
我们打算搞个早期采用者计划，找一些创业公司、非核心业务、学术机构先试起来。我们会全力支持，快速响应需求，有了成功案例就积极宣传。
目标是先拿下 1-2 个标杆场景，比如 IoT 平台或者实时数据管道，建立起用户社区，然后靠口碑传播。
竞争压力
消息队列市场已经很成熟了，Kafka 是老大。Redpanda 性能好部署简单，发展也很快。Iggy 也是用 Rust 写的，也在持续开发。
我们肯定不能跟 Kafka 正面硬刚，得找差异化的点：多协议、IoT、边缘计算这些方向。
五、到底什么最关键？
想了这么多，我觉得最关键的有几点：
技术执行力
这个是基础中的基础。把 Kafka 协议做好、性能优化做好、稳定性提升。
MQTT 做完了，Kafka 在开发中。这个要是做不好，后面都白搭。
市场定位
不能什么都想做。得找到自己的根据地，专注在 IoT + 大数据融合、边缘到云这些场景。
跟 Kafka 在所有场景硬拼，那是找死。
生态建设
连接器目标 50+，监控工具、管理控制台这些都得做。现在才 8 个连接器，工具链也刚起步。
这是个持久战，得投入 3-5 年。
生产案例
这个太重要了。有了 1-2 个标杆案例，企业顾虑就会少很多。
现在项目还早期，案例还很少。得赶紧找几个愿意试的用户。
写在最后
写完这篇文章，心情挺复杂的。
欣慰的地方在于：技术方向应该是对的。Rust、存算分离、插件化存储、多协议统一，这些都符合行业演进方向。而且目前来看，同时具备"多协议"、"存算分离"、"Rust"、"单一二进制"、"插件化存储"这五个特征的开源项目，好像就我们一个，差异化还是挺明显的。
但焦虑的地方也很明显：执行难度真的太大了。MQTT 做完只是从 0 到 1，接下来从 1 到 10 要把协议做完整、性能验证好、找到标杆案例，这三个缺一不可。从 10 到 100 更是要持续建生态、打品牌，至少 3-5 年，而且还有很多不确定性。
"AI 原生"这个定位，我觉得确实需要重新想一下。与其说那些虚的，不如务实点，就说"为 AI 场景优化的高性能消息队列"，专注做好基础能力。
如果你想试试 RobustMQ：
- 2025 年：非关键业务可以试试，特别是 MQTT 场景
- 2026 年：如果 Kafka 协议做好了，中小规模生产环境应该可以用
- 2027+ 年：再考虑大规模替换现有系统
这不是谦虚，是实话。技术创新本来就需要时间，生态建设更是如此。
Kafka 用了十年成为行业标准，Pulsar 用了七年建起生态。我们才刚起步，前面还有无数坑等着。但也正是因为难，做成了才有意义。
每写一行代码，每实现一个协议，每优化一次架构，都是在往前走。这个过程肯定漫长，肯定艰辛，但只要方向对、坚持住、社区支持，应该能走到想去的地方。
感谢关注 RobustMQ 的朋友，感谢贡献者，感谢提建议的用户。我们一起，慢慢把这条路走下去。
说实话，现在我们正在爬第一座山，还在山脚。但也还好，至少已经开始爬了。
项目地址
如果觉得这篇文章还行，欢迎给我们个 Star。
2025-01-29 / RobustMQ 团队