微服務環境下，資料如何治理

微服務可以在“自己的程式”中執行，並透過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。透過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程式所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程式範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程式的架構

這個定義也不知道是哪位兄臺更新的，這專業的語言、晦澀的詞語，讓我這有IT技術基礎的看著都一臉懵逼。

本質上，微服務是就一種用於構建應用的技術架構，他是IT技術發展的產物。微服務架構有別於更為傳統的單體架構、垂直架構，它的特點是每個核心的功能，都可以作為一項服務，每個服務都有自己的執行環境、資料庫，可以單獨部署和執行，這意味著各項服務在工作（和出現故障）時不會相互影響，從而將單點故障產生的影響降到最低。

與單體架構、SOA架構相比，微服務具有最為明顯的特徵是“去中心化”，這種對去中心化的關注不僅指導業務邏輯的組織，它還會涉及資料的儲存。

再說中臺

中臺是一個很泛的概念，包含了資料中臺、業務中臺、技術中臺、演算法中臺，還有一些垂直應用中臺，比如：財務中臺、營銷中臺、製造中臺等，甚至還有組織中臺、資源中臺的說法。不論是哪種中臺，它的核心思想都是企業能力和資源的共享和複用，實現這些能力和資源的集約化管理，並能夠對不斷變化的業務需求進行靈活，快速響應。

簡單來講，中臺是一種企業能力共享、資源複用的方法論。而微服務是一種可獨立部署、獨立執行、獨立維護的業務應用單元，它是一種技術架構模式。從這個層面講，中臺與微服務之間沒有半毛錢關係。

首先 ，可以肯定的是中臺和微服務都是IT治理演進產物，從單體式的系統架構，到模組化的垂直架構，到中心化的SOA架構，再到現在分散式的微服務架構、中臺架構。

其次 ，中臺、微服務都講求：抽象、重用和自治。抽象：將一個分佈在不同系統的不同模組，按照業務模組進行抽象和拆分，形成獨立的服務，例如：使用者管理、商品管理。重用：即複用被抽象重構的服務，避免重複“造輪子”。自治：服務是獨立開發、獨立維護，相互之間沒有強依賴關係，更加體現軟體設計中的高內聚、松耦合理念，可以針對每個服務進行服務降級、限流、熔斷等處理，而不影響其他服務的使用。

另外 ，中臺可以不是微服務架構，單體應用也可以作為中颱的能力，輸出給前臺業務應用。但是如果選擇一種架構重構業務中臺的各種服務，例如：使用者中心、商品中心、訂單中心等，具備獨立部署和執行能力（分散式）、服務自治能力（授權、認證、降級、限流、熔斷）、敏捷試錯能力（devops）的微服務架構無疑是更適合的選擇。基於微服務技術體系構建業務中臺，已經成了當前很多公司IT治理的首選解決方案。基於微服務架構的業務中臺，自然有他的優勢，諸如我們上文中提到的獨立部署和執行、服務自治、敏捷試錯等等，但是微服務架構下，拆分的不僅是應用，還有資料庫。

微服務如何拆分，資料如何分割槽，如何保證拆分後資料的一致性，是考驗微服務架構師經驗和水平的試金石。一旦拆分邏輯設計不周密，其將來的資料環境將變的複雜！

這些問題有些是架構設計就可以避免的，有的是需要進行微服務治理的，也有的問題歸屬資料治理的範疇。

傳統架構下，資料庫各模組之間的設計遵循ACID原則（原子性、一致性、隔離性、永續性），來保證業務資料的正確性。但是單體應用經過拆分後，每個微服務對應獨立的資料庫，各個服務間透過介面進行資料互動，原來的本地資料庫事務的ACID原則在微服務架構中失效了。這就需要有一定的時候補償機制，來保證微服務資料的最終一致性。常用的方案，如：TCC，可以提供業務回滾邏輯介入，可以讓開發人員參與，編寫回滾方法達到向後恢復的目的。

有人認為微服務架構下，資料治理會遇到很大的挑戰，但是在我看來，就是資料來源多了些，不論從體系上、方法上、還是從技術上、工具上，微服務就是微服務，資料治理還是資料治理。

1、治什麼

微服務下，資料治理的內容也無外乎也是後設資料、主資料、指標資料、業務資料。當然，也有處理非結構化資料、半結構化資料、實時資料微服務。資料治理的內容/物件沒有變。

2、在哪治

微服務下，資料治理在哪治的問題，要分為兩個層面考慮。

一個層面，是關於主資料或基礎資料的治理，其重點還是應該放在資料來源頭治理。比如：“使用者中心”微服務管理了使用者主資料，“商品中心”微服務管理了商品主資料，那對於使用者和商品這兩個主資料就應該從“使用者中心”、“商品中心”這兩個微服務中入手，控制好資料的入口。

另一個層面，是關於分析資料、業務資料、日誌資料的治理。對於分析資料，以及一些實時性要求高的業務資料、日誌資料的質量，應放在資料中臺或資料湖中治理。

3、怎麼治

資料治理體系和方法上與傳統架構下的資料治理沒有任何區別，我們主要從技術層面來看。從技術方面來講，微服務下的資料治理，一般有兩種選擇：第一種是線上處理資料，第二種是離線處理資料。

線上處理資料的方案就是按照微服務的標準介面來進行，後端服務或系統需要哪個資料就去呼叫某個微服務提供的介面來獲取，然後將返回的資料進行處理後將資料返回。

我們以使用者主資料治理為例，

首先 ，在資料標準方面需要定義好資料管控的要素，如：三元素法（姓名、手機號、身份證號碼）。

其次 ，透過微服務提供使用者的註冊服務、查詢服務、登入服務等等，供其他服務或系統呼叫，以達到資料統一的效果。

最後 ，其他服務或系統呼叫這個微服務的介面，返回資料處理後再返回給該微服務。這種方式，與傳統主資料管理不一樣的是：微服務下的主資料管理不需要建立“主資料管理平臺”這樣的“中心化”系統，而是直接呼叫微服務自身介面提供資料服務。但“去中心化”的微服務也有一個弊端，如果微服務呼叫過於頻繁會給微服務本身造成很大的壓力，所以就需要對這些使用頻率高的微服務進行分散式和叢集處理。

離線處理資料方案，就是將業務資料準實時的同步到另外一個資料庫中，在同步的過程中進行資料整合處理，以滿足業務方對資料的需求。這個層面，微服務和傳統架構下的資料治理模式和技術沒有區別，離線資料處理對微服務正常業務處理沒有影響。這種方式重點是藉助資料湖的能力進行分層治理，一般包括：資料來源層（可以將每個微服務都當做一個資料來源處理）、資料整合層（採集和處理不同型別資料的中介軟體，比如：kettle、kafka、Spark、Storm、Flume、Sqoop等）、資料儲存層（MongoDB、Redis、ES、HBase、Spark、Hive、HDFS、MySQL等）、資料應用層（ES、SparkSQL、pig、Impala等）。技術選型有很多，以切合公司業務為目標，不同的業務場景選擇合適的資料處理元件。