Kafka 发行版中附带的一些管理工具仍然允许与 ZooKeeper 直接通信。更糟糕的是，仍然有一两个操作必须经过 ZooKeeper 的这种直接通信才能完成。
我们一直在努力缩小这些差距。不久之后，对于以前需要直接 ZooKeeper 访问的每个操作，将都有一个公共的 Kafka API。我们还将在 Kafka 的下一个主要版本中禁用或删除不必要的 ——zookeeper 标志。
在实现 KIP-500 之后，Kafka 控制器会将其元数据存储在 Kafka 分区中，而不是存储在 ZooKeeper 中。但是，由于控制器依赖于该分区，因此分区本身不能依赖控制器来进行领导者选举之类的事情。 所以管理此分区的节点必须实现自我管理的 Raft 仲裁。
KIP-595: A Raft Protocol for the Metadata Quorum 概述了社区如何将 Raft 协议引入到 Kafka 中，以使能够在 Kafka 中更好的工作。 这将涉及将 Raft 论文 中描述的基于推的模型更改为基于拉的模型，这与传统的 Kafka 复制是一致的。其他节点将连接到这些节点，而不是将数据推送到其他节点。同样，我们将使用与 Kafka 一致的术语，使用 epochs 而不是原始 Raft 论文中的 terms 等等。
最初的实现将集中在支持元数据分区上。它不支持将常规分区转换为 Raft 所需的全部操作。但是，这是我们将来可能会谈到的话题。
当然，该项目最令人兴奋的部分是在 “ KIP-500模式” 下无需 ZooKeeper 即可运行的能力。当 Kafka 在此模式下运行时，我们将使用 Raft 仲裁存储元数据，而不是ZooKeeper。
最初，KIP-500 模式将是实验性的。大多数用户将继续使用“传统模式”，即仍然使用 ZooKeeper。部分原因是因为 KIP-500 模式最初并不支持所有可能的功能。另一个原因是因为我们希望在将其设置为默认值之前，KIP-500 模式必须解决之前所有问题。最后，我们需要时间完善从传统模式到 KIP-500 模式的升级过程。
启用 KIP-500 模式的大部分工作将在控制器中进行。我们必须将控制器中与 ZooKeeper 交互的部分与实现更多通用逻辑(如复制集管理)的部分分离开来。
我们需要定义和实现更多的控制器API，以替换当前涉及 ZooKeeper 的通信机制。新的 AlterIsr API 就是一个例子。该 API 允许副本在不使用 ZooKeeper 的情况下将同步副本集中的更改通知控制器。
KIP-500 引入了桥接发行版（bridge release）的概念，使用了这个功能使得 KIP-500 过渡期变得更好。Bridge 发行版非常重要，因为它们可以让用户升级时零停机。使用 Kafka 老版本的用户只需升级到 bridge 发行版即可。然后，再可以执行第二次升级到完全实现 KIP-500 的版本。正如它的名字所暗示的，桥接发行充当了通往新世界的桥梁。
Kafka 是最活跃的 Apache 项目之一。在过去的几年里，它的架构发生了惊人的变化。正如 KIP-500 这样的 ISSUE 所显示的那样，这种进化还没有完成。我最喜欢KIP-500的地方在于，它简化了整个体系结构，无论对于管理员还是开发人员而言。它将允许我们使用事件日志的强大抽象来处理元数据，它最终会证明：Kafka 不需要管理员！
本文翻译自：Apache Kafka Needs No Keeper: Removing the Apache ZooKeeper Dependency
本博客文章除特别声明，全部都是原创！
