共计 3671 个字符，预计需要花费 10 分钟才能阅读完成。
音讯队列 Kafka 简介
Apache Kafka 是一个分布式流平台，作为互联网畛域不可或缺的音讯组件，在寰球取得了宽泛的利用。在应用过程中，Kafka 个别被作为音讯流转的外围枢纽，上下游零碎通过 Kafka 实现异步，削峰填谷。在大数据处理和实时数据处理畛域 Kafka 也是不可代替的组件。
Kafka 应用十分宽泛，在有些畛域应用曾经十分成熟，如日志收集，大数据处理，数据库等畛域。Kafka 跟上下游也有标准化的对接模块，如日志收集有 Flume，Filebeat，Logstash，大数据处理有 spark，flink 等组件。同时在一些小众的畛域则没有现成的工具能够间接对接，如对接某个小众的数据库，或者用户本人定制化的零碎。这时个别的对接办法是自行开发 Kafka 生产生产程序对接。
在不同零碎对接时通常会遇到以下问题：
- 公司的不同团队对同一个零碎有对接需要，各自开发反复造轮子，且实现形式不一，降级运维老本高。
- 各子系统由不同的团队开发，因而，各零碎中的数据在内容和格局上，存在人造的不一致性，须要进行格局解决，以打消各零碎数据之间格局的不同。
基于 Kafka 应用的宽泛度和上下游零碎的多样性思考，Kafka 推出了内置的上下游零碎对接框架 Kafka Connect。
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 插件，编写流程个别如下：
Tasks
Task 是 Connect 数据模型中的次要解决数据的角色。每个 connector 实例协调一组理论复制数据的 task。通过容许 connector 将单个作业合成为多个 task，Kafka Connect 提供了内置的对并行性和可伸缩数据复制的反对，只需很少的配置。这些工作没有存储任何状态。工作状态存储在 Kafka 中的非凡主题 config.storage.topic 和 status.storage.topic 中。因而，能够在任何时候启动、进行或重新启动工作，以提供弹性的、可伸缩的数据管道。
Task 再均衡
当 connector 首次提交到集群时，workers 会从新均衡集群中的所有 connector 及其 tasks，以便每个 worker 的工作量大致相同。当 connector 减少或缩小它们所需的 task 数量，或者更改 connector 的配置时，也会应用雷同的从新均衡过程。当一个 worker 失败时，task 在流动的 worker 之间从新均衡。当一个 task 失败时，不会触发再均衡，因为 task 失败被认为是一个例外情况。因而，失败的 task 不会被框架主动重新启动，应该通过 REST API 重新启动。
Converters
在向 Kafka 写入或从 Kafka 读取数据时，Converter 是使 Kafka Connect 反对特定数据格式所必须的。task 应用转换器将数据格式从字节更改为连贯外部数据格式，反之亦然。
默认提供以下 converters：
- AvroConverter：与 Schema Registry 一起应用；
- JsonConverter：适宜构造数据；
- StringConverter：简略的字符串格局；
- ByteArrayConverter：提供不进行转换的“传递”选项；
转换器与连接器自身解耦，以便在连接器之间天然地重用转换器。
Transforms
Connector 能够配置转换，以便对单个音讯进行简略且轻量的批改。这对于小数据的调整和事件路由非常不便，且能够在 connector 配置中将多个转换链接在一起。
开源问题
Kafka connect 线下独自部署时，设计的很不错了，但作为一个云服务提供时，还是存在了不少的问题，次要体现在以下几点：
- 与云服务的集成度不好：云厂商有不少闭源产品，对于开源产品的云托管版也会有访问控制等问题。
- 占用 Kafka 集群资源：每个 connector 工作都须要三个内置元信息 topic，占用云产品资源，对于元信息 topic 的误操作也会导致工作异样。
- 运维管控接口和监控简略：管控接口没法管制运行资源粒度，监控短少 connector 工作维度的指标。
- 与云原生架构联合不好：架构初始设计并非云原生，工作之间隔离度不够，负载平衡算法简略，没有动静自均衡能力。
基于 Kafka connect 部署在云上的种种问题，音讯队列 Kafka 团队在兼容原生 kafka connect 框架的前提下，以云原生的形式从新实现了 Kafka connect 模块。
阿里云音讯队列 Kafka Connect 解决方案
阿里云音讯队列 Kafka Connect 框架介绍
架构设计将管制面和运行面离开，通过数据库和 Etcd 进行工作散发和模块通信。底层运行环境采纳 K8S 集群，更好的管制了资源的粒度和隔离水平，整体架构图如下：
该架构在很好的解决了 Apache Kafka Connect 模块在云上遇到的问题：
- 与云服务的对接：运行环境部署时默认网络买通，运行面买通了访问控制模块；
- 占用 Kafka 集群资源：元信息采纳数据库和 Etcd 存储，不占用 Kafka topic 资源；
- 运维管控接口加强：加强了资源层面的管控 Api，能够精细化的管制每个工作的运行资源；
- 监控指标加强：工作维度全链路运行时 metrics 收集，监控数据从流入到流出的不同阶段的运行状况，呈现问题是及时定位问题；
- 云原生架构设计：管制面兼顾全局资源，实时监测集群负载，并可能主动实现负载平衡，失败重启，异样漂移等运维操作；
阿里云 Kafka Connect 介绍
阿里云音讯队列 Kafka 曾经反对的 Connector 类型如下：
涵盖了数据库，数据仓库，数据检索和报表，告警零碎，备份需要这些支流的应用场景。
依据不同场景的理论需要，阿里云音讯队列 Kafka Connect 次要两种实现形式：
- 通过扩大 Kafka Connect 框架，实现内部零碎与 Kafka 的间接对接。
- 对于须要数据处理的工作类型，通过 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 在软件架构中会表演越来越多的重要角色。
作者：尘辉
原文链接
本文为阿里云原创内容，未经容许不得转载。
