揭秘Kora:Kafka的云原生事件流处理平台

序言

​ VLDB，即（International Conference on Very Large Data Bases，大规模数据库国际会议，简称VLDB），是世界顶级的数据库学术会议之一。每年的VLDB都会聚集全球顶尖的数据库技术专家和创新者，分享他们的研究成果和实践经验。在今年的VLDB2023大会上，工业界的最佳论文《Kora: A Cloud-Native Event Streaming Platform For Kafka》荣获殊荣，其详述了Confluent公司基于Kafka设计的云原生事件流平台Kora的实现原理。作为一名专注于Kafka云原生内核技术和生态技术的开发者，一直关注着Kafka和Confluent等行业领先公司的动态。此奖项的颁发，再次证明Kafka在事件流处理领域的价值和竞争力。尽管科技日新月异，新技术层出不穷，然而Kafka和Confluent这样的经典技术还依然保持着竞争力和应用价值，实在令人欣慰。

​ 在讲Kora之前，让我们来了解一下Kora及Kafka和Confluent的发展历史。

​ Kafka作为主要的事件队列和中间件，对许多互联网开发者来说并不陌生。然而，Kafka并非简单的消息队列，而是分布式事件流处理领域的佼佼者。它与传统消息中间件不同，一直聚焦在大数据、实时处理以及数据流领域。由于Kafka的出色表现，技术生态上逐渐诞生了Kafka core（事件流队列/消息队列），Kafka Stream（事件流流式处理和分析），Kafka Connect（数据生态连接，连接上下游数据系统）等丰富的技术产品。

​ 互联网的飞速发展使得数据规模呈指数级增长，数据的重要性日益显著。无论是数据报表还是数据分析，亦或是机器学习和人工智能，都需要快速、准确的数据处理。这为流数据处理领域提供了巨大的市场和技术机遇。因此，Kafka的创始团队成立了以Kafka为核心的商业化技术公司——Confluent，并成功上市。截至撰写本文2024年3月，Confluent的市值高达104亿美元，这无疑是基础架构领域非ToC领域的成功案例。

​ 随着云计算的发展和普及，【云原生】概念的深入人心，从严格定义上，Kafka 最初是在非云原生世界中构建的，这使得它无法以经济有效且高效弹性的方式直接在当今云上的基础设施中使用，因此遭遇了诸多其他基于云原生设计的消息产品的技术挑战。

​ 针对Kafka的云原生化，在国内，各大云厂商诸如阿里云，腾讯云，字节等也在跟进推出自己的云原生化的事件流解决方案，其核心竞争力始终围绕【弹性】、【性能】和【成本】建设，有Alikafka，Ckafka，BMQ等产品；在创业领域，也诞生了一系列创业公司，如基于pulsar作为技术底座的StreamNative，其核心特征是计算与存储分离架构，带来的收益是【弹性】能力的极大提升；如100%兼容Kafka协议的AutoMQ，其核心竞争力目前也是存算分离架构提供极致的降本和极高的弹性。

​ Confluent作为Kafka创始人孵化的创业团队，这个领域耕耘了十多年，对开源Kafka这些问题和痛点有意而为之，其本质原因是基于Kafka的云原生化存在十分重要的商业价值，既要在开源上处于领先地位，又需要在某些重要特性和功能上在商业化和开源上做出差异化，吸引客户付费使用，因此，在一些关键的特性上，开源是落后于商业化的。Kora的设计实现则首次披露了Confluent如何基于Kafka设计云原生事件流平台，可以打个比方，Kora，其对标的是国内各大云厂商诸如阿里云的Alikafka，腾讯云的Ckafka，华为云的Kafka等诸多大厂的云平台的设计实现。

​ 在云原生下，大规模运行 Kafka 面临着非常多的技术挑战，很欣慰能看到Kora的设计实现，笔者结合多年云计算流处理消息相关开发实践经验，发现其很多设计与国内各大云厂商不谋而合，但也有一些独到的实践值得借鉴和学习，笔者将在本文重点研究 Kora 提供的核心设计以及它使用哪些技术来构建大规模的云原生解决方案。

论文：https://www.vldb.org/pvldb/vol16/p3822-povzner.pdf

1 事件流

​ 在介绍Kora之前，先介绍事件流。事件流解决的是事件从生产到消费如何实时处理的问题，事件如流水一样持续不断的产生，相应的系统需要具备实时的处理能力。图1显示Kafka事件流系统的模型视图。Kafka在中间，生产者将数据写入日志的末尾，而消费者可以从任意偏移量中读取数据。事件由生产者写入Kafka之后，消费者可以通过Kafka的消费订阅，高扇出地即时地读取数据，可以这么理解，Kafka是大数据里面的高速公路。目前，Confluent收购了Flink初创团队创建的Immerok，数据的流式计算，流式存储和处理，流式传输正变得越来越紧密。

事件流模型

2 顶层设计

​ Kora是云原生的事件流平台，云原生的Kora具备何种特性呢？Kora给出的答案是：除了开源Kafka具备的基本的高可用性，持久性和可扩展性外，还提供【弹性】、【成本效率】、【性能】、【多租户】和【跨云同步】等差异化能力。因此，Kora的设计存在两个层面的设计，一方面是有别开源Kafka的架构设计，另一方面是云原生方案的设计。

1. 在Kafka的架构设计上，采用存算分离架构设计，元数据层面基于Raft协议实现分布式环境下的自我管理。这两个设计有效促进了Kafka的【弹性】、【性能】和【成本效率】的提升。
2. 在云原生设计上，提供了最核心对资源的抽象设计-Confluent Kafka Units（简称CKU），CKU是【弹性】、【成本效率】、【性能】、【多租户】和【跨云同步】等核心云原生能力的基石。CKU解决的是在跨云和跨云下不同的硬件中提供一致的性能体验。Confluent Cloud与国内云厂商不同的点之一是横跨三种云(AWS、GCP、Azure)和73个地区的数万个集群，如何远离底层硬件，在追求最佳性价比的过程中试验更新的硬件类型和配置，提供一致的性能和体验是非常具有挑战的。虽然更新、更快的硬件在不断满足客户日益增长的性能需求，但现实是，如果要评估新硬件适配多样化的工作负载需求，想获得最佳性价比，需要大量的测试和投入。

3 架构设计

​ 本节介绍Kora的设计目标和架构设计。

3.1 设计目标

• 可用性：单AZ提供99.95%的可用性，多AZ提供99.99%的可用性。

• 弹性：支持用户对集群规模的扩容和缩容，此外，Kora还提供自适应工作负载模式的变化，给集群大小提供最佳性能。

• 性能：高吞吐，低延迟，除了软件层面的优化，针对硬件资源，随着硬件资源的推陈出新，Kora会有意识地更新硬件资源，因此，随着时间的推移，用户可能会看到他们的应用程序的性能提升。

• 多租户：支持多租，尽可能降低客户成本。

• 多云支持：Kora运行在AWS、GCP和Azure上，最小化屏蔽云之间的资源差异，在服务交付上给用户提供统一的体验。

3.2 架构设计

Confluent Cloud中的控制面和数据面

​ 控制面和数据面解耦设计：如图2所示，分为集中式的控制面和分布式的数据平面。

​ 控制面承担资源管理的角色：控制面使用Kubernetes分配物理资源(包括计算、存储、网络等)以及初始化集群，在跨可用区场景中，集群会均匀分布在不同的可用区。

​ 数据面承担数据处理的角色：数据面由独立的物理Kafka集群( physical Kafka clusters，物理Kafka集群，简称PKC)组成和管控相关的微服务所构成。一个PKC托管一个或多个LKC（logical Kafka cluster，逻辑Kafka集群，简称LKC）。事件的生产和消费通过网络层流入和流出数据面。

这里值得借鉴的是：数据面的网络层使用Proxy，通过SNI(服务器名称标识)路由到各个Broker。Proxy是无状态的，独立扩展，因此，可以支持大型集群且不会遇到端口耗尽等瓶颈。在多租场景，笔者就遇到过端口不足的问题。

​ 控制面和数据面解耦在云计算或者基础架构领域可以说是比较常见的设计，Kora在生产环境上使用了两个比较重要的Kafka特性：第一，元数据自管理；第二，分层存储。

3.3 元数据管理

​ 在分布式系统中，如何协调分布在不同机器的服务，实现一致性的数据管理在分布式领域一直都是核心问题。一般在分布式系统设计中，都会避免自己设计一致性协议，而采用传统的ZooKeeper进行分布式协调和管理元数据。Kafka在2.8之前就一直依赖ZooKeeper进行集中式地管理元数据，在2.8开始推出基于Raft协议的元数据自我管理，简称Kraft，在Kafka 3.6版本则标志生产可用，截止当下，Kafka最新版本是3.7，在未来的4.0会彻底去除ZooKeeper的依赖。

为什么Kora要自己做元数据管理？

这是Kafka在技术演进上重要的一次升级。ZooKeeper是强一致性系统，因此性能不高，在百万分区下，会涉及大量的元数据同步和管理，基于ZooKeeper的元数据管理非常容易遇到性能问题，同时去ZK，会减少一个额外组件的运维，有利于系统的自我管理能力的进一步提升，因为Kafka比ZooKeeper更懂Kafka。这里额外对比一下Pulsar，Pulsar一直在挑战Kafka的地位，但是Pulsar存在一个问题，那就是部署和运维的组件较多，较复杂。好的技术产品，是需要将复杂问题闭环，对外部呈现最简单，最符合直觉的服务。

​ 在元数自我管理方面，Kora有一个实践值得借鉴：那就是，元数据管理的节点独立部署，只承担元数据管理的角色，独立部署在滚动升级场景，会减少选举带来的不稳定性，在大规模部署Kafka场景下，这不失为是一种好的实践。

3.4 分层存储

​ 在2018时候，分层存储设计在Kafka开源领域的设计就提出来了，即KIP-405，Kafka目前的存储和计算是在同一台机器上的，随着数据大小的增加，这种架构最终会成为瓶颈。目前3.6版本Kafka推出了分层存储，但是不建议生产可用，3.6的分层更接近是定义了使用的标准和协议，也就是一个框架，底层如何存储和处理数据还是需要开发者自己实现。

为什么时间这么久，完整的分层存储没有开源？

1. 因为分层存储存在极大的商业价值，并非技术不可行，这是商业化和开源的区别，Kora在云上大规模使用了分层存储技术，该技术能提供无限存储，在大量数据，长时间的数据存储场景中，能极大降低客户成本。
2. 在冷热数据中，冷数据的存储对接的可能是不同的系统，如亚马逊的S3，如HDFS，不同存储系统的存储的读写API都不一样，因此定义标准和协议更为现实。

​ 分层存储同时带来了一个非常好的优势，那就是【弹性】的极大提升。传统Kafka很难称为云原生，传统Kafka在扩缩容方面，涉及大量的数据迁移，因此Kafka的弹性效率不高。分层存储之后，只有少量热数据保留本地，因此在弹缩方面设计的数据迁移就很少，因此Kora在弹缩能力上比传统Kafka高很多，这个技术也是构建Kora云原生的核心基石。

4 云原生的设计

在本节中，我们将讨论如何设计Kora的云原生属性，本节中描述的构建模块也构成了我们多租户服务的基础。

这节，我们能近距离明白具备什么特性才能成为云原生。Kora给出的答案是：资源模型与抽象、集群组织、弹性、可观测能力、自动迁移、数据容灾以及升级。

4.1 资源模型

​ 资源模型：资源模型对提供真正的云原生体验非常重要，因为用户不必考虑云的底层细节，如CPU、内存、网络、IOPS/吞吐量/存储带宽等。Kora定义CKU（Confluent Kafka Units，Confluent的Kafka资源使用单位，简称CKU），CKU可以简单理解就是我们测距的米，测重的千克，测面积的平米等单位，一个CKU代表了客户能使用多少带宽/请求速率/网络连接总数/建连速度。

在定义了CKU后，在云上Kora的服务的提供都以CKU作为单位，但是呢？CKU是一种理想的设定，需要标准的使用方式才能使用好CKU，尤其是在云上，笔者对此感触颇深，云上的客户在使用方式千奇百怪，技术能力可能也参差不齐，往往存在诸多不佳实践，很难达到CKU的使用上限。因此Kora定义了集群负载的概念，用以衡量集群的负载。

​ 集群负载：集群负载存在最大的挑战是：直接使用CPU、IOPS/磁盘吞吐量或网络带宽不足并不科学，也不准确，在CPU很高时候，可能客户的延时并不大，可能客户运行的服务非常稳定，因此Kora使用Kingman公式的排队论定律来研究延迟和服务器利用率之间的关系。

Confluent 基于Kingman公式的排队论定律，参数采用时延，系数则是通过大量的测试得出，因为不同云之间的资源性能不一致，因此每种云的系统都不一样。集群负载实施会较为复杂，因为需要大量测试确定系数，Kora对三种云的不同资源硬件进行了大量实验，在CPU密集型场景中，证明Kingman的排队定律计算的负载参数非常有效，在低CPU的场景下，Kora则会使用带宽利用率提供集群负载指标

4.2 集群组织

​ 集群组织方面，Kora的设计和国内的思路设计基本一致，Kafka集群需要的各种微服务来实现可观察性、审计、计费等功能，这些功能Kora没有为这些服务提供专用资源，而是将它们与Kafka代理捆绑在一起，同时保留大约80%的VM资源供Kafka代理使用。

4.3 弹性

​ 弹性：前面Kora定义了CKU作为资源的单位，Kora的弹性，即能根据工作负载不断变化，以CKU作为粒度增加或者减少资源，弹性是云原生核心特征也是技术竞争力，其中Kora的弹性设计主要如下核心点：

1. **自适应的数据均衡**：Kora改造了Kafka的Controller组件，增加了收集集群中每个Kafka代理的指标，集中式地实时掌握集群负载情况，并通过基于简单的启发式重新分配副本，因此实现自我数据平衡的能力。
1. 元数据管理是基于Kraft协议独立部署和运行的，因此弹缩期间的选举造成的稳定性影响减少。
1. 数据采用分层存储，因此资源弹缩过程（增加节点或者减少节点）迁移数据的量很少，弹缩性能提升很大。

4.4 可观测性

​ 可观测性对于运行一个大型分布式系统至关重要，开源kafka提供了丰富的可观测指标，商业化提供更多的观测指标不足为奇，其中笔者认为Kora较为突出的设计是：

​ 端到端延时的设计：在传统情况下，我们可以很精确的了解服务端Broker的各种延迟指标和物理资源使用情况，但是事件诞生到Broker，Broker到消费者，这两个观测指标是游离分布式系统之外的。如何探测端到端的延迟，是一个非常有意义的挑战。为了弥补这一差距，Kora在每个集群中包括一个健康检查代理，该代理位于内部网络之外，并通过产生和消费请求不断探测端到端的延迟，以检测可用性或性能方面是否有损失。

4.5 自动迁移

​ 由Kora支持的Confluent Cloud为多区域集群提供99.99%的正常运行时间SLA。因为Kora是在多云下提供服务，当底层不同的云厂商不都提供相同的SLA保证时，维护4个9的可用性具有挑战性，事实上，Confluent的数据披露大部分可用性失效是由云基础设施故障引起的，Kora针对这块的设计是：

​ 健康巡检：每个代理运行一个健康巡检线程，认为代理不健康会自动迁移，在传统情况，自动迁移如果涉及大量数据回来迁移风暴，但是依然得益于分层存储的设计，Kora的自动迁移效率很高。

4.6 数据容灾

​ 在数据容灾方面，Kora有一个优秀的设计实践：镜像复制，Kora提供CLuster Link能力，比开源的mirrormaker2更强，允许在两个独立的Kafka集群之间以无缝的方式复制所有数据和所有元数据（包括不需要映射的消费位点）状态，因此，在源集群故障时候，只需将客户端指向新的集群端点即可。

4.7 升级

​ 升级：升级对核心服务的持续改进和创新至关重要，但是在大规模事件流处理过程，如何安全地尽可能降低抖动地升级是一个非常大的挑战也是持续打磨的过程。目前Kora的升级思路如下

1. 滚动升级，小集群只滚动一个，大集群滚动会多个，滚动下一组的过程会根据一系列内部健康指标是否达标在进行下一轮滚动。
1. 跨可用区实例确保所有副本不会在同一个可用区，减少滚动的影响。

5 多租户设计

​ 多租户能在大规模场景下，提供真正的云原生体验:更高层次的资源抽象、弹性和随用随付模型以及更低的成本，但是多租户的设计是非常具有挑战的，尤其是云上面对的客户来自各行各业，其中资源隔离是最核心的技术挑战，因为隔离如果没有做到位的话，很容易互相影响，造成故障。

5.1 逻辑集群

​ 命名空间隔离，设计了逻辑Kafka的概念，LKC的数据隔离是通过身份验证(通过API密钥)、授权和加密实现的。Kafka本身不支持命名空间隔离。Kora通过使用相应的逻辑集群ID(每个LKC的唯一标识符)标志每个集群资源(主题、消费者组、acl等)使用。

逻辑集群ID命名空间隔离

5.2 性能隔离

​ 资源隔离设计：Kora实施租户级配额来实现性能隔离，隔离的资源分别如下:

1. 入口和出口带宽：通过配额机制实现，当触发带宽额度后，会对客户连接进行静默处理。
2. CPU使用：对请求和请求处理时间进行限制，当请求处理时间大于限定值会静默处理。
3. 网络连接数量：限定网络连接数量，超过一定的连接数会报错。
4. 连接尝试率：限定网络重连的时间间隔，超过限度会报错。
5. 内存：影响内存使用的工作负载行为配额。分区数创建/删除配额：业务上限定分区数的总数。

​ 分布式配额设计：在随用随付模式下，由于大多数租户使用的带宽远远低于其逻辑集群的最大带宽容量，但是多租户下，不同租户的峰值时间不一，负载分布在不同的节点，不同时刻，不同节点的负载也不一样，如何有效利用集群资源提供更好的服务，Kora通过使用动态配额机制来解决这个问题。该机制根据租户的带宽消耗来调整带宽分配。这是通过使用共享配额服务来管理配额分配来实现的，这种设计如下：

1. 定义节点的最大物理带宽额度
2. 提供配额协调器用于分布式节点流量的收集和处理
3. 节点定期向配额协调器上报每个租户和每个Broker的带宽使用数据和相关的限额信息
4. 配额协调器汇总这些数据，重新计算每个代理-租户对的还能使用多少额度，并以将可使用的额度分发给相关节点
5. 为了适应大型多租户环境，部署了多个配额协调器，Broker通过哈希将每个配额实体映射到一个配额协调器

配额协调器设计

6 总结

​ 当下，互联网技术在不断发展，回顾过去，短短几年，从移动化，大数据，云计算，区块链到现在的人工智能，世界的发展日新月异。而这些技术的背后也催生了大量的数据，数据的价值被证明意义非凡，和水、电、燃气一样无处不在，而实时数据的处理需求，让事件流系统也成为越来越重要的基础设施，Kafka目前是事件流的领导者，Confluent也在不断的往事件流的流处理和流计算发展，Kora在某种程度上也代表了这个技术的前沿，VLDB 2023这篇工业界的Best Paper披露了很多好的设计和实践，非常值得我们借鉴。技术在不断发展，新的前沿的知识需要终身我们不断持续学习，百尺竿头，更进一步。