04: RobustMQ 产品层面的思考与定位

RobustMQ 是基于 Rust 构建的新一代高性能多协议消息队列。愿景是成为新一代云原生与 AI 原生消息基础设施。它不是简单的"又一个消息队列"，而是面向 AI 时代和云原生需求，对消息队列进行的一次重新思考和设计。

自 RobustMQ 项目启动之初，我们便持续审视自身是否陷入技术思维的局限，是否在构建一个缺乏实际业务需求支撑的产品，是否仅仅停留在技术层面的自我满足。

在开发 RobustMQ 的两年时间里，我们收到了诸多质疑：认为我们在"重复造轮子"、"又一个消息队列而已"、"消息队列技术已经成熟，缺乏创新空间"、"技术设想过于宏大，难以实现"。

我们深知，方向选择的正确性决定了一切努力的价值。因此，本文将从产品思维的角度，阐述我们在这段时间的思考与认知。

产品定位

RobustMQ 定位为标准的消息队列产品，与 RocketMQ、Kafka、Pulsar、RabbitMQ 处于同一产品类别。我们的愿景是，在消息队列技术演进的历史中，能够看到这样的脉络：RabbitMQ → Kafka → RocketMQ → Pulsar → RobustMQ。

因此，RobustMQ 的产品定位非常清晰：一个标准的、企业级的消息队列产品。

我们期望在未来，当用户需要选择消息队列时，RobustMQ 能够成为候选清单中的重要选项。用户选择 RobustMQ 的理由包括：

1. 卓越的性能表现

提供高 QPS/吞吐能力和稳定的延迟表现，能够满足流式处理、消息传递、金融交易等多种场景下对性能和吞吐的严苛要求。

2. 多协议兼容能力

兼容主流消息队列协议（MQTT、AMQP、Kafka、RocketMQ 等），降低迁移成本，并在性能、稳定性、成本控制、场景覆盖等方面提供更优的表现。

3. 插件式存储架构

通过插件式存储架构满足不同业务场景的需求。例如，对延迟敏感的场景可使用本地存储，数据量大且对成本敏感的场景可使用远程对象存储，实现存储方案的灵活配置。

4. 统一的技术栈

一套消息队列系统即可满足企业内各种消息中间件场景，无需维护多套异构系统，降低运维复杂度和技术栈管理成本。

5. 云原生弹性能力

具备完整的弹性扩缩容能力，完美适配 Kubernetes 架构，在成本控制和弹性伸缩方面表现更优。

从产品视角来看，RobustMQ 的核心价值定位是成为现有消息队列产品的优化替代方案。通过在稳定性、性能、弹性、成本、场景覆盖、迁移便捷性等维度的综合优势，吸引用户从现有消息队列产品迁移至 RobustMQ。

我们认为，RobustMQ 选择兼容现有协议而非设计新协议，是一个关键的战略决策。设计新的通信协议意味着需要重建整个生态系统，包括 SDK、工具链、社区支持等，工作量巨大且推广困难。而兼容主流协议可以直接复用现有生态，将精力集中在内核优化上，在性能、稳定性、弹性、成本等方面形成差异化竞争力。因此，设计新通信协议将会是 RobustMQ 偏离正确方向的开始。

商业化视角

RobustMQ 自项目启动之初，就坚持开源优先的原则，其目标始终是成为 Apache 顶级项目。但从商业化视角审视，RobustMQ 是否具备实际价值？它的目标用户群体是否会认可其价值？

经过深入分析，我们认为 RobustMQ 在商业层面具有明确的价值定位。其目标用户主要包括两类：To B 服务商和企业客户。

To B 服务商（如云厂商）

当前云厂商的消息队列产品主要采用开源产品托管模式，如托管 Kafka、RabbitMQ、RocketMQ 等。这种模式的优势在于开发成本低、产品稳定、能够快速产生收入。但从长期运营角度来看，存在以下挑战：

1. 差异化困境

开源托管模式难以形成与其他云厂商或用户自建方案的差异化优势，容易陷入资源售卖（CPU/内存）的价格竞争。

2. 二次开发的两难选择

为提高利润率和差异化优势，云厂商通常会对开源产品进行二次开发，但面临以下问题：

• 成本分散问题：如果对每个开源产品都进行二次开发，投入成本巨大且无法形成技术合力；如果只开发部分产品，则难以形成全面的差异化优势，增长空间受限
• 社区分叉风险：二次开发容易与上游社区产生分叉，无法享受社区红利，难以长期维护，最终可能回归社区版本，导致大量投入付诸东流

RobustMQ 的设计理念恰好能够解决这些痛点。其弹性设计、插件化存储、多协议支持、完全开源四大特性，为云厂商提供了理想的解决方案。

以实际场景为例，当 RobustMQ 完成多协议、Serverless、插件化存储等特性后，云厂商可以基于 RobustMQ 适配自有的云存储引擎，满足不同场景和方向的消息队列需求。相比维护多套异构系统，云厂商只需维护一套内核，长期的人力和运维成本将大幅降低，同时更容易通过内核优化形成自身的差异化竞争优势。

企业客户

对于小型企业，在业务场景相对简单的情况下，各类消息队列产品的差异性并不显著。但随着企业规模扩大、业务场景复杂化，通常需要部署多种消息队列。此时，无论是业务方的选型决策，还是基础架构团队的运维管理，成本都非常高昂。

因此，许多企业为提升系统稳定性、降低运维成本、减少人才储备需求，会限制只采用一至两款消息队列产品。

在这种场景下，一款支持多协议、性能优异、稳定可靠、弹性伸缩、能够覆盖多种场景的统一消息队列平台，完美契合企业的实际需求。这正是 RobustMQ 的设计初衷。

核心应用场景

当 RobustMQ 趋于成熟后，我们认为以下两种场景将成为重要的落地方向：

1. All-in-One 统一消息底座

面向云厂商和大型企业，提供一款统一的消息队列平台，满足各种不同场景需求，提升系统稳定性，降低整体投入成本。

2. 现有产品的优化替代

面向对现有消息队列产品在性能、弹性、成本等方面不满意的用户，提供更优的替代方案：

• 对 Kafka 的弹性和成本有更高要求的用户
• 对 MQTT Broker 有更高性能需求的用户
• 对 RabbitMQ 网络分区和性能有顾虑的用户

可以选择 RobustMQ 作为现有方案的替代。

从 0 到 1 的发展路径

面对这样一个技术挑战巨大、愿景宏远的项目，如何完成冷启动？如何推动 RobustMQ 从 0 到 1？

从产品思维的角度，我们规划了清晰的阶段性发展路径：

第一阶段：技术积累

在这个阶段，RobustMQ 的用户即开发者本身。开发团队通过技术追求、开源热情，在项目中获得成就感，通过学习 Rust、分布式存储、提升开源影响力等动力，完成 RobustMQ 的整体架构设计与基础实现。

第二阶段：MQTT 协议突破

在这个阶段，RobustMQ 的目标用户是需要 MQTT 协议的用户群体。选择 MQTT 作为切入点基于以下考量：

1. 技术可行性

MQTT 协议相对轻量简洁，功能清晰明确，是最快能够实现完整 Broker 并体现差异化优势的协议，能够快速验证 RobustMQ 的实际价值。

2. 市场空白

业界目前缺乏性能和架构表现特别优秀的开源 MQTT Broker 解决方案。

3. 市场机遇

EMQX 转向商业化 License 后，开源社区需要一款优秀的替代方案。

第三阶段：多协议生态

在这个阶段，RobustMQ 将覆盖前述所有目标用户群体。通过逐步适配和完善多种协议（Kafka、AMQP 等），不断扩展使用场景，最终实现技术愿景。

当前，我们已经完成第一阶段并进入第二阶段，MQTT 协议的核心功能已基本完成，正在向第三阶段迈进。从产品思维的角度来看，我们已经将 RobustMQ 构建成一个可持续、可坚持的项目。

为什么坚持开源

曾有人询问我们是否计划商业化。我们的回答始终是：不会。我们的目标一直是成为 Apache 顶级项目。

原因在于，RobustMQ 是一个技术挑战巨大、愿景宏远的项目。如果一开始就将其定位为商业化产品，很可能无法真正做好。商业化思维会扭曲技术决策，导致技术选择服务于短期商业目标而非长期技术价值。

基础软件需要持续的琢磨、沉淀、修正、优化。而在商业化压力下，这些必要的技术沉淀可能会变形，走向急功近利。

我们坚信，只有保持 100% 开源，RobustMQ 才能真正实现其技术价值，获得长期成功。

总结

从产品角度来看，RobustMQ 定位为标准的企业级消息队列产品。其核心价值在于通过系统性的技术优化，在性能、稳定性、弹性、成本等多个维度超越现有产品，成为现有消息队列产品的优化替代方案。

RobustMQ 不是"又一个消息队列"，而是"一个更好的消息队列"。

基础软件是一段漫长的旅程。我们始终相信，只有拥抱开源、拥抱热爱、拥抱坚持，才能真正做好基础软件。我们一直在探索和调整中前进。期待在未来的某一天，我们能够自信地说：RobustMQ 是一件真正有价值的事。