微信搜索【阿丸筆記】，關注Java/MySQL/中間件各系列原創實戰筆記，干貨滿滿。
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部署，滿足快速擴縮容，提高資源使用率。
如果有任何疑問或者建議，歡迎評論或者私信我哦～
都看到最后了，原創不易，點個關注，點個贊吧～
文章持續更新，可以微信搜索「阿丸筆記 」第一時間閱讀，回復【筆記】獲取Canal、MySQL、HBase、JAVA實戰筆記，回復【資料】獲取一線大廠面試資料。
知識碎片重新梳理，構建Java知識圖譜： github.com/saigu/JavaK…（歷史文章查閱非常方便）