前段時間，我的一個小伙伴跳槽到了某大型國有企業，剛到公司不久，老板給交給他一個重要項目——公司的數據中臺規劃。
老板交代：“要搞一個數據中臺架構，涵蓋數據資產管理、數據治理、數據分析等，同時這個數據中臺，要體現去中心化，甚至無中心化的理念”。
我這哥們兒有過多年的數倉架構經驗，并參考了業界主流的數據中臺架構，很快就“照貓畫虎”的搞了一個數據中臺架構圖出來。
當他拿走自己的“得意之作”，找老板匯報的時候，沒想到老板只看了一眼，就劈頭蓋臉罵了他一頓，主要原因就是沒有體現“去中心化”的思想。
小伙伴兒向我抱怨：“數據中臺可不就得建一個集中管理數據資產的平臺，實現數據資源的匯集、治理、編目、標簽化，然后再根據業務部門的用數需求形成數據服務，提供給其他系統調用嗎？數據不集中管理，怎么給數據資產打標簽，怎么沉淀數據服務？這跟去中心化本來就是矛盾的，MD，SB領導毛都不懂，##XXOO@#$%^&”。
小伙伴兒噼里啪啦，越說越委屈、越說越氣憤……
我趕緊打斷了他：“你先別急，你把需求再跟領導溝通溝通，比如公司上這個數據中臺也解決什么問題？為什么要去中心化？另外就是，去中心化和中臺也并不矛盾，業務中臺的最佳實踐就是去中心化的微服務架構，難不成你們老板讓你搞的是業務中臺？”。
……
后來，這個事情也就這樣過去了。但這件事引發了我的一些思考：
中臺架構就要去中心化嗎？中臺和微服務到底什么關系？微服務的情況下，數據治理該如何搞？一
先說服務
百度百科中，關于微服務的定義：
微服務可以在“自己的程序”中運行，并通過“輕量級設備與HTTP型API進行溝通”。關鍵在于該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分布一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構
這個定義也不知道是哪位兄臺更新的，這專業的語言、晦澀的詞語，讓我這有IT技術基礎的看著都一臉懵逼。
本質上，微服務是就一種用于構建應用的技術架構，他是IT技術發展的產物。微服務架構有別于更為傳統的單體架構、垂直架構，它的特點是每個核心的功能，都可以作為一項服務，每個服務都有自己的運行環境、數據庫，可以單獨部署和運行，這意味著各項服務在工作（和出現故障）時不會相互影響，從而將單點故障產生的影響降到最低。
與單體架構、SOA架構相比，微服務具有最為明顯的特征是“去中心化”，這種對去中心化的關注不僅指導業務邏輯的組織，它還會涉及數據的存儲。
再說中臺
中臺是一個很泛的概念，包含了數據中臺、業務中臺、技術中臺、算法中臺，還有一些垂直應用中臺，比如：財務中臺、營銷中臺、制造中臺等，甚至還有組織中臺、資源中臺的說法。不論是哪種中臺，它的核心思想都是企業能力和資源的共享和復用，實現這些能力和資源的集約化管理，并能夠對不斷變化的業務需求進行靈活，快速響應。
簡單來講，directadmin授權，中臺是一種企業能力共享、資源復用的方法論。而微服務是一種可獨立部署、獨立運行、獨立維護的業務應用單元，它是一種技術架構模式。從這個層面講，中臺與微服務之間沒有半毛錢關系。
但，中臺與微服務真的沒有關系嗎？
首先 ，可以肯定的是中臺和微服務都是IT治理演進產物，從單體式的系統架構，到模塊化的垂直架構，到中心化的SOA架構，再到現在分布式的微服務架構、中臺架構。
其次 ，中臺、微服務都講求：抽象、重用和自治。抽象：將一個分布在不同系統的不同模塊，按照業務模塊進行抽象和拆分，形成獨立的服務，例如：用戶管理、商品管理、訂單管理。重用：即復用被抽象重構的服務，避免重復“造輪子”。自治：服務是獨立開發、獨立維護，相互之間沒有強依賴關系，更加體現軟件設計中的高內聚、松耦合理念，可以針對每個服務進行服務降級、限流、熔斷等處理，云服務器，而不影響其他服務的使用。
