2026 年 RoadMap（更新版）
本文是对 2026 年 RoadMap 的修订版。旧版规划保留作为历史快照，不再更新；本页是当前生效的规划。
为什么要调整计划
旧版规划是站在 v0.3.0 的节点上写的：设想全年分三步走——先把 MQTT 打磨到生产可用（v0.4.0），再让 Kafka 具备基础读写能力（v0.5.0），最后同步探索 AI MQ（v0.6.0）。AMQP、RocketMQ 当时被明确列为"2026 年不在计划内"，NATS 甚至都没有出现在规划里。
实际进展超出了这个预期："一份数据、多协议原生视图"的统一底座架构已经端到端验证通过——MQTT、Kafka、NATS、mq9、AMQP 五个协议的第一个版本都已经跑在同一套底座上，核心逻辑已经完成。这不是"进度提前了一点"，而是旧规划里"2026 年不做"的事情已经提前做完了架构验证。
正因为底座已经被验证，接下来没有必要五个协议齐头并进——那只会分散精力、拉长每个协议真正达到生产可用的时间。所以下半年要做的是收拢范围，做减法，回到主线：把"MQTT 写入、Kafka 消费"这条已经跑通的核心路径做扎实、做到生产可用，集中打磨稳定性和性能，而不是继续在协议广度上扩张。
下半年核心目标：聚焦 MQTT + Kafka 主线
1. MQTT 生产化
- 集群模式稳定性：长时间运行、节点宕机/重启后的自愈能力验证
- 性能基线：连接数、发布/订阅吞吐、P99 延迟建立可对外公布的基准
- 可观测性：Metrics/Dashboard 覆盖完整的生产运维场景
- 安全：TLS/mTLS、ACL、认证链路的稳定性与性能打磨
2. Kafka 生产化
- 核心读写路径（Produce/Fetch/Offset/Consumer Group）在真实负载下的稳定性验证
- 与主流 Kafka 客户端（Java Client、官方 CLI 工具）的兼容性持续验证，修复边界场景
- 性能基线：吞吐、延迟建立可对外公布的基准
3. MQTT 与 Kafka 打通，做扎实
统一存储层已经证明"MQTT 写入、Kafka 消费同一份数据"这条路径能跑通（见 首页演示 和 IoT 场景说明），下半年要把它从"能跑通"做到"生产可用、经得起压测"：
- 跨协议一致性场景的压力测试和边界条件修复
- 高并发写入（MQTT）+ 高吞吐消费（Kafka）叠加场景下的资源隔离和性能验证
- 补齐这条路径上的运维可观测能力（能看到数据从 MQTT 写入到 Kafka 消费的全链路状态）
4. 远程存储 S3 适配
- 冷数据自动分层到 S3 / 兼容对象存储，降低长期存储成本
- 分层策略的生产级验证：读写路径在冷热数据混合访问下的稳定性和性能
其他协议：已验证，非当前重点
NATS、AMQP、mq9 的第一个版本已经在同一套底座上跑通，证明了架构的可扩展性，但下半年不作为主线投入，维持在"能用、持续小修小补"的状态，等 MQTT + Kafka 这条主线达到生产可用后再重新评估投入优先级。
发布节奏
大版本的时间节点维持原计划不变：
| 版本 | 时间节点 | 内容（已按新方向调整） |
|---|---|---|
| v0.4.x | 已发布，持续迭代中 | 统一底座架构验证：MQTT/Kafka/NATS/mq9/AMQP 第一版跑通 |
| v0.5.0 | 预计 2026 年 9 月 | MQTT 生产化阶段性成果、Kafka 生产化阶段性成果、MQTT↔Kafka 打通、S3 远程存储初步支持 |
| v0.6.0 | 预计 2026 年 12 月 | MQTT + Kafka 生产可用收官、性能压测基准报告发布、S3 远程存储生产可用 |
与旧规划不同的是：大版本之间会有更多小版本发布，持续交付阶段性的稳定性和性能改进，而不是把所有工作攒到大版本节点才发布——这也是 v0.4.0 之后已经在发生的节奏（0.4.x 系列已发布多个小版本）。