老板交代：“要搞一個數據中臺架構，涵蓋數據資產管理、數據治理、數據分析等，同時這個數據中臺，要體現去中心化，甚至無中心化的理念”。

我這哥們兒有過多年的數倉架構經驗，并參考了業界主流的數據中臺架構，很快就“照貓畫虎”的搞了一個數據中臺架構圖出來。

當他拿走自己的“得意之作”，找老板匯報的時候，沒想到老板只看了一眼，就劈頭蓋臉罵了他一頓，主要原因就是沒有體現“去中心化”的思想。

小伙伴兒向我抱怨：“數據中臺可不就得建一個集中管理數據資產的平臺，實現數據資源的匯集、治理、編目、標簽化，然后再根據業務部門的用數需求形成數據服務，提供給其他系統調用嗎？數據不集中管理，怎么給數據資產打標簽，怎么沉淀數據服務？這跟去中心化本來就是矛盾的，MD，SB領導毛都不懂，##XXOO@#$%^&”。

小伙伴兒噼里啪啦，越說越委屈、越說越氣憤……

我趕緊打斷了他：“你先別急，你把需求再跟領導溝通溝通，比如公司上這個數據中臺也解決什么問題？為什么要去中心化？另外就是，去中心化和中臺也并不矛盾，業務中臺的最佳實踐就是去中心化的微服務架構，難不成你們老板讓你搞的是業務中臺？”。

……

后來，這個事情也就這樣過去了。但這件事引發了我的一些思考：

中臺架構就要去中心化嗎？中臺和微服務到底什么關系？微服務的情況下，數據治理該如何搞？一

什么是微服務，微服務與中臺的關系？

先說服務

百度百科中，關于微服務的定義：

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

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

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

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

再說中臺

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

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

但，中臺與微服務真的沒有關系嗎？

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

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

另外 ，中臺可以不是微服務架構，單體應用也可以作為中臺的能力，輸出給前臺業務應用。但是如果選擇一種架構重構業務中臺的各種服務，例如：用戶中心、商品中心、訂單中心等，具備獨立部署和運行能力（分布式）、服務自治能力（授權、認證、降級、限流、熔斷）、敏捷試錯能力（devops）的微服務架構無疑是更適合的選擇。

二

微服務下，數據治理環境變得復雜？

基于微服務技術體系構建業務中臺，已經成了當前很多公司IT治理的首選解決方案。基于微服務架構的業務中臺，自然有他的優勢，諸如我們上文中提到的獨立部署和運行、服務自治、敏捷試錯等等，但是微服務架構下，拆分的不僅是應用，還有數據庫。

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

微服務架構中，將單體應用基于一定的業務抽象、拆分為多個服務，每個服務獨立部署和運行，同時，每個服務都有自己的獨立數據庫，需要考慮以下方面問題：

對于用戶、組織、區域等基礎數據在每個服務中可能都需要，數據庫設計怎么搞？每個微服務的數據庫獨立設計，跨多個服務的聯合數據查詢，怎么搞？如何進行進一步的數據分析和挖掘，數據如何集中管理，統一分析？處于不同微服務中的數據質量如何監控和保證，如何遵循統一的企業數據標準？分散的日志與配置文件如何管理？如何針對微服務中的特殊指標進行監控？數據的最終一致性如何保證？這些問題有些是架構設計就可以避免的，有的是需要進行微服務治理的，也有的問題歸屬數據治理的范疇。

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

這個屬于軟件架構設計范疇了，似乎我又跑題了，趕緊脈動回來！

那微服務環境下，數據治理到底治什么，在哪治，怎么治？

what ，治什么？即：哪些數據需要治理？

where ，在哪治？即：在單個的微服務中實施數據治理，還是集中到一個數據平臺（數據中臺）進行治理？

how ，怎么治？即：微服務下的數據治理和傳統架構下的數據治理有哪些不一樣？

我們帶著這三個問題，繼續往下看~~

三

微服務下的數據治理，治什么，在哪治，怎么治？

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

1、治什么

微服務下，數據治理的內容也無外乎也是元數據、主數據、指標數據、業務數據。當然，也有處理非結構化數據、半結構化數據、實時數據微服務。數據治理的內容/對象沒有變。

2、在哪治

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

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

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

3、怎么治

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

在線處理數據的方案就是按照微服務的標準接口來進行，后端服務或系統需要哪個數據就去調用某個微服務提供的接口來獲取，然后將返回的數據進行處理后將數據返回。

我們以用戶主數據治理為例，

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

其次 ，通過微服務提供用戶的注冊服務、查詢服務、登錄服務等等，供其他服務或系統調用，以達到數據統一的效果。

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

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

值得一提的是，微服務環境下更需要數據治理，尤其是元數據管理。元數據管理的作用不僅是對微服務中數據的治理，更是對微服務全生命周期的治理。如下圖：

參考：EAWorld

在微服務需求規劃階段，定義元數據標準。

在微服務設計階段，可以查詢其他微服務的元數據，以便微服務之間的數據調用。

在微服務的開發、測試、上線、運行階段使用相同元數據，保證各微服務開發到運營的各階段元數據的一致性，這是微服務實現“Devops”的基礎。

在微服務上線后，元數據可以幫助分析微服務的使用情況，并可以借助元數據的版本溯源分析功能，協助維護微服務的變更。

結束語

微服務架構最開始是在互聯網行業流行起來的，隨著互聯網向傳統行業的滲透（或者說傳統行業朝著互聯網方向轉型），微服務架構也逐漸出現在了企業應用開發的選項當中。盡管在核心理念上，微服務和SOA沒有太大差別，都是強調模塊化、服務化，但隨著敏捷開發、持續交付、DevOps理論的不斷發展和實踐，以及基于Docker等輕量級容器的應用和服務的逐步成熟，微服務已經成為了企業軟件架構的未來演進方向。

可以預見，在未來的很長一段時間內微服務架構與傳統軟件并存的。對于數據治理來講，傳統的數據管理方式可能會受到挑戰，但“治理”這兩個本身就帶著強烈的改革基因，改變一些傳統思維，固有習慣，擁抱新技術，面對新挑戰，與時俱進，才能達到“讓業務更有序、讓管理更有效！”的治理目標。