rocketmq Connect/EventBridge原理源码分析I-架构，服务和组件

1 简介

RocketMQ Connect是RocketMQ数据集成重要组件，可将各种系统中的数据通过高效，可靠，流的方式，流入流出到 RocketMQ，它是独立于 RocketMQ 的一个单独的分布式，可扩展，可容错系统，它具备低延时，高靠性，高性能，低代码，扩展性强等特点，可以实现各种异构数据系统的连接，构建数据管道，ETL，CDC，数据湖等能力。

RocketMQ EventBridge架起高可伸缩，高吞吐的事件通道。 EventBridge可以看作是runtime(connect)的管理台，构建逻辑(based domain模块)云事件通道，调用runtime api(adapter)创建物理(可运行)事件通道

本系列文章分析RocketMQ Connect和RocketMQ EventBridge源码原理，为两组件的改造和应用开发提供支持，

本文是第一部分，分析架构，服务和组件

第二部分，分析worker，worker connector，worker source task，worker sink task

2 关键词

CloudEvent

OpenMessaging OpenMessaging 是 Linux 基金会下一个开源组织，致力于制定消息领域的标准；

3 参考资料

4 发布计划

M1 事件通道构建控制台

Ø 拖拽方式构建事件通道，包括source connector/sink connector，及其transform链；集成rule based transform

Ø 可视化worker/worker集群状态和启停，connector/task启停

M2 分布式重构

Ø 引入elastic-platform(based zookeeper)，实现worker集群管理

配置服务，集群成员变更，分片

M3 动态资源管理

Ø 引入资源管理器，支持k8s资源申请

5 Connect

本章介绍connect平台

5.1 集群架构

若干worker组成集群，同一集群的worker共同运行同一个事件通道，worker间互为负载均衡和故障转移。

5.2 逻辑架构

上图是事件通道的展开，事件通道是逻辑定义，每个worker自身运行事件通道的部分任务，事件通道多个源和多个目标，源与目标之间转换链，其中filter转换决定是否流到对应的sink

5.3 组件和场景

*上面包视图根据个人理解有部分改动

startup worker启动，支持standalone和分布式两种模式

rest worker的rest接口，输出worker内connector和任务的操作

服务 集群服务，状态服务，配置服务，位点服务，分片服务等

worker connect执行单位，封装连接器/任务，转换执行，状态维护

controller 控制器起着门面服务的作用，持有服务实例

plugin 类加载器，载入jar包，类型

utils ServiceThread和datasync组件

还有些组件本系列没有分析：

connector，transform

5.4 原理分析

原理源码分析通过场景用例分析完成，包括启动，服务，worker(包括连接器和任务)，系统组件

5.4.1 启动(startup)

5.4.1.1 worker启动

worker启动有两种模式，分布式和standalone，流程差不多，下面分析一下分布式模式启动

启动从startup类发起，该类从命令行获取配置，实例化服务类，插件类，然后构建控制器；

控制器实例和初始化各服务和功能类，控制器两个职责

1. 作为门面服务支持rest服务；

2. 持有服务类，传递给Worker

5.4.1.2 worker集群启动

目前connect并没有worker集群的启动实现，worker节点启动，加入集群，集群的其他worker收到消费组变更通知，触发重分片

5.4.2 服务

下面详细分析每个服务

5.4.2.1 分片服务

分片服务负责分派连接器和任务到worker

RelanceService 分片服务，继承ServiceThread，获得定时执行和唤醒执行的特性

RebanceImpl/
AllocateConnAndTaskStrategy 分片的实现类，支持不同的分片策略；分片完成，连接器/任务分派到位，调用Worker重新启动连接器和任务

WorkerStatusListenerImpl 实现WorkerStatusListener接口，监听集群变化，唤醒分片服务，驱动重新分片

ConnectorConnectorConfigChangeListenerImpl 实现
ConnectorConfigUpdateListener接口，监听connector/task配置变更，唤醒分片服务，驱动重新分片

5.4.2.2 分片策略

分片策略有2点关键

1. 分片服务集成ServiceThread，支持唤醒执行和定时执行，而且定时时间间隔1秒，原因可能是集群变更事件有丢失，或者执行失败可能，引起任务丢失，频繁的分片要求分片策略有很高的稳定性，尽量减少连接器和任务的转移

2. 分片每个worker进行，分派属于自身worker的部分给自己，因此分片策略需与worker相关，不遗漏，不重复的分派

connect自带两个实现，默认实现，workerId排序，然后哈希分派；另一个是哈希一致性，这里不详细分析

5.4.2.3 集群服务

集群服务实现比较简单，职责是监听集群成员变化，对外输出WorkerStatusListener监听接口，集群成员变更事件，驱动执行分片服务

监听集群成员变化是通过订阅消息引擎的消费组成员变更事件

规划引入zookeeper，重新实现集群服务，配置服务

5.4.2.4 配置服务(config)

配置服务负责连接器/任务配置存储，同步；配置新增，变更；连接器/任务启停

ConfigManagementService 配置管理服务接口，有local，memory，rocketmq实现，适配standalone和分布式模式，memory只能在standalone；local和rocketmq可用作分布式模式*

DataSync组件 负责分发请求到集群的所有worker，请求分两类，配置变更；connector/task启停操作，两类请求有重叠，配置变更最终通过重新分片反映到connector/task

对于配置变更，worker不直接处理，通过DataSync分发变更到集群，当然包括自身，在消息消费中处理，这样所有配置在每个worker有完整备份，用于故障转移，新worker同步

对于启停操作，connector/task分派到不同worker，worker不直接处理，通过DataSync分发变更到集群，各worker收到后识别是否自身处理

ConnectorConfigUpdateListener 配置变更通知接口，目前有一个实现，该实现分配服务介绍过，唤醒分片服务，驱动重新分片

Ø 主要业务

DataSync组件分析可知，主要业务集中在消息消费方法

TARGET_STATE_PREFIX/CONNECTOR_PREFIX/TASK_PREFIX/DELETE_CONNECTOR_PREFIX

系统通过消息key前缀识别分流处理，具体业务不详细分析

local实现，起始时发送START_SIGNAL，收集其他worker的配置数据

5.4.2.5 位点服务(position)

位点服务记录source/sink处理位置，用于分页和容错

 “套路”与配置服务一样，原理不重复分析

PositionUpdateListener 位点变更监听目前没有使用

Ø 主要业务分析

ONLINE 是新节点起来，请求同步集群的其他节点数据，获得全量数据

5.4.2.6 状态服务(state)

状态服务跟踪connector/task的状态

“套路”与上面两个服务一样，原理不重复分析

Ø 状态模型

 WrapperStatusListener 该接口是聚合连接器和任务监听实现，连接器和任务通过该接口报告给状态服务

ConnAndTaskStatus 状态服务实现都拥有KeyValueStore，但并没有使用，而是使用ConnAndTaskStatus保存连接器和任务的状态

Ø 主业务分析

5.4.3 worker(已完成50%)

TBD，第二部分分析

5.4.4 资源管理

目前connect没有资源管理，计算资源即worker节点，worker节点相同消费组是同一个集群，作为计算资源分派任务

规划引入资源管理器，对接k8s，动态申请资源

5.4.5 功能组件

5.4.5.1 rest组件

worker内置rest服务，RestHandle，输出worker连接器/任务新建，配置和变更等服务，实现依赖控制器

5.4.5.2 服务唤醒和等待组件(ServiceThread)

服务继承ServiceThread获得定时和唤醒执行服务逻辑的特性

5.4.5.3 同步组件

datasync底层以消息引擎实现，用于数据同步和命令分发，例如，任务配置变更，通知集群的其他worker，其他worker保存到本地，每份数据都得到复制，用于任务故障转移时恢复

5.4.5.4 store组件

上一章提到，位点，状态，配置的存储，store组件负责该功能

组件利用泛型和序列化器，支持不同的数据的存储，实现只有基于内存和文件，均为本地存储

5.4.5.5 统计(stat)组件

TBD

6 EventBridge

运行架构

 总体来说，EventBridge可以看作是runtime(connect)的管理台，构建基于domain的逻辑事件通道，远程调用runtime api创建物理(可运行)事件通道

组件架构

 core 逻辑事件通道的模型

rpc 对应worker的RestHandle，构建/启停connector等操作

 web 逻辑事件通道模型的构建，基于spring boot的web应用

其中，web，rpc，持久属于adapter子系统，不同的runtim有对应的实现，domain是抽象的事件通道模型

附录

open message

open message是阿里发起一个消息标准，旨在提高系统连通性，消息的自解释能能力，了解open message对了解rocketmq connect和rocketmq eventbridge有很大的帮助

TBD