阿里云消息队列 Kafka 生态集成的实践与探索

作者：尘辉

消息队列 Kafka 简介

Apache Kafka 是一个分布式流平台，作为互联网领域不可或缺的消息组件，在全球获得了广泛的应用。在使用过程中，Kafka 一般被作为消息流转的核心枢纽，上下游系统通过 Kafka 实现异步，削峰填谷。在大数据处理和实时数据处理领域 Kafka 也是不可替代的组件。

Kafka 使用非常广泛，在有些领域使用已经非常成熟，如日志收集，大数据处理，数据库等领域。Kafka 跟上下游也有标准化的对接模块，如日志收集有 Flume，Filebeat，Logstash，大数据处理有 spark，flink 等组件。同时在一些小众的领域则没有现成的工具可以直接对接，如对接某个小众的数据库，或者用户自己定制化的系统。这时一般的对接方法是自行开发 Kafka 生产消费程序对接。

在不同系统对接时通常会遇到以下问题：

• 公司的不同团队对同一个系统有对接需求，各自开发重复造轮子，且实现方式不一，升级运维成本高。

• 各子系统由不同的团队开发，因此，各系统中的数据在内容和格式上，存在天然的不一致性，需要进行格式处理，以消除各系统数据之间格式的不同。

基于 Kafka 使用的广泛度和上下游系统的多样性考虑，Kafka 推出了内置的上下游系统对接框架 Kafka Connect。

image.png

Kafka Connect 介绍

Kafka Connect 是一个用于将数据流输入和输出 Kafka 的框架。下面介绍 connector 的一些主要概念：

• Connectors：通过管理 task 来协调数据流的高级抽象

• Tasks：如何将数据复制到 Kafka 或从 Kafka 复制数据的实现

• Workers：执行 Connector 和 Task 的运行进程

• Converters：用于在 Connect 和外部系统发送或接收数据之间转换数据的代码

• Transforms：更改由连接器生成或发送到连接器的每个消息的简单逻辑

Connectors

Kafka Connect 中的 connector 定义了数据应该从哪里复制到哪里。connector 实例是一种逻辑作业，负责管理 Kafka 与另一个系统之间的数据复制。

connector 有一些开源的实现。同时用户也可以从头编写一个新的 connector 插件，编写流程一般如下：

image.png

Tasks

Task 是 Connect 数据模型中的主要处理数据的角色。每个 connector 实例协调一组实际复制数据的 task。通过允许 connector 将单个作业分解为多个 task，Kafka Connect 提供了内置的对并行性和可伸缩数据复制的支持，只需很少的配置。这些任务没有存储任何状态。任务状态存储在 Kafka 中的特殊主题 config.storage.topic 和 status.storage.topic 中。因此，可以在任何时候启动、停止或重新启动任务，以提供弹性的、可伸缩的数据管道。

image.png

Task 再平衡

当 connector 首次提交到集群时，workers 会重新平衡集群中的所有 connector 及其 tasks，以便每个 worker 的工作量大致相同。当 connector 增加或减少它们所需的 task 数量，或者更改 connector 的配置时，也会使用相同的重新平衡过程。当一个 worker 失败时，task 在活动的 worker 之间重新平衡。当一个 task 失败时，不会触发再平衡，因为 task 失败被认为是一个例外情况。因此，失败的 task 不会被框架自动重新启动，应该通过 REST API 重新启动。

image.png

Converters

在向 Kafka 写入或从 Kafka 读取数据时，Converter 是使 Kafka Connect 支持特定数据格式所必需的。task 使用转换器将数据格式从字节更改为连接内部数据格式，反之亦然。

默认提供以下 converters：

• AvroConverter：与 Schema Registry 一起使用；

• JsonConverter：适合结构数据；

• StringConverter：简单的字符串格式；

• ByteArrayConverter：提供不进行转换的“传递”选项；

转换器与连接器本身解耦，以便在连接器之间自然地重用转换器。

image.png

Transforms

Connector 可以配置转换，以便对单个消息进行简单且轻量的修改。这对于小数据的调整和事件路由十分方便，且可以在 connector 配置中将多个转换链接在一起。

开源问题

Kafka connect 线下单独部署时，设计的很不错了，但作为一个云服务提供时，还是存在了不少的问题，主要体现在以下几点：

• 与云服务的集成度不好：云厂商有不少闭源产品，对于开源产品的云托管版也会有访问控制等问题。

• 占用 Kafka 集群资源：每个 connector 任务都需要三个内置元信息 topic，占用云产品资源，对于元信息 topic 的误操作也会导致任务异常。

• 运维管控接口和监控简单：管控接口没法控制运行资源粒度，监控缺少 connector 任务维度的指标。

• 与云原生架构结合不好：架构初始设计并非云原生，任务之间隔离度不够，负载均衡算法简单，没有动态自平衡能力。

基于 Kafka connect 部署在云上的种种问题，消息队列 Kafka 团队在兼容原生 kafka connect 框架的前提下，以云原生的方式重新实现了 Kafka connect 模块。

阿里云消息队列 Kafka Connect 解决方案

阿里云消息队列 Kafka Connect 框架介绍

架构设计将控制面和运行面分开，通过数据库和 Etcd 进行任务分发和模块通信。底层运行环境采用 K8S 集群，更好的控制了资源的粒度和隔离程度，整体架构图如下：

image.png

该架构在很好的解决了 Apache Kafka Connect 模块在云上遇到的问题：

• 与云服务的对接：运行环境部署时默认网络打通，运行面打通了访问控制模块；

• 占用 Kafka 集群资源：元信息采用数据库和 Etcd 存储，不占用 Kafka topic 资源；

• 运维管控接口增强：增强了资源层面的管控 Api，可以精细化的控制每个任务的运行资源；

• 监控指标增强：任务维度全链路运行时 metrics 收集，监控数据从流入到流出的不同阶段的运行情况，出现问题是及时定位问题；

• 云原生架构设计：控制面统筹全局资源，实时监测集群负载，并能够自动完成负载均衡，失败重启，异常漂移等运维操作；

阿里云 Kafka Connect 介绍

阿里云消息队列 Kafka 已经支持的 Connector 类型如下：

image.png

涵盖了数据库，数据仓库，数据检索和报表，告警系统，备份需求这些主流的使用场景。

根据不同场景的实际需求，阿里云消息队列 Kafka Connect 主要两种实现方式：

1. 通过扩展 Kafka Connect 框架，完成外部系统与 Kafka 的直接对接。

2. 对于需要数据处理的任务类型，通过 Kafka->函数计算（下简称 fc）->外部系统的，在 fc 上可以灵活的定制化处理逻辑。

具体 connect 的实现方式如下：

数据库

数据库之间备份一般不会走 kafka，msyql->kafka 一般都是为了将数据分发给下游订阅，在 mysql 数据有变更时作出告警或这其他响应，链路 mysql->kafka->订阅程序->告警/变更其他系统。

数据仓库

数据仓库阿里云上常用的是 maxCompute，任务特点是吞吐量大，也有数据清洗需求，一般流程为 kafka->maxCompute，然后 maxCompute 内部任务进行数据转换。也可以在入 maxCompute 之前进行数据清洗，链路一般为 kafka->flink->maxCompute。对于数据转换简单或者数据量小的任务，可以使用函数计算替换 flink，链路为 kafka->fc->maxCompute。

数据检索和报表

通用的数据检索和报表一般通过 es，数据传入 es 前需要做清洗处理，适合的路径 kafka->flink->es/kafka->fc->es。

告警系统

告警系统中使用 kafka 一般流程 前置模块->kafka->订阅程序->告警模块，这种最好的方式是 前置模块->kafka->fc->告警。

备份需求

有些数据可能需要定期归档，做长期保存，oss 是一个不错的介质，这种场景一般只需要保存原属数据，所以好的方式可能是 kafka->oss。如果数据需要处理，可以通过 Kafka->fc->oss 链路。

阿里云消息队列 Kafka 生态规划

消息队列 Kafka 当前支持的 connect 都采用自研新架构独立开发，对于主流的使用场景已经有了不错的覆盖，但同时也可以看到，Kafka 生态发展非常迅猛，Kafka 的使用场景也越来越多，开源 Kafka connect 也在不断的发展，下一步消息队列 Kafka 会对接开源 Kafka connect，让开源 Kakfa connect 可以无需修改，无缝的运行在自研的架构上。

总结

Kafka 在互联网架构中已经占据了重要的位置，同时也在积极往上下游拓展，除了 Kafka connect，还有 Kafka Streams，Ksql，Kafka Rest Proxy 等模块也在不断完善和成熟，相信在后续的发展中，Kafka 在软件架构中会扮演越来越多的重要角色。

点击此处，进官网了解更多详情