使用 Kafka 掌握多集群部署和复制

简要概述 Apache Kafka 和常见用例、用于扩展多集群部署的当前工具以及用于简化多集群部署的连接解决方案。

目录

• 卡夫卡是什么？

• 卡夫卡和库伯内斯

• 多集群 Kafka 案例

• 多集群卡夫卡

  • 延伸集群 - 同步复制
  • 连接集群 - 异步复制

• 结论

  
  

卡夫卡是什么？

Apache Kafka 通常简称为Kafka ，是由 Apache 软件基金会维护的开源事件流平台。 Apache Kafka 最初在LinkedIn构思，由Jay Kreps 、 Neha Narkhede和Jun Rao合作创建，随后于 2011 年作为开源项目发布。 Wiki 页面

如今，Kafka 是最流行的事件流平台之一，旨在处理实时数据源。它被广泛用于构建可扩展、容错和高性能的流数据管道。

Kafka 的用途在不断扩大， Brij Pandey在附图中很好地说明了前 5 个案例。

作为简要入门，了解 Kafka 平台的组件及其工作原理非常重要。

Kafka 作为分布式事件流平台，旨在高效处理实时数据源。它基于发布-订阅消息传递模型运行，并遵循分布式和容错架构。它维护一个持久的、有序的、分区的记录序列，称为“主题”。生产者将数据写入这些主题，消费者从中读取数据。这使得数据生产者和消费者之间能够解耦，并允许多个应用程序独立地使用相同的数据流。

Kafka 的关键组件包括：

1. 主题和分区： Kafka 将数据组织成主题。每个主题都是一个记录流，主题内的数据被分为多个分区。每个分区都是一个有序的、不可变的记录序列。分区允许数据分布在多个 Kafka 代理上，从而实现水平可扩展性和并行性。

   
   

2. 生产者：生产者是将数据写入 Kafka 主题的应用程序。他们将记录发布到特定主题，然后将这些记录存储在主题的分区中。生产者可以显式地将记录发送到特定分区，或者允许 Kafka 使用分区策略来确定分区。

   
   

3. 消费者：消费者是从 Kafka 主题读取数据的应用程序。它们订阅一个或多个主题并使用分配给它们的分区中的记录。消费者组用于扩展消费，主题内的每个分区只能由组内的一个消费者消费。这允许多个消费者并行工作来处理来自同一主题的不同分区的数据。

   
   

4. Brokers ：Kafka作为服务器集群运行，每个服务器称为一个broker。代理负责处理来自生产者和消费者的读写请求，以及管理主题分区。一个Kafka集群可以有多个broker来分配负载并确保容错。

   
   

5. 分区/复制：为了实现容错和数据持久性，Kafka允许为主题分区配置复制。每个分区可以有多个副本，其中一个副本指定为领导者，其他副本指定为追随者。领导者副本处理该分区的所有读写请求，而追随者则从领导者复制数据以保持同步。如果具有领导者副本的代理发生故障，其中一个追随者会自动成为新的领导者，以确保连续运行。

   
   

6. 偏移量管理：Kafka 维护每个分区的偏移量概念。偏移量表示分区内记录的唯一标识符。消费者跟踪当前的偏移量，以便在发生故障或重新处理时从中断处恢复消费。

   
   

7. ZooKeeper ：虽然不是 Kafka 本身的一部分，但 ZooKeeper 通常用于管理元数据并协调 Kafka 集群中的代理。它有助于领导者选举、主题和分区信息以及管理消费者组协调。 [注： Zookeeper 元数据管理工具很快就会被淘汰，取而代之的是Kafka Raft或 KRaft，一种内部管理元数据的协议]

   
   

总体而言，Kafka 的设计和架构使其成为一个高度可扩展、容错且高效的平台，用于处理大量实时数据流。它已成为许多数据驱动的应用程序和数据基础设施的核心组件，促进数据集成、事件处理和流分析。

典型的 Kafka 架构如下：

Kafka集群是指将多个Kafka Broker作为一个组一起运行以形成Kafka集群的做法。集群是 Kafka 架构的一个基本方面，提供了多种好处，包括可扩展性、容错性和高可用性。 Kafka集群用于处理大规模数据流，并确保系统在出现故障时仍保持运行。

在集群中，Kafka主题被划分为多个分区，以实现可扩展性和并行性。每个分区都是线性排序的、不可变的记录序列。因此，分区允许数据分布在集群中的多个代理上。

应该注意的是，最小的 Kafka 集群由 3 个 Kafka 代理组成，每个代理都可以在单独的服务器（虚拟或物理）上运行。 3 节点指导有助于避免代理故障时出现脑裂情况。

卡夫卡和库伯内斯

随着越来越多的公司采用 Kafka，人们对在 Kubernetes 上部署 Kafka 的兴趣也越来越大。

事实上，Dynatrace 最新的2023 年 Kubernetes in the Wild 报告显示，超过 40% 的大型组织在Kubernetes内运行其开源消息传递平台 - 其中大部分是 Kafka。

来源。

同一份报告还大胆宣称，“Kubernetes 正在成为云的‘操作系统’。”

那么，Kafka 管理员必须了解 Kafka 和 Kubernetes 之间的相互作用，以及如何适当地实现它们以实现规模化。

多集群 Kafka 案例

在单个 Kubernetes 集群设置中运行 Kafka 集群相当简单，理论上可以实现所需的可扩展性。然而在生产过程中，情况可能会变得有点模糊。

我们应该区分 Kafka 和 Kubernetes 之间术语“集群”的使用。 Kubernetes 部署还使用术语“集群”来指定一组连接的节点，称为 Kubernetes 集群。当 Kafka 工作负载部署在 Kubernetes 上时，您最终将在 Kubernetes 集群内运行一个 Kafka 集群，但与我们的讨论更相关的是，您还可能拥有一个跨越多个 Kubernetes 集群的 Kafka 集群 - 以实现弹性、性能、数据主权ETC。

首先，Kafka 并不是为多租户设置而设计的。从技术角度来说，Kafka 不理解 Kubernetes 命名空间或资源隔离等概念。在特定主题内，没有简单的机制来在多个用户组之间实施安全访问限制。

此外，不同的工作负载可能具有不同的更新频率和规模要求，例如批量应用程序与实时应用程序。将两个工作负载合并到一个集群中可能会造成不利影响或消耗比必要的更多的资源。

数据主权和监管合规性还可以对特定区域或应用程序中的数据和主题共存进行限制。

当然，弹性是多个 Kafka 集群需求背后的另一个强大驱动力。虽然 Kafka 集群是为主题容错而设计的，但我们仍然必须为整个集群的灾难性故障做好准备。在这种情况下，需要完全复制的集群才能实现适当的业务连续性规划。

对于将工作负载迁移到云或采用混合云策略的企业，您可能希望设置多个 Kafka 集群并随着时间的推移执行计划的工作负载迁移，而不是进行有风险的全面 Kafka 迁移。

这些只是在实践中企业发现自己必须创建多个 Kafka 集群但又需要彼此交互的部分原因。

多集群卡夫卡

为了使多个 Kafka 集群相互连接，必须将一个集群中的关键项复制到其他集群。其中包括主题、偏移量和元数据。在 Kafka 术语中，这种重复被视为镜像。有两种可能的多集群设置方法。延伸集群或连接集群。

延伸集群 - 同步复制

延伸集群是跨多个物理集群“延伸”的逻辑集群。主题和副本分布在物理集群中，但由于它们表示为逻辑集群，因此应用程序本身并不知道这种多重性。

延伸集群一致性强，更易于管理和管理。由于应用程序不知道多个集群的存在，因此与连接的集群相比，它们更容易部署在延伸集群上。

延伸集群的缺点是它需要集群之间的同步连接。它们并不适合混合云部署，并且需要至少 3 个集群的法定数量以避免“裂脑”情况。

连接集群 - 异步复制

另一方面，连接集群是通过连接多个独立集群来部署的。这些独立的集群可以运行在不同的区域或云平台上，并进行单独管理。

连接集群模型的主要好处是，在集群发生故障时不会出现停机，因为其他集群独立运行。每个集群还可以针对其特定资源进行优化。

连接集群的主要缺点是它依赖于集群之间的异步连接。集群之间复制的主题不是“写入时复制”，而是取决于最终一致性。这可能会导致异步镜像过程中可能发生数据丢失。

此外，必须修改跨连接集群工作的应用程序才能了解多个集群。

在我们解决这个难题的解决方案之前，我将简要介绍一下市场上用于实现 Kafka 集群连接的常用工具。

开源 Kafka 本身附带了一个名为 Mirror Maker 的镜像工具。

Mirror Maker 通过内置的生产者在不同集群之间复制主题。通过这种方式，数据可以在集群之间交叉复制，并具有最终一致性，但不会中断各个进程。

值得注意的是，虽然 Mirror Maker 的概念很简单，但大规模设置 Mirror Maker 对于 IT 组织来说可能是一个相当大的挑战。管理 IP 地址、命名约定、副本数量等必须正确完成，否则可能会导致所谓的“无限复制”，其中主题被无限复制，从而导致最终崩溃。

Mirror Maker 的其他缺点是缺乏允许/禁止更新列表的动态配置。 Mirror Maker 也无法正确同步主题属性，这使得在添加或删除要复制的主题时出现大规模操作难题。 Mirror Maker 2 试图解决其中一些挑战，但许多 IT 商店仍然难以正确设置 Mirror Maker。

其他用于 Kafka 复制的开源工具包括 Salesforce 的 Mirus、Uber 的 uReplicator 和Netflix的定制 Flink。

对于商业许可选项，Confluence 提供了两个选项：Confluence Replicator 和 Cluster Linking。 Confluence Replicator 本质上是一个 Kafka Connect 连接器，它提供了一种高性能且有弹性的方式在集群之间复制主题数据。 Cluster Linking 是内部开发的另一项产品，旨在实现多区域复制，同时保留主题偏移。

即便如此，Cluster Linking 是一种异步复制工具，数据必须跨越网络边界并穿越公共流量路径。 现在应该清楚，Kafka 复制是大规模生产应用程序的关键策略，问题是选择哪个选项。

富有想象力的 Kafka 管理员很快就会意识到，您可能需要连接集群和延伸集群，或者这些部署的组合，具体取决于应用程序性能和弹性要求。

然而，令人畏惧的是设置集群配置并跨多个集群大规模管理这些配置所面临的指数级挑战。有什么更优雅的方法来解决这个噩梦？

Avesha 的KubeSlice是一种两全其美的简单方法。通过在集群或命名空间之间创建直接服务连接，KubeSlice 无需手动配置 Kafka 集群之间的单独连接。

KubeSlice的核心是在集群之间创建安全、同步的第 3 层网络网关；在应用程序或命名空间级别隔离。设置完成后，Kafka 管理员就可以在任何集群中自由部署 Kafka 代理。

每个代理都与通过切片加入的每个其他代理具有同步连接，即使代理本身可能位于不同的集群上。这有效地在代理之间创建了一个延伸集群，并提供了强一致性和低管理开销的好处。

鱼与熊掌兼得！

对于那些可能想要将 Mirror Maker 部署到集群中的人来说，这可以轻松完成，因为集群之间的连接已委托给 KubeSlice。因此，Kafka 应用程序可以在同一部署中享受同步（速度、弹性）和异步（独立、规模）复制的优势，并能够根据需要混合和匹配功能。对于本地数据中心、跨公共云或混合设置中这些数据的任意组合来说都是如此。

最好的部分是 KubeSlice 是一种无中断部署，这意味着无需卸载任何已部署的工具。只需建立一个切片并将 Kafka 部署添加到该切片上即可。

结论

本博客简要概述了 Apache Kafka，并涉及了一些更常见的用例。我们介绍了当前可用于跨多个集群扩展 Kafka 部署的工具，并讨论了每种工具的优缺点。最后，本文还介绍了 Kubeslice - 一种新兴的服务连接解决方案，可简化 Kafka 多集群部署，并消除与大规模跨多个集群配置 Kafka 复制相关的麻烦。

读者可能会发现有用的几个链接：

关于在 AWS 上运行 Kafka 的最佳实践的较旧博客（在引入 KubeSlice 之前）

KubeSlice 的引导式设置

在 GKE 上部署 Kafka