數據脫敏大數據架構設計

需求背景

系統有數據識別、數據脫敏邏輯，支持可配置規則，自定義等，須要進行異構數據同步，大數據量。如今針對如下幾個需求進行講解

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

架構和模塊

架構圖

五核心模塊及其主要功能

• 調度平臺

  • 使用Nginx方式來調用數據中心，經過註冊中心獲取數據中心的服務列表
  • 能夠合理的根據數據同步的狀況，去調用服務；好比數據同步可能存在的順序性，執行延時；
  • 讀取控制檯DB的配置信息，定時執行數據同步任務
  • 對數據同步的調用，能夠按照簡單的輪詢方式，也能夠根據數據同步服務器的性能狀況，進行負載均衡

• 數據同步

  • 負責執行數據庫異構數據同步任務，可支持增量，全量模式，用DataX框架來實現
  • 服務於調度平臺的調用
  • 會存儲數據同步的執行結果，供控制檯進行展現
  • 會上報服務器的性能指標到數據同步DB，以供調度平臺參考

• 控制檯

  • 配置管理界面，服務於用戶進行數據同步任務的配置信息，並存儲到控制檯DB中；

• 數據識別

  • 負責針對數據庫的數據進行數據識別任務

• 數據脫敏

  • 按照內置規則、自定義配置，負責脫敏數據
  • 可提早進行數據脫敏，以供數據同步轉換環節調用

三個輔助服務發現模塊

• 註冊中心
  • 用於服務發現和註冊
  • 數據同步註冊實例並按期報心跳
  • 能夠用zookeerper來實現
  • 調度平臺經過域名訪問註冊中心獲取數據同步的地址列表
• Nginx
  • 和域名系統配合，協助調度平臺訪問註冊中心獲取數據同步地址列表
  • 和域名系統配合，協助用戶訪問控制檯進行配置管理

可用性分析

高可用經過Nginx、註冊中心來實現，能夠支持動態擴容。每一個主要模塊都是以無狀態集羣方式部署的，各自模塊均可以經過註冊中心來實現服務註冊，模塊之間的調用服務發現來獲取，並以域名方式實現。

考慮到擴展，因此設想的方案是儘量的作到每一個服務職責單一。

這樣的拆分，也是考量到每一個環節的瓶頸都不同，目前預估不是很精確，這樣能夠爲後續擴展提供方便性。

數據脫敏、數據識別須要單獨獨立出來，緣由：自己的服務不在數據同步中，可能提早預處理進行。

經過集羣部署方式，支持冗餘設計。

調度平臺、Nginx集羣經過數據同步性能狀況,實現任務自動分發，支持自動負載均衡。

可用性分析

可用性表格分析

場景	影響	降級	緣由
某臺數據同步下線	無影響	-	數據同步無狀態，調度平臺重連其餘的數據同步服務。
全部數據同步下線	調度平臺沒法執行數據同步任務	控制檯正常運行；調度平臺把數據同步任務放入執行隊列，等待執行	-
某個Nginx下線	無影響	-	多Nginx部署，數據徹底同步，註冊中心、控制檯域名經過SLB自動切換到其餘存活的Nginx
控制檯DB宕機	調度中心無影響，控制檯沒法更新配置	調度平臺開啓配置緩存後，對配置的讀取不受數據庫宕機影響
某臺數據識別、數據脫敏下線	無影響	-	數據識別、數據脫敏無狀態，數據同步重連其餘的數據識別、數據脫敏同步服務
所有數據識別、數據脫敏下線	無影響	-	數據同步可執行在線脫敏功能，會影響任務時長。

結論

數據同步、控制檯、調度平臺、數據識別、數據脫敏是數據脫敏的幾大核心微服務模塊，相互協做完成配置中心業務功能，Nginx、註冊中心是輔助微服務之間進行服務發現的模塊。

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