Apache Kafka集群类型的部署策略

组织开始采用单个Apache Kafka集群部署第一个使用案例来启动其数据流采用。对全组织范围的数据治理和安全性的需求，以及不同的SLA、延迟和基础设施要求引入了新的Kafka集群。多个Kafka集群是常规，而非例外。使用案例包括混合集成、聚合、迁移和灾难恢复。本博文探讨了不同行业中针对Kafka部署的真实成功案例和集群策略。

Apache Kafka：事件驱动架构和数据流的事实标准

Apache Kafka是一个面向高吞吐量、低延迟数据处理的开源分布式事件流平台。它允许您实时发布、订阅、存储和处理记录流。

Kafka是一个流行的选择用于 构建实时数据管道和流应用。Kafka协议已成为事件流传输的事实标准，在各种框架、解决方案和云服务中广泛使用。它支持操作和分析工作负载，具备持久存储、可扩展性和容错等特性。Kafka包括组件，如用于集成的Kafka Connect和用于流处理的Kafka Streams，使其成为多种数据驱动用例的多功能工具。

虽然Kafka因实时用例而闻名，但许多项目利用该数据流平台确保整个企业架构的数据一致性，包括数据库、数据湖、遗留系统、开放API和云原生应用。

不同的Apache Kafka集群类型

Kafka是一个分布式系统。生产环境通常需要至少四个代理。因此，大多数人自动假设您只需一个单一的分布式集群，当您增加吞吐量和用例时进行扩展。这在一开始并没有错。但…

一个Kafka集群不是每个用例的正确答案。各种特性影响Kafka集群的架构：

• 可用性：零停机时间？99.99%的正常运行时间SLA？非关键分析？
• 延迟: 端到端处理时间在100毫秒内（包括处理）？10分钟端到端数据仓库管道？时间旅行以重新处理历史事件？
• 成本: 价值与成本？总拥有成本（TCO）很重要。例如，在公共云中，网络可能占Kafka总成本的80％！
• 安全和数据隐私: 数据隐私（PCI数据，GDPR等）？数据治理和合规性？属性级的端到端加密？自带密钥？公共访问和数据共享？空隙式边缘环境？
• 吞吐量和数据大小: 关键交易（通常低交易量）？大数据源（点击流，物联网传感器，安全日志等）？

类似本地部署 vs. 公共云、区域 vs. 全球等相关主题，还会影响Kafka架构。

Apache Kafka 集群策略和架构

单个Kafka集群通常是数据流处理旅程的正确起点。如果操作和扩展正确，它可以承载来自不同业务领域的多个用例，并处理每秒的千兆字节。

然而，根据项目要求，您可能需要一个具有多个Kafka集群的企业架构。以下是一些常见示例：

• 混合架构：多个数据中心之间的数据集成和单向或双向数据同步。通常是在本地数据中心和公共云服务提供商之间建立连接。将遗留系统中的数据转移到云分析是最常见的情景之一。但也可能进行命令和控制通信，例如将决策/建议/交易发送到区域环境（例如在主机中存储来自移动应用的付款或订单）。
• 多区域/多云：出于合规、成本或数据隐私原因进行数据复制。数据共享通常只包括部分事件，而非所有Kafka主题。医疗保健是众多行业中朝这个方向发展的一个例子。
• 灾难恢复：在不同数据中心或云区域之间以主动-主动或主动-被动模式复制关键数据。包括灾难发生时的故障转移和回退机制的策略和工具，以确保业务连续性和合规性。
• 聚合：用于本地处理（例如预处理、流式ETL、流处理业务应用程序）的区域集群，并将精选数据复制到大数据中心或云中。零售商店是一个很好的例子。
• 迁移：进行IT现代化，将从本地迁移到云端或从自管理的开源系统迁移到完全托管的SaaS。此类迁移可以在业务持续进行的同时零停机或数据丢失。
• 边缘（断开/空隙）：安全性、成本或延迟要求在边缘部署，例如在工厂或零售商店。一些行业在安全关键环境中部署具有单向硬件网关和数据二极管的设备。
• 单个代理：不具备弹性，但足以用于将Kafka代理嵌入机器或工业PC（IPC）中，并将聚合数据复制到大型云分析Kafka集群中的场景。一个很好的例子是在战场士兵的计算机上安装数据流（包括集成和处理）。

桥接混合Kafka集群

这些选项可以结合使用。例如，边缘处的单个代理通常将一些策划数据复制到远程数据中心。混合集群有不同的架构，具体取决于它们如何桥接：通过公共互联网、私人链接、VPC对等连接、过渡网关等。

多年来看到Confluent Cloud的发展，我低估了需要花费在安全性和连接性上的工程时间。然而，缺少安全桥接是阻碍采用Kafka云服务的主要障碍。因此，在Kafka集群之间提供各种安全桥接是不可或缺的，远远不止是通过公共互联网。Kafka云服务。

甚至有一些情况下，组织需要将数据从数据中心复制到云端，但云服务不被允许发起连接。Confluent为这种安全需求构建了一个特定功能，称为“源发起链接”，其中源（即本地Kafka集群）始终发起连接 – 即使云Kafka集群正在消费数据：

来源：Confluent

如您所见，情况很快变得复杂起来。从一开始就找到合适的专家来帮助您，而不是在您已经部署了第一个集群和应用程序之后。

很久以前，我已经在一次详细的演示中描述了分布式、混合、边缘和全球Apache Kafka部署的架构模式。查看那些幻灯片和视频录像，以获取更多关于部署选项和权衡的详细信息。

RPO与RTO = 数据丢失与停机时间

RPO和RTO是您在决定Kafka集群策略之前需要讨论的两个关键绩效指标：

• RPO（恢复点目标）是以时间为单位衡量的最大可接受数据丢失量，表示应多频繁进行备份以最小化数据丢失。
• RTO (恢复时间目标)是在中断后恢复业务运营所需的最长可接受时间。它们帮助组织规划其数据备份和灾难恢复战略，以平衡成本和运营影响。

尽管人们经常以 RPO = 0 和 RTO = 0 为目标开始，但他们很快意识到要实现这一点是多么困难（但并非不可能）。您需要决定在灾难中可以丢失多少数据。如果发生灾难，您需要一份灾难恢复计划。法律和合规团队将告诉您在灾难发生时是否可以丢失一些数据集。在评估您的 Kafka 集群策略时，需要讨论这些问题以及许多其他挑战。

使用 MIrrorMaker 或 Cluster Linking 等工具在 Kafka 集群之间进行复制是异步的，因此 RPO > 0。只有一个延伸的 Kafka 集群提供 RPO = 0。

延伸的 Kafka 集群：通过数据中心之间的同步复制实现零数据丢失

大多数部署具有多个 Kafka 集群的情况下，通过工具如 MirrorMaker 或 Confluent Cluster Linking 在数据中心或云之间进行异步复制。这对于大多数用例来说已经足够好了。但是在灾难发生时，您会丢失一些消息。RPO > 0。

一个延伸的 Kafka 集群在三个数据中心部署了 Kafka brokers of 一个单一集群。这种复制是同步的（因为这是 Kafka 在一个集群中复制数据的方式），并且可以保证零数据丢失（RPO = 0）- 即使在发生灾难的情况下！

为什么不能总是使用延伸的集群？

• 数据中心之间需要低延迟（<~50ms）和稳定的连接。
• 需要三个（！）数据中心；两个是不够的，因为大多数（多数派）必须确认写入和读取以确保系统的可靠性。
• 它们很难设置、操作和监控，比在一个数据中心运行的集群要困难得多。
• 在许多使用案例中，成本与价值不成比例；在真正的灾难中，大多数组织和使用案例都会面临比丢失几条消息更严重的问题（即使这是关键数据，如付款或订单）。

要明确，在公共云中，一个区域通常有三个数据中心（=可用区）。因此，在云中，一个云区域是否算作扩展集群取决于您的服务级别协议。大多数SaaS Kafka提供的部署在此处是一个扩展集群。

然而，许多合规情况不认为一个云区域的Kafka集群足以保证服务级别协议和业务连续性，如果发生灾难。

Confluent构建了一个专门产品来解决（部分）这些挑战：多区域集群（MRC）。它提供了在扩展Kafka集群内进行同步和异步复制的能力。

例如，在金融服务场景中，MRC同步复制低交易量的关键交易，但异步复制高日志量：

• 处理从美国东部和美国西部输入的“付款”交易，采用完全同步复制
• 同一集群中的“日志”和“位置”信息使用异步 – 优化延迟
• 自动化灾难恢复（零停机，零数据丢失）

有关拉伸Kafka集群与两个Kafka集群之间的主动-主动/主动-被动复制的更多细节，请参阅我的全球Kafka演示。

Kafka云服务的定价（与自管理相比）

上述部分解释了为什么您需要根据项目需求考虑不同的Kafka架构。自管理的Kafka集群可以按照您的需求进行配置。在公共云中，完全托管的产品看起来不同（与任何其他完全托管的SaaS一样）。定价是不同的，因为SaaS供应商需要配置合理的限制。供应商必须提供特定的SLA。

数据流领域包括各种Kafka云服务。以下是Confluent当前云服务的示例，包括具有不同SLA、安全功能和成本模型的多租户和专用环境。

来源：Confluent

确保评估并了解不同供应商在公共云中提供的各种集群类型，包括总拥有成本、提供的可用性SLA、跨区域或云提供商的复制成本等。差距和限制通常被故意隐藏在细节中。

例如，如果您使用亚马逊托管的Apache Kafka流媒体服务（MSK），您应该知道其条款和条件规定“服务承诺不适用于由底层Apache Kafka或Apache Zookeeper引擎软件引起的导致请求失败的任何不可用、暂停或终止…”。

然而，定价和支持SLA只是比较的一个关键因素。在评估数据流平台时，您必须做出许多“构建与购买”的决策。

Kafka存储：分层存储和Iceberg表格式，仅存储数据一次

Apache Kafka 增加了 分层存储，以分离计算和存储。这一功能使得企业架构更加可扩展、可靠和具有成本效益。Kafka 的分层存储支持一种新的 Kafka 集群类型：以具有成本效益的方式在 Kafka 提交日志中存储 PB 级数据（就像在您的数据湖中）并附带时间戳和保证顺序，以便回溯进行历史数据的再处理。KOR Financial 是一个很好的例子，展示了如何将 Apache Kafka 用作长期持久性的数据库。

Kafka 实现了左移架构，仅为操作和分析数据集存储一次数据：

考虑到这一点，再次思考我在上面描述的多个 Kafka 集群的用例。您是否仍然应该将数据在静态数据库、数据湖或湖屋中从一个数据中心或云区域批量复制到另一个区域？ 不。您应该实时同步数据，仅存储一次数据（通常在对象存储中，如 Amazon S3），然后将所有分析引擎（如 Snowflake、Databricks、Amazon Athena、Google Cloud BigQuery 等）连接到这一标准表格式。

多个 Kafka 集群的真实成功案例

大多数组织拥有多个 Kafka 集群。本节探讨了不同行业的四个成功案例：

• Paypal（金融服务）– 美国：即时支付，欺诈预防。
• JioCinema（电信/媒体） – 亚太地区 : 数据集成、点击流分析、广告、个性化。
• Audi（汽车/制造） – 欧洲、中东和非洲 : 具有关键和分析要求的联网汽车。
• New Relic（软件/云） – 美国 : 全球范围内的可观察性和应用性能管理（APM）。

PayPal: 按安全区域分隔

PayPal 是一个数字支付平台，允许用户在全球范围内安全、方便地实时发送和接收资金。这需要一个可扩展、安全和合规的 Kafka 基础设施。

在 2022 年的黑色星期五期间，Kafka 流量峰值达到每日约 1.3 万亿条消息。目前，PayPal 拥有超过 85 个 Kafka 集群，每个假期季节，他们都会扩展其 Kafka 基础设施以应对流量激增。Kafka 平台继续无缝扩展，以支持这种流量增长，而不会对其业务产生任何影响。

今天，PayPal 的 Kafka 集群由超过 1,500 个代理组成，托管超过 20,000 个主题。事件在集群之间复制，提供 99.99% 的可用性。

Kafka 集群部署被分隔到数据中心内的不同安全区域：

来源：Paypal

Kafka集群根据数据分类和业务需求部署在这些安全区域。使用实时复制工具，如MirrorMaker（在此示例中，运行在Kafka Connect基础设施上）或Confluent Cluster Linking（通过直接使用Kafka协议进行复制的更简单且更少出错的方法），在数据中心之间镜像数据，这有助于灾难恢复并实现跨安全区域的通信。

JioCinema：按用例和SLA进行分离

JioCinema是印度一个快速增长的视频流媒体平台。该电信OTT服务以其广泛的内容提供而闻名，包括印度超级联赛（IPL）等现场体育赛事、新推出的动漫中心，以及全面覆盖巴黎2024奥运会等重大事件的计划。

数据架构利用Apache Kafka、Flink和Spark进行数据处理，如2024年在班加罗尔举行的Kafka峰会所示：

来源：JioCinema

数据流在各种用例中发挥着关键作用，改变用户体验和内容传递。每秒超过一千万条消息增强了分析、用户洞察和内容传递机制。

JioCinema的用例包括：

• 服务间通信
• 点击流/分析
• 广告跟踪器
• 机器学习和个性化

Kushal Khandelwal，JioCinema的数据平台、分析和消费主管解释说，并非所有数据都相同，各用例的优先级和SLA有所不同：

来源：JioCinema

数据流是一段旅程。与全球许多其他组织一样，JioCinema最初使用一个大型Kafka集群，包含1000多个Kafka主题和10万多个Kafka分区来应对各种用例。随着时间推移，关于用例和SLA的关注点分离演变为多个Kafka集群：

来源：JioCinema

JioCinema的成功故事展示了数据流媒体组织的普遍演变。现在让我们探索另一个例子，在这个例子中，从一开始为一个用例部署了两个非常不同的Kafka集群。

Audi：运营与联网汽车分析

汽车制造商奥迪提供了具有先进技术的联网汽车，集成了互联网连接和智能系统。奥迪的汽车支持实时导航、远程诊断和增强型车载娱乐。这些车辆配备了奥迪连接服务。功能包括紧急呼叫、在线交通信息和与智能家居设备的集成，以增强驾驶员的便利和安全。

来源：奥迪

奥迪在2018年Kafka峰会的主题演讲中展示了其联网汽车架构。奥迪企业架构依赖于两个具有非常不同SLA和用例的Kafka集群。

来源：奥迪

数据摄取 Kafka 集群非常关键。它需要全天候运行，并提供使用 Kafka 和 MQTT 连接数百万辆汽车的最后一英里连接。从 IT 端到车辆的反向通道有助于服务通信和OTA（空中升级）。

ACDC Cloud 是奥迪连接汽车架构的分析 Kafka 集群。该集群是许多分析工作负载的基础，使用诸如 Apache Spark 等批处理框架来处理大规模的IoT和日志数据。

这种架构早在2018年就已经提出。奥迪的口号“技术推动进步”展示了该公司在大多数汽车制造商部署类似方案之前就应用新技术进行创新的方式。所有来自连接汽车的传感器数据都会实时处理并存储以供历史分析和报告。

新颖可视化：全球多云可观察性

新颖可视化是一款基于云的可观察性平台，为全球客户提供应用程序和基础设施的实时性能监控和分析。

Andrew Hartnett，新颖可视化的软件工程副总裁，解释了数据流对于新颖可视化整个商业模型的关键性：

“Kafka是我们的中央神经系统。它是我们所做一切的组成部分。在我们公司中，110个不同工程团队的数百项服务以某种方式与Kafka相关，因此它确实是至关重要的。我们所寻找的是增长的能力，而Confluent Cloud提供了这一点。”

New Relic每分钟摄入高达70亿个数据点，并有望在2023年摄入2.5艾字节的数据。随着New Relic扩展其多云策略，各团队将使用Confluent Cloud在所有环境中实现统一视图。

“New Relic是多云的。我们希望与我们的客户在一起。我们希望在相同的环境和区域中，并希望我们的Kafka与我们同在。”Artnett在Confluent案例研究中说道。

多个Kafka集群是常态，而不是例外

事件驱动架构和流处理已经存在了几十年。随着Apache Kafka和Flink等开源框架与完全托管的云服务结合，采用率逐渐增加。越来越多的组织在Kafka的扩展上面临挑战。企业级数据治理、卓越中心、部署和运营自动化以及企业架构最佳实践有助于成功提供多个Kafka集群的数据流，以满足独立或协作的业务领域。

多个Kafka集群是常态，而非例外。混合集成、灾难恢复、迁移或聚合等用例使得实时数据流处理能够在各处以所需的SLA运行。