什么是Kafka Connect runtime？其对架构组件关系有何影响？

别扯太学术的定义，runtime本质就是给上层可插拔逻辑提供托管运行环境的底层常驻程序。它自己不硬编码任何具体业务逻辑，专门兜底所有业务逻辑跑起来都要用到的通用脏活：生命周期管理、资源调度、故障重试、状态持久化、集群协调、底层基础设施适配。
举个所有人都熟的例子：JVM就是Java程序的runtime，你写的Java业务代码不用自己管内存怎么分配、垃圾怎么回收、怎么适配不同操作系统，这些通用活全是JVM兜着，你只需要写业务逻辑就行。
判断一个组件是不是runtime有个很简单的标准：你写的业务逻辑/插件没法独立跑，必须丢到它里面才能被调度执行，它就是承载你逻辑跑的runtime。

Kafka Connect从设计之初就是个标准的runtime，不是很多人误以为的“一堆Connector凑出来的同步工具包”，它和其他组件的边界划得非常清楚：

• 和Connectors的关系：Connector是完全运行在Connect runtime内的可插拔业务插件，本身不是独立进程。自定义Connector的开发者根本不用关心任务怎么拆分到多节点、Task挂了怎么重启、消费位点怎么持久化、集群扩缩容时怎么重平衡、类依赖冲突怎么解决，这些通用能力全是runtime内置提供的。Connector只需要实现两个最核心的业务逻辑：一是告诉runtime自己负责的同步任务该怎么拆分成可并行的Task，二是实现单条数据从源系统读取/往目标系统写入的逻辑，剩下的全交给runtime托管。哪怕你一个Connector都不装，Kafka Connect集群照样能正常启动，只是没有可调度的业务逻辑而已。
• 和Converters的关系：Converter是runtime托管的标准序列化/反序列化插件，runtime负责在Connector和Kafka之间做数据流转时自动调用对应Converter做格式转换。Connector只需要输出/接收通用的结构化数据对象（比如Struct类型），根本不需要感知数据最终要序列化成JSON、Avro还是Protobuf，也不用自己处理序列化逻辑——这些全是runtime拿到Converter配置后自动完成的，两边完全解耦。
• 和Kafka Broker本身的关系：Connect runtime是依附于Kafka运行的上层托管服务，它自己的所有元数据（包括Connector配置、Task运行状态、消费位点、集群节点信息）全部存在Kafka的内部主题里，不需要额外部署元数据库。runtime会统一维护和Kafka的生产/消费客户端实例、连接池、重试流控逻辑，上层Connector完全不需要自己创建Kafka客户端，直接通过runtime提供的上下文就能和Kafka做数据交互。
• 和单消息转换（SMT）、配置提供者这类其他插件的关系：这类组件和Converter一样，全是runtime托管的可插拔能力链，runtime会按照用户配置的顺序自动触发执行，Connector完全不需要感知这些逻辑的存在，也不用做任何适配。

内容的提问来源于stack exchange，提问作者Mandroid