DataLink是一个满足各种异构数据源之间的实时增量同步，分布式、可扩展的数据交换平台。

项目背景

着眼于未来，我们的目标是打造一个平台，满足各种异构数据源之间的实时增量同步，支撑公司业务的快速发展。在充分调研的基础之上，我们发现，没有任何一款开源产品能轻易的满足我们的目标，每个产品都有其明显的短板和局限性，所以最终的选项只有”自行设计”。但自行设计并不是凭空设计，现有的数据交换平台、已有的经验、大大小小的开源产品都是我们的设计根基，与其说是自行设计，倒不如说是站在巨人的肩膀上做了一次飞跃。由此诞生了DataLink这样一个产品：

  • 满足各种异构数据源之间的实时增量同步
  • 平台提供统一的基础设施（高可用、动态负载、同步任务管理、插件管理、监控报警、公用业务组件等等），让设计人员专注于同步插件开发，一次投入，长久受益

  • 吸收、整合业内经验，在架构模型、设计方法论、功能特性、可运维、易用性上进行全面的升级，在前瞻性和扩展性上下足功夫，满足未来5-10年内的各种同步需求

    工作原理

    0-0.架构原理.png
    原理描述：

  • 典型管理系统架构，Manager(Web管理)+Worker(工作节点)
    a. Manager负责worker的负载均衡、集群的配置管理和系统监控
    b. Worker核心功能是管理Task的生命周期，并配合Manager进行Re-Balance

  • Zookeeper：Manager的高可用需要依赖于Zookeeper，另外，Task会将运行时信息注册到Zookeeper

  • Mysql：Datalink的运行需要依赖各种配置信息、以及在运行过程中会动态产生监控和统计数据，统一保存到Mysql中

    Manager

  • Manager是整个DataLink集群的大脑

  • Manager有三个核心功能
  1. 担任整个集群的负载均衡协调器：当集群出现状态变更时，第一时间进行Re-Balance
  2. 负责整个集群的配置管理：提供管理后台，配置发生变更时进行事件通知、缓存刷新等操作，保证系统能够获取到最新的变更
  3. 监控整个集群的健康状况，主要有：同步是否出现延迟、同步是否出现异常、数据同步TPS、数据同步吞吐量、机器健康状况检查等等

    Coordination

    整个Datalink集群的【负载均衡】都需要依赖于Manager提供的GroupCoordinator，这也是Manager最核心的功能。

    Monitor

    Manager端运行了数个Monitor，用来对集群进行立体化的监控，主要监控指标有：
  • 同步延迟监控报警
  • 同步异常监控报警
  • 任务运行状态监控报警
  • 机器运行状态监控报警
  • 机器内存监控报警
  • 机器系统监控

Admin

Manager提供了web模块，用于对整个集群进行管理，主要的管理模块有：

  • 集群管理：主要对分组和机器进行管理
  • 介质管理：主要对各种类型的数据源进行配置管理
  • 增量任务：主要对实时增量数据同步任务进行管理
  • 全量任务：主要对离线全量数据同步任务进行管理

  • 监控管理：主要进行监控指标配置和监控数据展现
    此外Manager内部还实现了一些定时任务，对集群进行一些自动化运维的工作

    Service

    Manager提供了若干HTTP接口用来为外提供服务，这些服务的调用者主要分两类：

  • Worker：Worker和Manager之间非Reblance类型的通信，走的都是http通道

  • 外部系统：外部系统如果需要访问datalink集群，都是通过调用Manager的服务接口实现的

Group

  • 分组是DataLink的一个核心概念，Worker和Task在运行之前必须先知道自己属于哪个分组

  • 分组的目的是：实现组内自治、组间隔离，不同分组会有不同的参数配置、运行策略、高可用级别等等

    Worker

  • Worker必须归属于某个分组

  • Worker的核心功能是管理Task的生命周期，并配合Manager进行Re-Balance
  • Worker运行哪些Task受Manager的分配

Coordination & ExecutingTask

Worker最核心的两大功能：参与集群的Coordination和对Task进行生命周期的管理，主要包括：

  • 和Manager的GroupCoordinator进行Reblance交互
  • 和Manager维持心跳（保持session）
  • 接收Manager指令，重启Task
  • 监控t_dl_task配置表，扫描到Task新增和删除时，发起Reblance
  • 监控t_dl_task配置表，扫描到Task-TargetState发生变化时，Pause或Resume Task

  • 监控t_dl_task配置表，扫描到Task配置参数发生变更时，自动重启Task

    Probe

    Worker内部运行了一系列的Probe，用于采集Task和Worker的各项运行指标，方便监控和统计，主要包括：

  • Task延迟时间

  • Task异常
  • Task的其它常规指标：每分钟同步的数据量，每分钟同步的流量，单条记录的写入速度，每分钟的读写交互次数等
  • Worker的各种运行指标：Jvm内存、GC次数、GC时间、网卡流量、CPU-load和使用率等

Rest

Worker内嵌了Jetty，用于提供Rest服务，这些服务的调用者，主要是Manager，如：重启Task服务、重启Worker、取元数据信息等。

BootMode

Worker支持两种启动方式：standalone和distributed，前者启动时只依赖于数据库，后者启动时需要同时依赖数据库、datalink-manager和zookeeper。

Task

DataLink真正执行数据同步任务的是每一个具体的Task，由Task从某一个固定类型的数据源读取数据，并同步到若干个目标端数据源，即为一对多的关系。我们将源端数据源类型规定为Task的类型，系统目前支持的Task类型有：MYSQL, FLEXIBLEQ, HBASE，支持同步到的目标端数据源类型有：Rdbms、ElasticSearch、Hdfs、HBase、FlexibleQ、SDDL。

(Re-)Balance

  • (Re-)Balance的定义：通过一定的负载均衡策略，使Task在Worker节点上均衡的分布
  • (Re-)Balance的单位是Group，一个分组发生(Re-)Balance不会影响其它分组的正常运行
  • 发生(Re-)Balance的时机
  1. Manager发生主备切换
  2. 新的Worker加入分组
  3. 某个Worker离开分组
  4. 新增Task
  5. 删除Task

    Plugin

  • 插件模型最大的意义在于解耦和复用，只需要提供一套基础框架，开发一系列同步插件，通过配置组合便可以支持”无限多”的同步场景
  • 插件划分为两种：Reader插件和Writer插件，插件之间通过Task串联起来
  • Task运行时，每个插件都有自己独立的Classloader，保证插件之间的jar包隔离

MySQL

  • DataLink的运行需要依赖各种配置信息，这些配置信息统一保存到Mysql中
  • DataLink在运行过程中会动态产生监控和统计数据，这些数据也统一保存到Mysql中

  • 存储的配置信息主要有： 同步任务信息、工作节点信息、分组信息、数据源配置信息、映射规则信息、监控信息、角色权限信息等

    Zookeeper

  • Manager的高可用需要依赖于zookeeper，通过抢占和监听”/datalink/managers/active”节点，实现秒级switch
    注：Worker的高可用并不依赖zookeeper，只要manager能够保证高可用，worker就是高可用的

  • Task会将运行时信息注册到zookeeper，注册信息主要有两类
  1. Task的状态信息（运行、暂停还是出错），通过状态信息可以监控task的健康状况
  2. Task的position信息，通过postion信息可以查看当前的同步进度，也可以实现故障恢复

Netty&Jetty

  • Manager使用Netty提供Tcp服务，用来监听Worker端发送的Coordinator信息（注：Netty只用来做高可用和负载均衡）
  • Manager使用Jetty提供Http服务，主要用来提供web管理功能和接收Worker发送的监控和统计数据

  • Worker使用Jetty提供Http服务，主要用来接收Manager发送的管理指令

    Kafka-Client

  • DataLink套用了kafka的(Re-)balance协议

  • 在Worker端和Manager端分别定义了各自的Coordinate模块，这些模块都需要依赖kafka的client包

层次架构图

0-3.功能(层次)架构图.png