CNCF NATS 毕业后消息系统选型应关注哪些兼容边界

CNCF 在 2026 年 11 月 10 日宣布 NATS 毕业，这说明项目在治理、社区和生产使用成熟度上获得了更高认可，但它不等于“NATS 与 Kafka、MQTT 或任意旧消息系统天然兼容”。真正影响选型的，是投递语义、数据保留、客户端能力、协议接入、安全模型和运维拓扑能不能对上。

官方地址：https://nats.io/

把“毕业”当成可信度信号，把“兼容”拆成六个可验收的技术边界：消息语义、持久化、协议客户端、主题模型、安全隔离、桥接与运维。只要其中一项对不上，就应保留原系统或采用双轨迁移。

先把 CNCF 毕业和兼容性分开

CNCF 的公告强调，NATS 已成为连接分布式应用、服务和 AI agent 的生产级消息与流平台，并同时提供消息、流式处理和状态能力。这个结论帮助团队判断项目的社区与治理风险，但不会替你完成协议迁移。

评审时先写下三句话：现有生产者和消费者使用什么协议；一条消息丢失、重复或延迟时业务能否接受；消息是否必须跨重启、跨区域或跨消费者组回放。三句话没有答案时，不要因为“毕业”就直接替换原有消息系统。

先锁定投递语义和持久化边界

Core NATS 的发布订阅面向在线订阅者，消息只交给发布时已经连接的订阅者，适合低延迟通知、请求应答和服务间事件。它不是默认的持久化队列，也不能因为部署成集群就自动获得失败重投。

需要保存、回放或确认进度时，评估 JetStream。官方文档把 stream 描述为消息存储，把 consumer 描述为记录消费位置的服务端状态视图；未及时确认的消息可能再次投递。因此迁移前至少记录：

这一步通常决定迁移成本：如果旧系统依赖严格的消费位点、延迟队列、事务出站或复杂重试，需要逐项映射，不能只把旧 topic 名称替换成 NATS subject。

核对协议、客户端和主题模型

NATS 原生客户端通过自己的文本协议连接服务端，核心操作围绕 subject、发布、订阅和请求应答展开。官方生态页列出了 Go、JavaScript/TypeScript、Python、Java、Rust、C#/.NET 和 C 等 Tier 1 客户端；其他客户端可能滞后于服务端新能力，选型时应把“语言能连上”与“能使用所需 JetStream 或安全特性”分开。

如果现有设备使用 MQTT，浏览器侧使用 WebSocket，或历史数据要与 Kafka、JMS、Spark、Flink 互通，优先评估官方生态中的协议入口和桥接组件。要验收的不是“能否转发一条消息”，而是主题映射、消息头、QoS/确认、顺序、重试、时间戳和错误处理是否保持业务含义。

主题命名也属于兼容边界。NATS subject 使用点号层级和通配符，队列组通过共享组名实现负载分发；旧系统的 topic、分区、消费者组和路由键需要形成明确的映射表。若一个旧 topic 依赖分区内有序，而迁移后只使用普通 queue group，就可能得到“吞吐正常但顺序失效”的结果。

把安全、拓扑和桥接验收写进方案

NATS 的权限模型以 subject 为核心：发布、订阅以及请求应答最终都落在 subject 权限上。迁移时不能只复制用户名和密码，还要重新检查账号隔离、发布/订阅 allow 与 deny、JetStream API 权限以及管理接口范围。

TLS 也要按连接类型拆开看。客户端连接、集群路由、leaf node、gateway、WebSocket 和 MQTT 连接分别有自己的安全配置；只给客户端链路加密，并不代表跨区域路由或边缘链路同样满足要求。证书轮换、客户端重连和旧客户端的 TLS 能力，都应列入演练。

推荐用一张迁移验收表收口：

1. 语义：明确至少一次、至多一次、重复消费和顺序要求。
2. 数据：明确保留策略、容量、回放入口、备份和恢复目标。
3. 连接：逐语言确认客户端版本、JetStream 能力、TLS 和重连行为。
4. 互操作：为 MQTT、WebSocket、Kafka 等每条桥接链路写出字段、确认和失败映射。
5. 运维：确认集群、leaf node、监控、告警、升级和回滚负责人。

上线顺序应从旁路消费或小范围双写开始，先比较消息数量、重复率、延迟、未确认数量和错误类型，再扩大流量。任何一项语义指标无法解释，都应回滚到原系统，而不是用吞吐提升掩盖兼容缺口。

常见问题

NATS 毕业后是不是可以直接替换所有消息中间件？

不是。毕业主要是项目成熟度和社区治理信号，替换仍取决于投递、持久化、协议、顺序、事务、桥接和安全要求。

Core NATS 和 JetStream 应该怎么选？

只需要在线低延迟通信时优先看 Core NATS；需要存储、回放、确认和失败重投时评估 JetStream，并把重复消费和保留成本纳入设计。

现有 Kafka topic 能否直接映射为 NATS subject？

只能完成名称层映射，不能自动保留 Kafka 的分区、位点、消费组、事务或重放语义。桥接前必须逐项定义这些字段和失败行为。

最终判断可以压缩成一句话：CNCF 毕业让 NATS 更值得进入候选清单，但是否适合你的系统，取决于六类兼容边界能否用小流量、可回滚的验收结果证明。