微信搜尋【阿丸筆記】，關注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…（歷史文章查閱非常方便）