需求背景

系統有資料識別、資料脫敏邏輯，支援可配置規則，自定義等，需要進行異構資料同步，大資料量。現在針對以下幾個需求進行講解

1、支援冗餘設計 2、支援任務自動分發，支援自動負載均衡 3、支援隨時擴容節點而無需關停原有的系統和業務

架構和模組

架構圖

五核心模組及其主要功能

• 排程平臺

  • 使用Nginx方式來呼叫資料中心，通過註冊中心獲取資料中心的服務列表
  • 可以合理的根據資料同步的情況，去呼叫服務；比如資料同步可能存在的順序性，執行延時；
  • 讀取控制檯DB的配置資訊，定時執行資料同步任務
  • 對資料同步的呼叫，可以按照簡單的輪詢方式，也可以根據資料同步伺服器的效能情況，進行負載均衡

• 資料同步

  • 負責執行資料庫異構資料同步任務，可支援增量，全量模式，用DataX框架來實現
  • 服務於排程平臺的呼叫
  • 會儲存資料同步的執行結果，供控制檯進行展示
  • 會上報伺服器的效能指標到資料同步DB，以供排程平臺參考

• 控制檯

  • 配置管理介面，服務於使用者進行資料同步任務的配置資訊，並儲存到控制檯DB中；

• 資料識別

  • 負責針對資料庫的資料進行資料識別任務

• 資料脫敏

  • 按照內建規則、自定義配置，負責脫敏資料
  • 可提前進行資料脫敏，以供資料同步轉換環節呼叫

三個輔助服務發現模組

• 註冊中心
  • 用於服務發現和註冊
  • 資料同步註冊例項並定期報心跳
  • 可以用zookeerper來實現
  • 排程平臺通過域名訪問註冊中心獲取資料同步的地址列表
• Nginx
  • 和域名系統配合，協助排程平臺訪問註冊中心獲取資料同步地址列表
  • 和域名系統配合，協助使用者訪問控制檯進行配置管理

可用性分析

高可用通過Nginx、註冊中心來實現，可以支援動態擴容。每個主要模組都是以無狀態叢集方式部署的，各自模組都可以通過註冊中心來實現服務註冊，模組之間的呼叫服務發現來獲取，並以域名方式實現。

考慮到擴充套件，所以設想的方案是儘可能的做到每個服務職責單一。

這樣的拆分，也是考量到每個環節的瓶頸都不一樣，目前預估不是很精確，這樣可以為後續擴充套件提供方便性。

資料脫敏、資料識別需要單獨獨立出來，原因：本身的服務不在資料同步中，可能提前預處理進行。

通過叢集部署方式，支援冗餘設計。

排程平臺、Nginx叢集通過資料同步效能情況,實現任務自動分發，支援自動負載均衡。

可用性分析

可用性表格分析

場景	影響	降級	原因
某臺資料同步下線	無影響	-	資料同步無狀態，排程平臺重連其他的資料同步服務。
所有資料同步下線	排程平臺無法執行資料同步任務	控制檯正常執行；排程平臺把資料同步任務放入執行佇列，等待執行	-
某個Nginx下線	無影響	-	多Nginx部署，資料完全同步，註冊中心、控制檯域名通過SLB自動切換到其他存活的Nginx
控制檯DB當機	排程中心無影響，控制檯無法更新配置	排程平臺開啟配置快取後，對配置的讀取不受資料庫當機影響
某臺資料識別、資料脫敏下線	無影響	-	資料識別、資料脫敏無狀態，資料同步重連其他的資料識別、資料脫敏同步服務
全部資料識別、資料脫敏下線	無影響	-	資料同步可執行線上脫敏功能，會影響任務時長。

結論

資料同步、控制檯、排程平臺、資料識別、資料脫敏是資料脫敏的幾大核心微服務模組，相互協作完成配置中心業務功能，Nginx、註冊中心是輔助微服務之間進行服務發現的模組。

採用微服務架構設計，架構和部署（部署方式可以用容器思路來操作）都有一些複雜，但是每個服務職責單一，易於擴充套件。