KoP-正式开源在-Apache-Pulsar-上支持原生-Kafka-协议

咱们很快乐地发表 StreamNative 和 OVHcloud 开源了“KoP“（Kafka on Pulsar）。KoP 将 Kafka 协定解决插件引入 Pulsar broker。这样一来，Apache Pulsar 就反对原生 Apache Kafka 协定。将 KoP 协定解决插件增加到现有 Pulsar 集群后，用户不必批改代码就能够将现有的 Kafka 应用程序和服务迁徙到 Pulsar。这样，Kafka 应用程序就能够应用 Pulsar 的弱小性能，例如：

• 利用企业级多租户个性简化经营。
• 防止数据搬迁，简化操作。
• 利用 Apache BookKeeper 和分层存储长久保留事件流。
• 利用 Pulsar Functions 进行无服务器化事件处理。

什么是 Apache Pulsar

Apache Pulsar 是一个事件流平台。最后，Apache Pulsar 就采纳云原生、分层分片的架构。该架构将服务和存储拆散开来，使零碎实现更敌对的容器化。Pulsar 的云原生架构具备强扩展性、高一致性和高弹性，使公司能通过实时数据解决方案扩大业务。自 2016 年开源以来，Pulsar 已失去宽泛采纳，并于 2018 年成为 Apache 顶级我的项目。

对 KoP 的渴望

Plusar 为队列和流工作负载提供对立的音讯模型。Pulsar 反对本人基于 protobuf 的二进制协定，以确保高性能和低提早。protobuf 有利于实现 Pulsar 客户端。而且，该我的项目也反对 Java，Go，Python 和 C ++ 语言以及社区提供的第三方客户端。然而，对于应用其余音讯传输协定编写的应用程序，用户必须重写这些应用程序，否则这些应用程序无奈采纳 Pulsar 新的对立音讯传输协定。

为了解决这一问题，Pulsar 社区开发了一些应用程序，以便将 Kafka 应用程序从其余音讯零碎迁徙到 Pulsar。例如，Pulsar 在 Kafka Java API 上提供了 Kafka wrapper。Kafka wrapper 容许用户在不扭转代码的状况下将其应用的 Kafka Java 客户端应用程序从 Kafka 切换到 Pulsar。Pulsar 还提供丰盛的 connector 生态系统，用于连贯 Pulsar 和其余数据系统。然而，那些想要从其余 Kafka 应用程序切换到 Pulsar 的用户依然有强烈的需要。

StreamNative 和 OVHcloud 的单干

StreamNative 收到大量的入站申请，申请帮忙从其余音讯零碎迁徙到 Pulsar。同时，StreamNative 也意识到在 Pulsar 上原生反对其余音讯传输协定（例如 AMQP 和 Kafka）的必要性。所以，StreamNative 开始致力于将通用协定解决插件框架引入到 Pulsar 中。该框架容许应用其余音讯传输协定的开发人员应用 Pulsar。

多年来，OVHcloud 始终采纳 Apache Kafka。只管他们有在 Kafka 上运行多个集群且每秒解决数百万条音讯的教训，但仍面临艰巨的经营挑战。例如，如果不应用多租户个性，他们很难将成千上万个用户的数千个 Topic 放在一个集群中。

所以，OVHcloud 放弃 Kafka，决定将其主题即服务的产品（即 ioStream）转移到 Pulsar，并在 Pulsar 上构建其产品。与 Kafka 相比，Pulsar 反对多租户个性且其整体架构蕴含 Apache BookKeep 组件，这有助于简化用户操作。

在初步试验之后，OVHcloud 决定将 KoP 作为 PoC proxy，将 Kafka 协定即时转换到 Pulsar。在此过程中，OVHcloud 留神到 StreamNative 正在致力于将 Kafka 协定原生地引入到 Pulsar。于是，他们联手开发了 KoP。

KoP 旨在利用 Pulsar 和 BookKeeper 的事件流存储架构和 Pulsar 的可插拔协定解决插件框架来提供一种精简而全面的解决方案。KoP 是一个协定名称为“kafka”的协定解决插件。KoP 绑定在 Pulsar broker 上，并与 Pulsar broker 一起运行。

分布式日志

对于 日志 ，Pulsar 和 Kafka 都采纳十分类似的数据模型，用于公布 / 订阅音讯和事件流。例如，Pulsar 和 Kafka 都采纳分布式日志。这两个零碎的次要区别在于它们如何实现分布式日志。Kafka 采纳分区的架构，将分布式日志（Kafka 分区中的日志）存储在一组 broker 中。Pulsar 采纳 分片 的架构，利用 Apache BookKeeper 作为其横向扩大的分片存储层，将分布式日志存储在 Apache BookKeeper 中。Pulsar 基于 分片 的架构有助于防止数据搬迁、实现高扩展性、以及长久地存储事件流。无关 Pulsar 和 Kafka 次要区别的更多信息，参考 Splunk 博客和 BookKeeper 我的项目博客。

Pulsar 和 Kafka 都基于类似的数据模型（分布式日志）进行搭建，而且 Pulsar 采纳分布式日志存储和可插拔的协定解决插件框架（在 2.5.0 版本中引入），所以 Pulsar 能够很容易地实现兼容 Kafka 的协定解决插件。

实现形式

通过比照 Pulsar 和 Kafka，咱们发现这两种零碎有很多相似之处。这两种零碎都包含以下操作：

• Topic 查找：所有客户端都连贯到任一 broker 以查找 Topic 的元数据（即 owner broker）。获取元数据之后，客户端与 owner broker 建设长久的 TCP 连贯。
• 公布 ：客户端与 Topic 区的 owner broker 进行对话，以将音讯追加到 分布式日志 中。
• 生产：客户端与 Topic 分区的 owner broker 进行对话，以便从分布式日志中读取音讯。
• 偏移量 ：为公布给 Topic 分区的音讯调配 偏移量 。在 Pulsar 中，偏移量被称为 MessageId。consumer 能够应用 偏移量 来查找日志中的给定地位，以便读取音讯。
• 生产状态：这两个零碎都保护订阅中的 consumer（Kafka 称之为生产组）的生产状态。Kafka 将生产状态存储在 __offsets Topic，而 Pulsar 将生产状态存储在 cursors。

正如你所见，这些都是横向扩大分布式日志存储（例如 Apache BookKeeper）提供的所有原始操作。Pulsar 的外围性能是在 Apache BookKeeper 上实现的。因而，咱们能够非常简单、间接地应用 Pulsar 在 BookKeeper 上开发的现有组件来实现 Kafka 概念。

下图阐明了咱们如何在 Pulsar 中增加 Kafka 协定反对。咱们引入一个新的 协定解决插件，该协定解决插件利用 Pulsar 的现有组件（例如 Topic 发现、分布式日志库 -ManagedLedger、cursor 等）来实现 Kafka 传输协定。

Topic

Kafka 将所有 Topic 存储在扁平的命名空间。然而，Pulsar 将 Topic 存储在层次化、多租户的命名空间。咱们在 broker 配置中增加了 kafkaNamespace 配置，这样管理员就能够将 Kafka Topic 映射到 Pulsar Topic。
为了不便 Kafka 用户应用 Apache Pulsar 的多租户个性，当 Kafka 用户应用 SASL 验证机制来验证 Kafka 客户端的时候，能够指定一个 Pulsar 租户和命名空间作为其 SASL 用户名。

音讯 ID 和偏移量

Kafka 为每条被胜利公布到 Topic 分区的音讯都指定了一个偏移量。Pulsar 为每条音讯指定了一个 MessageID。音讯 ID 由 ledger-id、entry-id 和 batch-index 组成。咱们在 Pulsar-Kafka wrapper 中应用雷同的办法将 Pulsar 的音讯 ID 转换为偏移量，反之亦然。

音讯

Kafka 和 Pulsar 的音讯都蕴含键、值、工夫戳和 header（在 Pulsar 中被称作‘properties’）。咱们主动在 Kafka 音讯和 Pulsar 音讯之间转换这些字段。

Topic 查找

咱们为 Kafka 和 Pulsar 的申请解决插件提供雷同的 Topic 查找办法。申请解决插件发现 Topic，查找所申请的 Topic 分区的全副所有权，而后将蕴含所有权信息的 Kafka TopicMetadata 返回给 Kafka 客户端。

公布音讯

当收到 Kafka 客户端公布的音讯后，Kafka 申请解决插件逐个将多个字段（例如键、值、工夫戳和 headers）进行映射，从而将 Kafka 音讯转换为 Pulsar 音讯。同时，Kafka 申请解决插件利用 ManagedLedger append API 将这些已转化的 Pulsar 音讯存储在 BookKeeper。Kafka 申请解决插件将 Kafka 音讯转换为 Pulsar 音讯后，现有的 Pulsar 应用程序就能够接管 Kafka 客户端公布的音讯。

生产音讯

当收到 Kafka 客户端的 consumer 申请时，Kafka 申请解决插件关上一个非长久 cursor，而后从申请的偏移量开始读取 entries。Kafka 申请解决插件将 Pulsar 音讯转换回 Kafka 音讯后，现有的 Kafka 应用程序就能够接管 Pulsar 客户端公布的音讯。

Group coordinator & 偏移量治理

最大的挑战是实现 group coordinator 和偏移量治理。Pulsar 不反对集中的 group coordinator，无奈为生产组里的 consumer 调配分区，也无奈治理每个生产组的偏移量。Pulsar broker 基于分区来治理分区调配，而分区的 owner broker 通过将确认信息存储在 cursors 来治理偏移量。

咱们很难让 Pulsar 模型与 Kafka 模型保持一致。因而，为了齐全兼容 Kafka 客户端，咱们将 coordinator group 的更改和偏移量存储在 Pulsar 名为 public/kafka/__offsets 零碎 Topic 中，从而实现 Kafka coordinator group。这样，咱们可能在 Pulsar 和 Kafka 之间建设桥梁，并容许用户应用现有的 Pulsar 工具和策略来治理订阅并监控 Kafka consumer。咱们在已实现的 coordinator group 中增加一个后盾线程，定期将偏移量更新从零碎 Topic 同步到 Pulsar cursor。因而，实际上 Kafka 生产组被认为是 Pulsar 订阅。所有现有的 Pulsar 工具也能够用于治理 Kafka 生产组。

连贯两种风行的音讯生态系统

StreamNative 和 OVHcloud 都器重客户的胜利。咱们置信，在 Apache Pulsar 上提供原生 Kafka 协定可能帮忙采纳 Pulsar 的用户更快地获得业务胜利。KoP 整合了两个风行的事件流生态系统，解锁了新的用例。客户能够利用这两个生态系统的劣势，借助 Apache Pulsar 构建一个真正对立的事件流平台，减速开发实时应用程序和服务。

KoP 使日志收集器能够持续从其起源收集日志数据，并应用现有的 Kafka 集成向 Apache Pulsar 公布音讯。上游应用程序能够应用 Pulsar Functions 来解决达到零碎的事件，实现无服务器化事件流传输。

试用 KoP

KoP 应用 Apache License V2 许可证，我的项目地址为：https://github.com/streamnati…。StreamNative Platform 曾经内置 KoP。你能够抉择下载 StreamNative Platform 来试用 KoP 的所有性能。如果曾经运行 Pulsar 集群，并且心愿其反对 Kafka 协定，能够将 KoP 协定解决插件装置到现有的 Pulsar 集群。相干详细信息，请参考阐明。

如果想要理解无关 KoP 的更多信息，请参考 KoP 的代码和文档息。咱们期待你提出问题和 PR。你也能够在 Pulsar Slack 中退出 #kop 频道，探讨无关 Kafka-on-Pulsar 的所有事件。

StreamNative 和 OVHcloud 将于 3 月 31 日举办无关 KoP 的网络研讨会。如果想要理解更多详细信息，请单击注册。期待与你在网上见面。

致谢

最后，StreamNative 发动 KoP 我的项目。起初，OVHcloud 团队退出了该我的项目。咱们一起合作开发 KoP 我的项目。非常感谢 OVHcloud 的 Pierre Zemb 和 Steven Le Roux 对这个我的项目的奉献！