音讯队列 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在软件架构中会表演越来越多的重要角色。
作者：尘辉
原文链接
本文为阿里云原创内容，未经容许不得转载。