簡介 CloudCanal 實現的 基於 Kafka 構建安全的跨互聯網數據同步 方案被客戶用於生產後，又出現了新的需求，主要集中在方案能否更加輕量化和可控性上，簡而言之，去掉 Kafka 中轉，直接在 CloudCanal 中實現跨網路安全互通。 本篇文章即介紹 CloudCanal 實現的更加輕 ...
簡介
CloudCanal 實現的 基於 Kafka 構建安全的跨互聯網數據同步 方案被客戶用於生產後，又出現了新的需求，主要集中在方案能否更加輕量化和可控性上，簡而言之，去掉 Kafka 中轉，直接在 CloudCanal 中實現跨網路安全互通。
本篇文章即介紹 CloudCanal 實現的更加輕量化方案，特點包括
- 無消息等獨立軟體依賴
- 兩端資料庫完全不開放公網埠
- 兩端資料庫元數據可映射
- 基於 HTTPS 傳輸
- 具備用戶名密碼鑒權機制
- 支持多種資料庫異構互通
技術點
Tunnel數據源
去掉消息依賴的跨互聯網資料庫互通，我們是通過一個虛擬的數據源 Tunnel 實現。
Tunnel 數據源本身並不是實體資料庫，而是一組邏輯信息，包括
- ip(或功能變數名稱)
- port
- 用戶名
- 密碼
- TLS 證書文件和密碼
- 元數據
通過這個虛擬數據源，我們可以使用 HTTP(S) 或 TCP 實現數據拉取或者接收數據的目的，同時完全匹配 CloudCanal 業務模型，達到功能的完整性。
PUSH模型
對於數據傳輸模式 PUSH 或 PULL，我們選擇了 PUSH 模式，即客戶端將數據推送到服務端，本質原因在於
- 主要解決互通問題，而非訂閱問題
- 目標端同步寫入數據更加匹配 CloudCanal 其他目標端風格
- 數據通道無數據持久化，無需維護 store 來暫存數據
當然，PUSH 模式也帶來一些問題，包括
- 如何確保最終數據寫入再提交位點
- 位點回溯複雜(全量和增量、不同數據源位點格式不一致)
對於上述兩個問題，我們採用 延遲提交位點技術 解決
延遲提交位點技術
採用 PUSH 模式後，位點管理是比較複雜且危險的工作，如果提早提交位點，可能丟數據。
為此，我們實現了 延遲提交位點技術，即客戶端每一次寫入 server 端，只返回已經提交的位點，並且將所有數據源、所有任務類型的位點序列化成 json 字元串。
通過這項技術，我們能夠確保位點之前的數據肯定已經寫到對端，並且在某些業務場景下，通過客戶端任務的位點回溯，達到重覆消費某一段時間數據的目的。
元數據映射
因為使用了虛擬的 Tunnel 數據源，並且其帶有 schema（存儲於CloudCanal kv配置表中), 所以針對這個數據源，我們模擬了表結構獲取和遷移的過程，讓其在任務創建和運維過程中如同一個真實存在的資料庫。
一個真實的 Tunnel 數據源的元數據如下:
[
{
"db": "cc_virtual_db",
"schemas": [
{
"schema": "cc_virtual_schema",
"tables": [
{
"table": "WORKER_STATS",
"columns": [
{
"name": "ID",
"jdbcType": -5,
"typeName": "LONG",
"key": true
},
{
"name": "GMT_CREATE",
"jdbcType": 93,
"typeName": "TIMESTAMP",
"key": false
},
{
"name": "AUCRDT",
"jdbcType": 93,
"typeName": "TIMESTAMP",
"key": false
}
]
},
{
"table": "KBS_QUESTION",
"columns": [
{
"name": "ID",
"jdbcType": -5,
"typeName": "LONG",
"key": true
},
{
"name": "CATEGORY",
"jdbcType": 12,
"typeName": "STRING",
"key": false
}
]
}
]
}
]
}
]
我們可以通過結構遷移 (MySQL/SQLServer/Oracle -> Tunnel) 擴充它，或者直接通過 數據源管理->更多->查看配置->_**dbsJson **_進行修改。
操作示例
本示例使用阿裡雲資源模擬杭州 RDS for MySQL 到深圳 RDS for MySQL , 兩端資料庫均不開公網埠，數據走互聯網, 採用 HTTPS 傳輸和用戶名密碼認證。
環境準備
- 杭州環境部署 CloudCanal ，併購買 RDS for MySQL 作為源端
- 深圳環境部署 CloudCanal , 併購買 RDS for MySQL 作為目標端
- 因 CloudCanal 為 docker 版本 ， 深圳環境 CloudCanal 安裝包解壓後 ，需要修改 docker-compose.yml 埠映射再安裝/升級，並開放 ECS 安全組相關埠，以便遠程連接。
- 此例以 18443 埠作為 Tunnel 數據源監聽埠
為目標端資料庫初始化元數據
- 因無法通過 Tunnel 到對端資料庫做結構遷移，所以需要事先使用 mysqldump 等工具初始化對端資料庫結構
添加 Tunnel 數據源
- 分別在源端和目標端 CloudCanal 配置 Tunnel 數據源
- 源端數據源列表
- 目標端數據源列表
為 Tunnel 初始化元數據
- 源端創建一個 MySQL -> Tunnel 結構遷移，並完成
- 目標端
- 從源端 Tunnel 數據源拷貝結構並複製到對端
目標端任務創建
- 選擇 Tunnel 和 目標資料庫
- 選擇數據同步
- 選擇表、列、映射略
- 任務正常運行，監聽埠並準備接收數據
源端任務創建
- 選擇源端資料庫 和 Tunnel 數據源
- 選擇數據同步，並初始化數據
- 數據初始化中（如有效率問題，可忽略）
- 數據持續同步中
數據驗證
造增量數據
- 為了造數據簡便，開下源端資料庫公網地址
數據校驗
- 在深圳環境添加源端數據源，並做數據校驗。結果顯示數據一致。
常見問題
-
目前支持哪些鏈路的互通？
- MySQL/SQLServer/ORACLE -> MySQL , 其他互通按需添加。
-
Tunnel 到對端資料庫能做結構遷移麽？準備表結構比較麻煩
- 因為資料庫結構對元數據精度要求很高，Tunnel中間結構主要為同步服務，所以元數據級別上還無法構成精確的結構遷移源端。建議構建臨時實例(只dump表結構)並開公網，再使用CloudCanal結構遷移解決問題。
-
Tunnel 數據源有結構，能動態編輯麽？
- Tunnel 數據源模擬了一個資料庫，編輯任務能力天然具備。加表先編輯目標端任務，再編輯源端任務，否則反之。我們後續計劃用一篇專門的文章介紹這個運維操作。
-
目前數據互通還存在什麼問題？
- 對於 blob 等欄位類型還需要進一步支持和驗證
- 跨互聯網，性能層面需要經過特別的優化
- 安全層面，目前僅用到 HTTPS 證書加密，配合自定義的賬號密碼
總結
本文主要介紹純粹通過 CloudCanal 進行數據互通實踐，通過引入虛擬數據源，達成數據互通和元數據映射等能力，具備不錯的可落地性。
