2020年下半年的主要任務(wù)，就是從0到1搭建了數(shù)據(jù)傳輸服務(wù)平臺產(chǎn)品。平穩(wěn)上線后，基本達(dá)到預(yù)期，實現(xiàn)了最初的產(chǎn)品規(guī)劃目標(biāo)。

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

• 產(chǎn)品設(shè)計
• 整體技術(shù)架構(gòu)
• 核心模塊的技術(shù)選型、原理與改造適配
• 總結(jié)與展望

1.什么是數(shù)據(jù)傳輸服務(wù)

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

當(dāng)然，目前我們的核心存儲還是以MySQL為主，因此，自研的數(shù)據(jù)傳輸服務(wù)的首要數(shù)據(jù)源是MySQL。

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

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

2.產(chǎn)品設(shè)計

對于DTS的最強(qiáng)烈需求來源，是正在推進(jìn)的多云架構(gòu)，需要能夠構(gòu)建多云數(shù)據(jù)庫鏡像。同時，我們又深入調(diào)研了其他業(yè)務(wù)需求，得到了眾多用戶場景。

包括但不限于：

• 數(shù)據(jù)庫多云同步
• 分庫分表數(shù)據(jù)同步
• ES 索引構(gòu)建
• 壓測數(shù)據(jù)、線下導(dǎo)入/同步
• 緩存刷新，Local cache/Redis cache等刷新
• 業(yè)務(wù)數(shù)據(jù)變更訂閱
• CQRS模式實現(xiàn)

這些場景經(jīng)過歸納整理，得到了DTS的三大產(chǎn)品功能模塊。

• 數(shù)據(jù)訂閱模塊：支持ES索引構(gòu)建 、緩存刷新、業(yè)務(wù)數(shù)據(jù)變更訂閱、CQRS模式實現(xiàn)
• 數(shù)據(jù)遷移模塊：支持?jǐn)?shù)據(jù)庫多云同步、分庫分表數(shù)據(jù)同步、壓測數(shù)據(jù)、線下導(dǎo)入
• 數(shù)據(jù)同步模塊：支持?jǐn)?shù)據(jù)庫多云同步、分庫分表數(shù)據(jù)同步、壓測數(shù)據(jù)、線下導(dǎo)入/同步

3.整體技術(shù)架構(gòu)

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

3.1 交互層

交互層就是用戶可見的前臺DTS產(chǎn)品，是用戶視角的DTS系統(tǒng)。

1)產(chǎn)品模塊

系統(tǒng)中包含了數(shù)據(jù)訂閱產(chǎn)品模塊、數(shù)據(jù)遷移產(chǎn)品模塊、數(shù)據(jù)同步產(chǎn)品模塊。

用戶通過與各個產(chǎn)品模塊交互，直接獲取對應(yīng)產(chǎn)品模塊任務(wù)信息，實現(xiàn)對模塊任務(wù)的管理，包括創(chuàng)建、啟動、停止、釋放、任務(wù)監(jiān)控信息等。

2)通用服務(wù)

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

這些通用服務(wù)能力可以來自于其他內(nèi)部系統(tǒng)，也可以是獨立設(shè)計的。

最重要的是，這些通用服務(wù)可以復(fù)用于DTS未來的產(chǎn)品擴(kuò)展，包括Redis的數(shù)據(jù)同步、HBase數(shù)據(jù)同步。

3)核心設(shè)計

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

因此交互層的核心實現(xiàn)采用 模板模式 ，實現(xiàn)了基礎(chǔ)任務(wù)的創(chuàng)建、啟動、停止、釋放、審核、鑒權(quán)等流程。

將基礎(chǔ)任務(wù)流程中的特定動作，如啟動引擎任務(wù)、停止引擎任務(wù)等具體實現(xiàn)放在各個模塊的實現(xiàn)類中進(jìn)行實現(xiàn)。

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

3.2 控制層

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

這一層主要面向運維視角，實現(xiàn)對引擎層的監(jiān)控、啟停、擴(kuò)容等能力。

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

Canal、otter等開源產(chǎn)品都已經(jīng)自帶了相關(guān)控制臺，可以直接使用。

3.3 引擎層

引擎層是整個系統(tǒng)的核心部分，目前的架構(gòu)設(shè)計下，引擎層的引擎都是支持?jǐn)U展、支持替換的。

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

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

對于引擎層，最核心的在于技術(shù)選型。需要結(jié)合業(yè)務(wù)需求、開源項目穩(wěn)定性、開源項目功能特點綜合分析，下文我們會仔細(xì)展開說明。

另外，對于生產(chǎn)環(huán)境使用的項目，必須做好配套的監(jiān)控告警措施，保證線上的穩(wěn)定性。

otter/canal都有現(xiàn)成的監(jiān)控指標(biāo)，我們需要將 同步延遲 等關(guān)鍵指標(biāo)進(jìn)行采集，并設(shè)置合理的告警閾值。

同時，對于一些沒有現(xiàn)成的監(jiān)控指標(biāo)，比如 任務(wù)存活狀態(tài) 等，我們可以通過 巡檢 進(jìn)行定時檢查，避免由于同步任務(wù)掛起而影響上層業(yè)務(wù)。

4.數(shù)據(jù)訂閱模塊

4.1 技術(shù)選型

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

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

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

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

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

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

4.2 基本原理

數(shù)據(jù)訂閱的原理基本一樣，都是基于MySQL的主從復(fù)制原理實現(xiàn)。

MySQL的主從復(fù)制分成三步：

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

Canal 就是模擬了這個過程。

Canal模擬 MySQL slave 的交互協(xié)議，偽裝自己為 MySQL slave ，向 MySQL master 發(fā)送 dump 協(xié)議;

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

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

4.3 部署架構(gòu)

核心組件：

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

4.4 使用方式

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

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

將數(shù)據(jù)庫訂閱binlog投遞到Rocketmq，下游用戶可以利用Rocketmq的Consumer Group，多次、重復(fù)消費對應(yīng)數(shù)據(jù)，實現(xiàn)業(yè)務(wù)解耦、緩存一致性等場景。

4.5 改造適配

1)控制臺api封裝

由于canal-admin的技術(shù)棧還是比較新的，有比較成熟的分層結(jié)構(gòu)和獨立的rpc接口，因此，在DTS服務(wù)中，包裝相關(guān)canal-admin的接口，即可實現(xiàn)產(chǎn)品化的前臺接口邏輯。

2)云原生改造

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

5.數(shù)據(jù)遷移模塊

5.1 技術(shù)選型

跟數(shù)據(jù)訂閱不同，Mysql的數(shù)據(jù)遷移五花八門，實現(xiàn)原理也都各不相同。

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

5.2 基本原理

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

我們主要使用了MySQL的數(shù)據(jù)同步，它的實現(xiàn)原理比較簡單，就是通過

select * from table; 

獲取全量數(shù)據(jù)，然后寫入到目標(biāo)庫中。

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

5.3 部署架構(gòu)與使用方式

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

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

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

后面會考慮進(jìn)一步迭代，采用獨立服務(wù)器部署Datax，然后通過自定義Java服務(wù)或者使用Saltstack實現(xiàn)遠(yuǎn)程調(diào)用腳本。

6.數(shù)據(jù)同步模塊

6.1 技術(shù)選型

數(shù)據(jù)同步的方案主要有三種

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

6.2 基本原理

基于Canal開源產(chǎn)品，獲取數(shù)據(jù)庫增量日志數(shù)據(jù)。Canal原理參考 數(shù)據(jù)訂閱 的基本原理。

典型管理系統(tǒng)架構(gòu)，manager(web管理)+node(工作節(jié)點)。

6.3 部署架構(gòu)

核心組件：

• zookeeper：解決分布式狀態(tài)調(diào)度的，允許多node節(jié)點之間協(xié)同工作
• manager: 運行時推送同步配置到node節(jié)點
• node: 內(nèi)嵌canal，負(fù)責(zé)binlog訂閱，并把事件同步到目標(biāo)數(shù)據(jù)庫;同時，將同步狀態(tài)反饋到manager上

6.4 改造適配

1)控制臺api封裝

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

因此，需要根據(jù)已有代碼，重新封裝獨立的rpc接口，然后才能對接到DTS服務(wù)中，包裝相關(guān)otter-admin的接口，實現(xiàn)產(chǎn)品化的前臺接口邏輯。

2)云原生改造

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

7.總結(jié)與展望

從產(chǎn)品設(shè)計、技術(shù)調(diào)研、架構(gòu)設(shè)計到最后研發(fā)上線，歷時半年左右。最終功夫不負(fù)有心人，項目順利上線，通過前臺產(chǎn)品的簡單交互與審核，就能秒級快速創(chuàng)建DTS任務(wù)。

目前已經(jīng)支持?jǐn)?shù)十個DTS任務(wù)(包括數(shù)據(jù)訂閱、數(shù)據(jù)遷移、數(shù)據(jù)同步)，落地了多云數(shù)據(jù)庫鏡像、ES索引構(gòu)建、數(shù)據(jù)實時同步、業(yè)務(wù)數(shù)據(jù)訂閱等多個業(yè)務(wù)場景。

未來，還需要做進(jìn)一步的技術(shù)迭代，包括：

1)擴(kuò)展數(shù)據(jù)傳輸引擎

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

后面還會繼續(xù)嘗試HBase-replication的接入，做HBase相關(guān)的任務(wù)遷移與同步。

這些都可以通過復(fù)用 通用服務(wù)能力 和 模版流程，實現(xiàn)快速接入。

2)增加調(diào)度模塊

后續(xù)還需要增加任務(wù)調(diào)度模塊，主要實現(xiàn)兩方面的能力：

根據(jù)實例負(fù)載進(jìn)行任務(wù)的調(diào)度，保證資源的合理使用

根據(jù)業(yè)務(wù)特性、重要程度做任務(wù)調(diào)度，保證資源隔離

3)完成云原生化改造

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