RobustMQ 2026：我们要做什么
2025 年对 RobustMQ 来说，是从"摸索方向"到"方向明确"的一年。
2025 年做了什么
年初的时候，RobustMQ 还处于原型阶段——架构没定型，定位模糊，很多东西都在试错。这一年最重要的事情不是写了多少代码，而是想清楚了几个根本性的问题：做什么、不做什么、为什么是现在。
最终沉淀出来的定位是：用 Rust 构建的、为 AI、IoT、大数据场景设计的下一代统一通信平台。支持 MQTT 和 Kafka 双协议，底层是存算分离的架构，存储层支持内存、RocksDB、File Segment 多种模式。
这一年的工程产出集中在三件事上：
架构落地。 Meta Service、Broker、Storage Engine 三层拆分清晰，组件边界稳定。Meta Service 引入了自研的 Multi Raft，支持多个独立 Raft Group，为后续大规模部署打好了基础。
MQTT 功能趋于完整。 MQTT 3.x 和 5.0 全协议覆盖，Session 持久化、共享订阅、QoS 0/1/2、离线消息、延迟消息、规则引擎基础功能——常见的 IoT 场景基本都能承接了。
生态工具补齐。 Grafana + Prometheus 开箱即用的监控体系、命令行管理工具、HTTP Admin API、Web 控制台、Bench 压测 CLI——一个消息系统能不能真正落地，工具配套不能缺。
2025 年以 0.3.0 版本收尾。功能覆盖到了，但稳定性、性能、生产可用性，还需要在 2026 年继续打磨。
2026 年要做什么
2026 年计划发布三个大版本。主线只有一件事：把 MQTT 做到生产可用、好用、非常好用，做到 MQTT Broker 用户只想用 RobustMQ。Kafka 和 AI MQ 是今年要启动的方向，但不是重心——主体流程跑通，打好基础，做到哪算哪。
v0.4.0（预计 5 月）— MQTT 生产初步可用
这个版本的核心只有一件事：让 MQTT Broker 初步具备在生产环境运行的条件。
一轮全面的代码重构消除技术债，压测集群模式并修复所有阻塞性 Bug，补全 QoS 1/2 确认链路的边界条件，节点宕机后在线 Session 无感恢复。可观测性方面，Prometheus 指标覆盖所有关键维度，结构化日志支持按 ClientID/Topic 过滤。单元测试覆盖率目标 ≥ 60%，混沌测试覆盖节点宕机和网络分区场景。
v0.5.0（预计 9 月）— MQTT 生产可用 + Kafka/AI MQ 主流程跑通
MQTT 继续深化：规则引擎 SQL 过滤、更多 Bridge 目标、精细化限流、慢订阅告警。目标是让用户用起来足够顺滑，遇到问题有地方查、有工具排查、有人响应。
Kafka 方向：Producer/Consumer 协议打通，Topic 管理，Java Kafka Client 可以直连——主体流程能跑通就算达标。
AI MQ 方向：Topic 直连 S3/MinIO 对象存储、三层缓存框架原型、基于共享订阅的 Agent 通信示例。先把架构跑通，验证方向是否可行。
v0.6.0（预计 12 月）— MQTT 生产稳定 + 持续深化
MQTT 的目标是稳定——经过大量真实用户验证，没有明显的生产 Bug，性能基线清晰，运维工具完整。Kafka 和 AI MQ 在上一个版本的基础上继续推进，做到哪算哪，不强求完整。
最后说几句
时间有限，但方向清晰了，这比什么都重要。
2026 年想做的事情很多，但我清楚一点：把已经做到的东西做稳，比追加新功能更重要。MQTT 如果不能在生产环境可靠运行，后面的一切都是空谈。所以 v0.4.0 会是重中之重，不会为了赶进度而跳过。
如果你在用 RobustMQ，或者在观望，欢迎来 GitHub 提 Issue、反馈问题、或者直接参与贡献。每一个真实的使用场景，对我们来说都比什么都重要。