2020年下半年的主要任務，就是從0到1搭建了數據傳輸服務平臺產品。平穩上線后，基本達到預期，實現了最初的產品規劃目標。

這里做個復盤，記錄下從0到1的過程，包括：

• 產品設計
• 整體技術架構
• 核心模塊的技術選型、原理與改造適配
• 總結與展望

1.什么是數據傳輸服務

數據傳輸服務DTS(Data Transmission System)的目標是支持RDBMS、NoSQL、OLAP等數據源間的數據交互，集數據遷移/訂閱/同步于一體，幫助構建安全、可擴展、高可用的數據架構。

當然，目前我們的核心存儲還是以MySQL為主，因此，自研的數據傳輸服務的首要數據源是MySQL。

為什么不直接采用公有云產品呢，比如阿里云DTS?

主要原因是為了能更好地對接內部其他系統，支持許多內部系統數據遷移/同步的自動化流程需求。同時，業內相關開源技術非常豐富且成熟，有很多現成的輪子可以使用，可以大大降低云服務使用成本。

2.產品設計

對于DTS的最強烈需求來源，是正在推進的多云架構，需要能夠構建多云數據庫鏡像。同時，我們又深入調研了其他業務需求，得到了眾多用戶場景。

包括但不限于：

• 數據庫多云同步
• 分庫分表數據同步
• ES 索引構建
• 壓測數據、線下導入/同步
• 緩存刷新，Local cache/Redis cache等刷新
• 業務數據變更訂閱
• CQRS模式實現

 

這些場景經過歸納整理，得到了DTS的三大產品功能模塊。

• 數據訂閱模塊：支持ES索引構建 、緩存刷新、業務數據變更訂閱、CQRS模式實現
• 數據遷移模塊：支持數據庫多云同步、分庫分表數據同步、壓測數據、線下導入
• 數據同步模塊：支持數據庫多云同步、分庫分表數據同步、壓測數據、線下導入/同步

3.整體技術架構

整個DTS系統分為三個 邏輯層次，交互層、控制層、引擎層。

 

3.1 交互層

交互層就是用戶可見的前臺DTS產品，是用戶視角的DTS系統。

1)產品模塊

系統中包含了數據訂閱產品模塊、數據遷移產品模塊、數據同步產品模塊。

用戶通過與各個產品模塊交互，直接獲取對應產品模塊任務信息，實現對模塊任務的管理，包括創建、啟動、停止、釋放、任務監控信息等。

2)通用服務

交互層除了產品模塊之外，用戶能夠感知到的交互能力還包括了用戶管理、權限管理、變更管理、基本任務信息管理等 通用服務能力。

這些通用服務能力可以來自于其他內部系統，也可以是獨立設計的。

最重要的是，這些通用服務可以復用于DTS未來的產品擴展，包括Redis的數據同步、HBase數據同步。

3)核心設計

正如一開始提到，雖然目前我們以MySQL為主，但是未來肯定會擴展到其他數據源的數據遷移與同步。

因此交互層的核心實現采用 模板模式 ，實現了基礎任務的創建、啟動、停止、釋放、審核、鑒權等流程。

將基礎任務流程中的特定動作，如啟動引擎任務、停止引擎任務等具體實現放在各個模塊的實現類中進行實現。

實現了DTS模塊化設計和極高的可擴展性，為未來接入其他 遷移/同步引擎(Redis/Hbase) 打下基礎。

3.2 控制層

控制層是面向管理員的操作平臺。

這一層主要面向運維視角，實現對引擎層的監控、啟停、擴容等能力。

對比交互層產品模塊，這一層次的控制臺會有更復雜的任務控制選項，同時，也會具備很多運維層面的操作，比如引擎層的服務器管理能力等。

Canal、otter等開源產品都已經自帶了相關控制臺，可以直接使用。

3.3 引擎層

引擎層是整個系統的核心部分，目前的架構設計下，引擎層的引擎都是支持擴展、支持替換的。

目前全部采用開源項目，包括：

• 數據遷移引擎采用Datax：https://github.com/alibaba/DataX
• 數據訂閱引擎采用canal: https://github.com/alibaba/canal
• 數據同步引擎采用otter: https://github.com/alibaba/otter

對于引擎層，最核心的在于技術選型。需要結合業務需求、開源項目穩定性、開源項目功能特點綜合分析，下文我們會仔細展開說明。

另外，對于生產環境使用的項目，必須做好配套的監控告警措施，保證線上的穩定性。

otter/canal都有現成的監控指標，我們需要將 同步延遲 等關鍵指標進行采集，并設置合理的告警閾值。

同時，對于一些沒有現成的監控指標，比如 任務存活狀態 等，我們可以通過 巡檢 進行定時檢查，避免由于同步任務掛起而影響上層業務。

4.數據訂閱模塊

4.1 技術選型

數據訂閱實際上就是一種CDC(Change Data Capture)工具，目前開源產品中比較成熟的有Canal、DataX、DataBus、Debezium等。

整體而言，Canal、DataX、Debezium的使用人數多，社區活躍，框架也比較成熟。在滿足應用場景的前提下，優先選擇，代價適中。

DataX支持豐富，使用簡單，但延遲較大(依賴獲取頻率)，只需要手寫規則文件，對復雜同步自定義性不強。

Debezium雖然比Canal支持更多類型的數據源，但是我們實際上只需要mysql，并不需要PostgreSQL這些的支持。

而Canal有幾點特性我們非常需要，讓我們決定使用Canal作為數據訂閱引擎：

• 對阿里云RDS有特殊定制優化，可以自動下載備份到oss的binlog文件然后指定位點開始同步
• 有非常友好的控制臺
• 支持投遞到Rocketmq
• 新版本的Canal-Adapter可以支持多種客戶端消費，包括mysql、es等

4.2 基本原理

數據訂閱的原理基本一樣，都是基于MySQL的主從復制原理實現。

MySQL的主從復制分成三步：

• master將改變記錄到二進制日志(binary log)中(這些記錄叫做二進制日志事件，binary log events，可以通過show binlog events進行查看);
• slave將master的binary log events拷貝到它的中繼日志(relay log);
• slave重做中繼日志中的事件，將改變反映它自己的數據。

Canal 就是模擬了這個過程。

Canal模擬 MySQL slave 的交互協議，偽裝自己為 MySQL slave ，向 MySQL master 發送 dump 協議;

MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal );

Canal 解析 binary log 對象(原始為 byte 流);

4.3 部署架構

核心組件：

• zookeeper：使用已有的zookeeper集群，實現訂閱任務的HA
• canal-admin：數據訂閱的控制層的控制臺，管理canal-server上的訂閱任務狀態與配置
• canal-server：用于運行數據訂閱任務，抓取數據庫binlog，投遞到MQ或者下游client。

4.4 使用方式

Canal支持TCP直接消費、MQ消費兩種模式。

為了支持多個下游消費，減少上游數據庫訂閱壓力，我們使用了MQ消費模式。

將數據庫訂閱binlog投遞到Rocketmq，下游用戶可以利用Rocketmq的Consumer Group，多次、重復消費對應數據，實現業務解耦、緩存一致性等場景。

4.5 改造適配

1)控制臺api封裝

由于canal-admin的技術棧還是比較新的，有比較成熟的分層結構和獨立的rpc接口，因此，在DTS服務中，包裝相關canal-admin的接口，即可實現產品化的前臺接口邏輯。

2)云原生改造

計劃中，改造為k8s部署，支持快速擴縮容

5.數據遷移模塊

5.1 技術選型

跟數據訂閱不同，Mysql的數據遷移五花八門，實現原理也都各不相同。

綜合來看，我們選擇了DataX作為數據遷移引擎。

5.2 基本原理

DataX 是阿里巴巴集團內被廣泛使用的離線數據同步工具/平臺，實現包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各種異構數據源之間高效的數據同步功能。

我們主要使用了MySQL的數據同步，它的實現原理比較簡單，就是通過

select * from table; 

獲取全量數據，然后寫入到目標庫中。

當然，這里利用了JDBC的流式查詢，避免OOM。同時，datax也支持自定義限速。

5.3 部署架構與使用方式

Datax的使用方式比較簡單，通過配置任務Json，執行腳本即可。

由于數據遷移使用不多，且基本是一次性使用，所以暫時是直接部署在DTS的服務中，通過Java的Process類進行相關處理。

• 創建Datax所需的conf文件，并返回地址
• 使用Runtime.getRuntime().exec()執行 Datax的python腳本
• 根據返回的Process對象，處理成功/失敗、執行輸出日志等

后面會考慮進一步迭代，采用獨立服務器部署Datax，然后通過自定義Java服務或者使用Saltstack實現遠程調用腳本。

 

6.數據同步模塊

6.1 技術選型

數據同步的方案主要有三種

綜合實施性、技術成熟度、雙向同步需求的考慮，我們選擇了otter作為數據同步引擎。

6.2 基本原理

基于Canal開源產品，獲取數據庫增量日志數據。Canal原理參考 數據訂閱 的基本原理。

典型管理系統架構，manager(web管理)+node(工作節點)。

6.3 部署架構

核心組件：

• zookeeper：解決分布式狀態調度的，允許多node節點之間協同工作
• manager: 運行時推送同步配置到node節點
• node: 內嵌canal，負責binlog訂閱，并把事件同步到目標數據庫;同時，將同步狀態反饋到manager上

6.4 改造適配

1)控制臺api封裝

由于otter-admin的技術棧比較舊，采用webx框架實現，沒有前后端分離。

因此，需要根據已有代碼，重新封裝獨立的rpc接口，然后才能對接到DTS服務中，包裝相關otter-admin的接口，實現產品化的前臺接口邏輯。

2)云原生改造

改造為k8s部署，支持快速擴縮容，具體可以參考我上一篇文章 擁抱云原生，如何將開源項目用k8s部署?

7.總結與展望

從產品設計、技術調研、架構設計到最后研發上線，歷時半年左右。最終功夫不負有心人，項目順利上線，通過前臺產品的簡單交互與審核，就能秒級快速創建DTS任務。

目前已經支持數十個DTS任務(包括數據訂閱、數據遷移、數據同步)，落地了多云數據庫鏡像、ES索引構建、數據實時同步、業務數據訂閱等多個業務場景。

未來，還需要做進一步的技術迭代，包括：

1)擴展數據傳輸引擎

目前已經在嘗試接入Redis-shake做Redis的遷移與同步。

后面還會繼續嘗試HBase-replication的接入，做HBase相關的任務遷移與同步。

這些都可以通過復用 通用服務能力 和 模版流程，實現快速接入。

2)增加調度模塊

后續還需要增加任務調度模塊，主要實現兩方面的能力：

根據實例負載進行任務的調度，保證資源的合理使用

根據業務特性、重要程度做任務調度，保證資源隔離

3)完成云原生化改造

目前只有otter引擎實現了k8s部署，后面還需要對canal-server、Datax實現k8s部署，滿足快速擴縮容，提高資源使用率。