Kafka 把 ZooKeeper 那条路撤了：要不要跟

先给结论：这件事真正解决的问题，是「谁来接管那三台只在当元数据存储的机器」，不是「Kafka 要不要换」。手上还挂着 ZooKeeper 集群的，可以不用赶，但别再给这条路添新依赖。

发生了什么：一条路撤了，另一条路刚铺好

Apache Kafka 4.0（2025 年 3 月发布）对这篇文章的读者只有一件事有用：ZooKeeper 支持被彻底移除，Java 8 同时不再支持。以前是二选一，现在元数据路径只剩 KRaft，没有选项。两条改动叠在一起，说明这不是「新增一种模式」，是「拆掉旧的那条」。

但「路撤了」和「你必须搬家」是两回事。官方 4.1 那一版的升级文档里，从 ZooKeeper 模式迁移到 KRaft 仍然是一个正经章节——写 Kafka 的人清楚存量有多大，所以给的是路径，不是通牒。

云厂商侧今年把路径里最贵的一段补上了：Amazon MSK 在 2026 年 8 月公告支持 ZooKeeper 到 KRaft 的就地升级。在这之前，这类迁移的默认做法是双集群并行——起一套新的、双写、切读、拆旧。就地升级不消灭风险，但它直接砍掉了这件事对机器数量和窗口时长的要求。

我的判断：这个事件只完成了一半。Kafka 官方拆了旧路，运维侧的低成本迁移方法是刚到位的。两半凑齐之后，「跟」的决策门槛比前两年低了一档——这才是今年值得重新评估的原因，而不是版本号本身。

对存量系统：成本不在 Kafka，在那三台机器

先把 Kafka 本身放一边。你跑的集群大概率早就是当初引入版本之上的某个状态，动它要排队。真正值得单独算账的，是旁边那套 ZooKeeper。

Kafka 用 ZooKeeper 的时候，ZK 的活只有一件：存集群元数据、选控制器。也就是说：

• 你为一套组件的目录服务，养了三台机器（一个 ensemble 的起步配置）；
• 你维持着「看得懂 ZooKeeper」这条运维经验，而这条经验在 KRaft 模式的 Kafka 上用不上，在别的系统里也越来越少有人用；
• 每一次和 Kafka 相关的动作——升级、配置变更、机房搬迁、故障演练——都多牵出一层；
• 这一层的补丁、监控、告警不归 Kafka 管，又很容易被当成 Kafka 的事。

最后一条最重，而且在架构图上完全看不出来：ZooKeeper 在 Kafka 的运维清单里，实际运维它的往往是通用中间件组或者「当年搭的人已经走了」。最贵的一类组件，就是这种承载关键职责却没有明确归属的。

还有一个隐性放大器：升级列车。ZooKeeper 模式的 Kafka，每一次版本升级都要两层一起回归——Kafka 本体一遍，ZK 兼容性一遍，中间还夹着客户端协议的兼容矩阵。这意味着这套集群的可动窗口比 KRaft 集群更少、每次改动的验证人天更多。如果你的 Kafka 已经停在旧版本两三年没动，原因很可能不是「不想动」，而是「每次评估都发现动一次的代价接近动两次」。这条路撤了之后，这笔账不会再变小，只会随着落后年限累积。

所以「要不要跟」这个问题，我会先改写成另一个问题：那套 ZooKeeper 现在还活着，理由是不是只剩 Kafka 的元数据？如果答案是「是」，那么你每个季度都在为一种已经退场的架构付租金——付的不只是机器，是持续分散出去的运维注意力。

跟与不跟：各自的触发条件

这张表我自己评估同类事件时用，左右两列都是能在机房里直接核对的事，不需要预测趋势。

跟（排进今年的窗口）	不跟（明年再看）
机房里 ZooKeeper 的唯一消费方就是 Kafka	同一套 ZK 还挂着别的服务的注册或配置
Kafka 版本已经落后到安全补丁覆盖不到	在跑的版本稳定，且在官方支持范围内
用云托管实例，且托管侧已支持就地迁 KRaft	自建集群，且拿不出双跑所需的备用机器
链路上还有 Java 8，JVM 升级反正躲不掉	运行时已是较新 LTS，没有版本欠账
接手方刚发生过变动，没人说得清那套 ZK	有一个团队对 Kafka 全链路负责到底

有两行容易被低估，单独说。

Java 8 那行。 Kafka 4.0 不支持 Java 8，对还在 8 上的存量系统，这是一次「被迫的捆绑迁移」：想跟 Kafka，就得先动 JVM。反过来说，如果今年本来就有 JVM 升级计划，那搭车做比单独立项省一个窗口；如果今年不动 JVM，「跟」就自然排到明年之后，不必焦虑。

接手方那行。 ZooKeeper 模式的 Kafka 集群最脆弱的形态，是「全公司没人对那套 ensemble 负责」。这种情况下，迁移本身就是还经验债的机会：KRaft 把元数据和控制器收回 Kafka 进程内，运维知识重新归一个团队，注意力成本一次性结清。

如果两个条件都对不上——ZK 还有别的用途、版本也还新——那正确答案就是不动，等这套 ZooKeeper 的其他消费方各自退役之后回来收个尾。动一半比不动更贵。

如果左列对上了，我会用固定的四项来估这件事的改动量，避免把它估成一次大项目：

1. 清点。 把所有依赖这套 ZK 的东西列出来，确认 Kafka 元数据是不是唯一消费方；顺手确认生产者、消费者客户端的版本分布，老客户端往往是排期的最大制约。
2. 选路径。 自建集群按官方迁移章节走标准路径；托管实例只要控制台侧已支持就地升级，就优先就地。这两条路的成本差在前面对表里已经说了，不需要重新发明评估方法。
3. 写回退预案。 迁移过程出问题退到哪一步、元数据以哪边为准，这些必须在动手之前落在纸上，而不是等到故障里再讨论。
4. 留观察期。 迁移完成后保留一个完整业务周期，重点看控制器在节点故障和重平衡时的行为，和旧版本时期的表现做对比。

这四项合起来，对一个中等规模的集群通常是「数个人天的改动 + 一个观察月的注意力」量级。这就是我说的决策门槛降了一档：主要成本集中在排期和预案上，不在技术难度上。真正做不动的，从来都是前面对表右列那些情况。

还没上 Kafka 的团队：先问这套消息量级值不值得自建

另一半读者没有历史包袱，那这件事对他们只剩一个问题：现在第一次引入，怎么选。我的顺序是：

1. 先分清要的是「业务消息队列」还是「日志流」。多数业务系统的异步解耦、事务消息、削峰场景，RocketMQ 这类专门做消息的组件覆盖得更直接，部署形态也更少；这条路线我在 RocketMQ 生产落地 里拆过，不重复。
2. 再核对量级和生态需求。Kafka 的长板是高吞吐日志流和围绕它的连接器、流处理、入湖生态。只拿来发几个异步任务 topic，长板兑现不了，付的却是完整一套集群的成本。
3. 最后才讨论自建还是用托管。托管拿走的恰好就是控制器和元数据这一层——正是这类事件一直在缩减的东西。小团队在这上面没有规模优势。

给还没起步的系统一条硬判据：新选型里 ZooKeeper 只应该出现在减分项里。它不再是通用分布式协调设施，现在它的主要身份是少数旧版本 Kafka 的元数据存储。这正是 KRaft 对你们比对存量用户更大的意义——消息队列从一个双组件运维问题变回单组件问题。这类「把系统逐层拆开、每层单独定归属」的拆法，方法在 新系统逐层拆解。

一句收尾

Kafka 撤的是 ZooKeeper 那条路，不是你的迁移义务：先去查清楚机房里那套 ZooKeeper 还在支撑什么，如果答案只剩 Kafka 的元数据，就把它排进今年的计划——因为迁移方式第一次降到了「一次变更窗口」的量级，而不是「起一套新集群」的量级，这种时间窗不会一直开着。