如何建設中臺？中臺建設的組織、支撐技術和方法論

編者按：本文轉載自網易副總裁，網易杭州研究院執行院長汪源的我的公衆號「冷技術熱思考」（歡迎搜索關注）。上一篇中臺系列的文章重點闡述了中臺的概念，本文是系列文章的第二篇，目的是說明什麼狀況下能夠考慮建設中臺，若是要建怎麼建的問題，能夠做爲企業思考中臺建設的大框架。如下爲原文（有少許改動）：

本文將例舉典型的須要建設中臺的場景，供參考判斷要不要建中臺。建設中臺須要考慮組織、技術支撐和方法論，每每還須要諮詢服務的幫助，本文也能夠做爲思考中臺建設的大框架。

要不要建設中臺？

要建設中臺，首先要考慮要不要建設中臺。話說的這麼繞是由於如今有不少不明就理就想建中臺的。這個問題先作個初略的判斷。

01業務中臺的典型場景

對業務中臺來講，比較符合的場景主要有：
· 業務系統研發團隊至少大幾十人（含外包的），需求多變化快，系統又涉及多個領域（好比作ERP、電商的），業務邏輯比較複雜。這時業務中臺能夠把系統和業務領域劃分清楚，提升研發效率。
· 作類似行業的外包項目爲主，業務規模也作的比較大的（一年有兩位數的項目）。這時業務中臺能夠提高軟件複用，下降定製化成本，提升研發效率。若是你作外包，每一個項目都徹底不同，那中臺也救不了你。

此外還有如下場景可能不須要建設完整的中臺，但適合落地與中臺相關的微服務技術的：
· 大規模互聯網式在線系統，對穩定性和彈性要求高當前搞不定的。微服務或業務中臺能夠比較好的解決這些問題。
· 掉到IT豎井的坑裏想爬出來的，經過項目外包作的系統沒法管理和維護的。微服務或業務中臺能夠對系統的API、文檔等進行有效管理，也能實現系統間的打通。

02數據中臺的典型場景

對數據中臺來講，比較符合的場景主要是數據產品比較多，天天要看數據若是沒數據就不知道怎麼工做的運營人員比較多的業務。好比電商就是典型。若是這些數據產品和運營人員還在多個團隊，那基本上數據中臺沒跑了。若是常常出現指標不一致、數據出錯、想要的數據不知道哪裏有等問題，那基本上數據中臺也沒跑了。

並非數據量大就須要建中臺，主要仍是看用數據的姿式是否是比較複雜，當前問題是否是比較多。對於這類符合的業務，數據中臺能把層層數據直到最上層的指標梳理清楚，提高數據質量，從而提高運營效率。把數據理清楚了，每每還能下降數據存儲和數據開發人員的成本。

除了上述判斷，還有一條是同行對比。若是一個行業你們都有點躍躍欲試想弄中臺，那領先者必定要想辦法搶先（既然是領先者了，每每也符合上述標準），否則就可能被顛覆。跟隨者要不要想辦法搶先從而超越領先者呢？可能很差說吧，但若是領先者已經建了，跟隨者通常得緊跟，不然真可能被甩開了。

若是根據上述邏輯以爲大體要考慮去搞一把中臺的話，那請繼續讀本文如下內容，讀完本文後續內容而後更具體的看看問題存不存在，條件是否具有。要建設中臺，須要考慮組織、支撐技術、方法論這三個方面，每每還須要諮詢服務。

中臺組織

中臺做爲一種有業務屬性的共性能力，首先就須要一個懂業務、承擔業務職責的專職的組織機構來負責。要不要建中臺，首先要看領導有沒有魄力去整合創建一箇中臺組織。由於原來的平臺部一般不懂業務，懂業務的人各自分散在前臺業務部門，因此創建中臺組織每每涉及人員、組織架構和部門職責的調整。 正由於如此，中臺的建設每每須要做爲一把手工程才能成功。

中臺組織關鍵要懂業務和承擔業務職責。舉個例子，一個大數據平臺的建設運維團隊不是一箇中臺組織。一個團隊若是作了很是完善的中臺產品（如開發了數據中臺所須要的指標管理系統、數據倉庫開發系統、數據質量管理系統等等），但只是把產品提供給業務方使用，這個團隊仍然不能說是中臺組織。只有當這個團隊承擔起指標體系的建設和管理、數據倉庫的設計和實施、數據質量的保障等工做時，才能夠說是中臺組織。而要作到這一點，這個組織確定是比較瞭解業務的，它的目標和考覈也必定與業務有相關性（確定不僅是平臺穩定性這樣的非業務指標）。

中臺組織的層次與中臺的層次最好是對應的，BU級的中臺組織最好直接向BU老大或分管的CXO彙報，企業的中臺組織最好直接向CEO或分管的CXO彙報。

這裏特別說明一點的是若是不建設在線業務中臺，而只是採用微服務、雲原生等技術的話，能夠不涉及組織方面的大規模變更，就在原來的研發部實現轉型。一般來講也能夠實現必定的系統可用率、彈性和研發效率方面的提高。

中臺建設的支撐技術

建設中臺通常須要一套支撐技術。

01在線業務中臺支撐技術

建設在線業務中臺通常須要雲原生、DevOps、微服務技術體系的支撐，這是由於：
· 微服務技術：中臺是一個獨立的組織負責併爲多個前臺業務服務，所以須要一個標準的服務接口、成熟的服務治理能力和高效的敏捷研發技術。在當前的技術環境下，採用地球人都熟悉的REST風格的同步API、消息隊列異步通訊做爲標準的服務接口技術，採用服務框架（如Spring Cloud等）、API網關、APM等做爲標準的服務治理和敏捷研發技術是最合適的選擇。再也不建議採用傳統的基於ESB的服務化（SOA）技術，由於ESB產品過多的介入到業務邏輯中，致使前臺業務的變動每每須要中臺團隊的配合才能完成，這樣就失去了建設好中臺，支撐前臺高效創新的意義。此外，中心化的ESB軟件和複雜的基於XML的WS-xxx等協議也影響到系統的可用性和性能。能夠參見Martin Fowler在P of EAA中的評價，Web Services是應用集成而非應用開發的技術。
· DevOps技術：若是不經過DevOps使得各微服務都能自助式的部署更新，則微服務帶來的敏捷性就無從發揮，反而由於服務數量的增長致使研發效率的降低，所以持續集成、持續發佈等DevOps技術通常是實現微服務的必備。
· 雲原生技術：微服務和DevOps要求底層的基礎設施是靈活可編程的，不然根據Amdahl定律，只要有一個必須的環節是低效的，總體的效能也提不上去。
須要強調的是中臺要敏捷，這一方面是由於中臺具有業務屬性，且支撐了很是豐富的前臺業務，前臺業務的敏捷性要求有一部分就會傳導的中臺層；另外一方面是中臺的重要性使得其須要持續不斷的優化，即使對外提供的服務不變，內部實現也會常常變。
· 分佈式事務技術：實施微服務拆分後，複雜的業務流程再也不能經過數據庫的事務機制來實現ACID特性，爲此還須要服務層面的分佈式事務處理技術。典型的分佈式事務處理模型包括TCC、Saga、FMT等。其中TCC和Saga須要各服務實現定製化回滾邏輯，侵入性比較嚴重，用起來門檻比較高。FMT模式對於Java能夠作到加一行註解（如@GlobalTransaction）便可實現分佈式事務，剩下的由框架自動處理，用起來方便的多。Saga模式是Princeton的兩位研究者在1987年提出的，靈活性和併發度最好，但須要經過語義鎖等精細的設計才能發揮出來。

因而可知，在線業務中臺的技術支撐體系是至關複雜的，所幸的是Netflix、Google等世界領先的互聯網企業因爲自身業務須要打造了不少實用的技術模塊，開源社區也貢獻了很多力量，CNCF組織又作了很好的聚集和標準化。 經過將相關技術加以整合，已經有了不錯的產品可用，如網易輕舟微服務就是一套產品化設計良好、功能豐富的在線業務中臺支撐技術產品。

通常而言，前臺也會和在線業務中臺同樣採用雲原生等一樣的技術體系，這是由於前臺更須要敏捷性。在完善的中臺支撐之下，前臺會比較輕，還能夠考慮採用FaaS Serverless技術，不過目前這方面的實踐還很少（特別在中國），相關的支撐技術也不是很成熟。

02數據中臺支撐技術

建設數據中臺通常須要一整套以下典型的支撐技術：
· 指標管理系統：指標是中臺與前臺之間最關鍵的接口，也是建設數據中臺的牛鼻子，由於它是最核心的業務語言，且指標不一致、數據常出錯是建設數據中臺最多見的出發點。若是指標體系沒有統一的方法論，進行統一建設，那麼就很難說是數據中臺。指標管理系統通常要實現一套一致的方法論（如原子 / 派生 / 複合指標、維度、修飾詞等），作好指標的業務和技術口徑管理，還須要支持指標的審批管理。數據中臺的指標沒法交給各前臺業務自助式的建設。
· 數據服務系統：相似於在線業務中臺須要經過API網關提供標準化的服務，數據中臺也須要一個標準化的服務方式，一般稱爲數據服務系統，也能夠說是數據網關或數據門戶。相似於別的網關類產品，數據服務系統須要提供鑑權、日誌審計、流控、協議轉換（如SQL Dialect之間的轉換）等功能，也應該發展多引擎融合查詢、邏輯模型等擴展功能以提升服務接口的穩定性和實現的靈活性。
· 元數據管理系統：元數據管理是整個數據中臺的基礎和中心，全部的其餘系統都依賴元數據管理。元數據管理首先要作好的固然是數據模式或目錄（catalog）的管理，至少要知道中臺裏都有什麼數據。對複雜的數據中臺來講，數據血緣也很重要。沒有血緣信息，不知道數據間的依賴關係，數據質量確定管很差，由於不知道一個數據的質量問題怎麼來，又進而會影響什麼。一樣的若是沒有血緣，數據資產也確定管很差，由於不知道什麼數據有價值什麼沒價值，這就像若是你不知道一個函數被誰調用，你就不知道它是否是死代碼同樣。元數據管理系統每每也須要提供一個基礎的訪問界面，一般稱之爲數據地圖。
· 數據倉庫開發與管理系統：除了指標管理，數據倉庫的開發是將一大堆初始數據建設梳理成一個漂亮的數據中臺的核心過程。通常來說數據中臺更適合用Kimball的維度建模方法而非數據倉庫之父Bill Inmon所提倡的方法，這是由於Inmon強調頂層設計，而Kimball強調至下而上。若是要建設數據中臺，確定是由於前臺業務複雜多變，這時強調頂層設計會致使中臺建設緩慢、僵化。由於中臺雖然應該是由組織高層決策，但目的倒是爲了支持前臺業務，而不是爲了控制。 支持而不是控制，這一點毫不能本末倒置。
· 數據質量管理系統：全部複雜的系統都須要專業的質量管理，在線業務系統有一系列的彈力設計和APM等監控運維工具，數據中臺也須要專業的質量管理。數據質量管理系統一般設計爲支持豐富的稽覈 / 校驗 / 比對規則，監控數據是否準確、實時、一致，還要作到及時的報警，分析影響面，提供快速修復的手段等。但這些手段只能發現和補救問題，不能預防問題，要預防問題，還要經過測試工具減小代碼bug、經過資源彈性應對性能波動、經過優先級調度優先知足重要業務需求等。相對來講，當前數據中臺領域的質量管理沒有在線業務領域的成熟，如在線業務領域的測試手段遠比數據領域的精細，在線業務領域很常見的熔斷、限流、服務降級等模式在數據領域都沒有成熟的實踐方法（優先級調度能夠說是實現了部分的服務降級功能），隨着數據中臺愈來愈普遍和重要，這些技術應該也須要持續發展，但技術上的挑戰不小。
· 數據安全管理系統：數據中臺由於聚集了組織全部有價值的數據資產，所以良好的安全管理是必須的。細粒度的權限和審計是基礎，通常的還須要隱私 / 敏感數據的脫敏處理、數據加密（特別是將數據託管在第三方平臺之上時）、數據泄漏防禦（比方說一種常見的方法是限制將數據下載到本地的數據量）等技術。發展到高級階段甚至可能還須要聯邦學習、數據沙盒等技術。
· 數據資產管理系統：在數據質量和安全單列的狀況下，數據資產管理主要負責的是數據的生命週期管理、成本的統計分析與優化等工做。

同時，數據中臺還須要強大的大數據計算引擎、數據集成 / 同步 / 交換引擎，還每每須要一套敏捷BI系統：
· 大數據計算引擎：數據中臺要管理的數據規模和複雜度每每都很高（不然搞中臺屬於爲賦新詞強說愁），因此傳統的數據庫和數據倉庫基本上支撐不了。當前的技術環境下，基於Hadoop MapReduce或Spark幾乎是惟二的選擇，固然這也包括了這二者之上的Hive和Spark SQL。能用SQL就用SQL，易於維護，也易於數據血緣的收集。除此以外，流處理可能還須要Flink，交互式查詢可能要引入Impala或GreenPlum。
· 數據集成 / 同步 / 交換引擎：一方面數據中臺須要強大的數據集成和同步能力才能吸納各方數據。集成和同步的概念相近，同步更強調實時性。另外一方面，數據中臺每每由多種數據計算引擎構成，就須要同步或交換引擎實現不一樣引擎見的數據交換。
· 敏捷BI系統：建設數據中臺一般最重要的目的是爲了支持業務運營和決策，爲此須要基於數據中臺進一步開發數據產品。敏捷BI系統是開發數據產品快速、輕型的手段，可以儘快儘早的發揮數據中臺的價值。

此外，對於互聯網業務，統一的埋點引擎每每也是數據中臺所須要的。若是埋點的邏輯都不統一的話，建數據中臺的時候會發現數據的源頭就是亂的，後續也都無法作。其餘行業業務，數據採集也屬於基礎工做，也是要先作好的。

因而可知，建設數據中臺須要的技術支撐體系也是至關的龐大，複雜。所幸的是這十年來Google等領先的企業、Hadoop / Spark等開源社區以及大量的廠商大體聯合探索出了一條可行的路徑，方法論和技術路線都比較統一了。以此爲基礎，就能夠提供較成熟的數據中臺技術支撐產品，如網易杭研研發的「網易猛獁V6.0 + 網易有數」就是一套較完整的數據中臺產品。

中臺建設的方法論

復瑣事務都須要方法論的指導（和約束），組織管理有虛虛實實的一大套各類理論，研發有敏捷方法或IPD流程，中臺是復瑣事務，因此也須要方法論。由於中臺建設涉及組織和技術兩個維度，因此中臺的方法論也應該要覆蓋這兩個維度。目前而言，技術維度的方法論相對成熟，由於複用了不少原有的方法論。

01在線業務中臺方法論

對於業務中臺，微服務、網關、REST API及語義化版本控制、六邊形架構是側重於技術架構的方法論，DevOps、敏捷項目管理是側重於流程層面的方法論，領域驅動設計（DDD）是側重於業務架構的方法論。要作好業務中臺，以上方法論大概都不可或缺。
你們能夠看到，除了微服務跟中臺大體是同步發展的以外，其餘方法論都是早前就存在的東西。正由於有這麼多合適的方法論存在，中臺才變得可行，不管如何在短時間內要發展出這麼多方法論是不現實的，由於方法論的威力不只在於它要好，還在於它要流行。

技術架構和流程方面的方法論已經很流行，無需多說（六邊形架構放在和DDD一塊兒介紹）。值得關注的是領域驅動設計這麼一個10多年前就被提出，這麼多年一直不溫不火的方法論，忽然在中臺領域彷佛找到了它的最佳安身之所。這樣的現象是會曇花一現，仍是會長期持續，值得思考。

DDD的核心概念是通用語言和限界上下文。通用語言指的是在一個業務領域內通用（但不是在更大的領域內也徹底通用的）的概念、術語等語言，限界上下文指的是相鄰通用語言之間「翻譯」的邊界，好比前臺業務的用戶可能要變成後臺清算的客戶。

我以爲DDD的通用語言和一直以來的領域建模是比較類似的，更具創新意義的是限界上下文。在架構設計中，咱們要不要構造那種擁有很是多屬性，但每一個使用者只使用少許屬性，或者屬性的名稱和含義對使用者來講不貼切的對象？若是沒有限界上下文的約束，可能會認爲這樣畢竟實現了更多的複用，是好的，但用限界上下文的理念來看，這樣極可能是很差的。每一個領域應該專一於本身領域的語言，領域之間要交互怎麼辦？加一種翻譯機制，也就是限界上下文解決。

領域驅動和限界上下文的理念會天然延伸出六邊形架構的設計。所謂六邊形架構指的是一個程序的內部只須要處理業務邏輯，他的數據 / 請求從哪裏來，數據要存儲到哪裏去（或者領域事件要發佈），都經過各類適配器完成。由於這樣的適配器可能較多，就再也不像傳統的三層（三明治）架構。不過若是六邊形只有一個Input和一個Output適配器的話，和三層架構就仍是差很少的。我想從三層架構進化到六邊形架構的主要緣由仍是由於如今的環境已經從傳統的C / S或B / S這樣只有一個前端，也只有RDBMS這樣的一個後端發展到前面有Web / 移動等多個端，向後也有RDBMS / NoSQL等多個端，橫向也有服務化 / MQ等多個端的多端環境。我不知道哪天會不會發展出一個十面埋伏架構出來。

02數據中臺方法論

數據中臺的方法論也是博採衆長，最核心的來自於數據倉庫領域關於數據倉庫規劃實施和指標體系建設的方法。在數據倉庫領域，有兩套大相徑庭的方法以前一直是較勁的，一個是數據倉庫之父Bill Inmon所倡導的至上而下的方法，另外一個是另外一位大師級人物Kimball所倡導的至下而上的方法。在我理解，所謂Kimball的模式之因此說是至下而上，是由於基本上中臺團隊只負責從ODS到DWD到DWS就完了，往上就是所謂的ADS，其實已是面向各個業務（或者數據產品）了。你均可以說ADS層不屬於數倉。這樣的方法在中臺做爲一種新生事務無法有很強的話語權時顯然是更容易作出的選擇，可能將來中臺概念深刻人心，集團高度重視，說不定Inmon方法又會從新流行？但也能夠思考這種細節上都體現了領導的管理意志的中臺仍是中臺嗎。指標設計的方法論基於Kimball方法中的粒度建模的方法，作了比較大的細化和改進。

劃分主題域是建數據中臺的常見實踐，不過主題域劃分與行業強相關，好比對零售業常見的有商品、交易、流量、用戶、營銷等域。

數據中臺統一經過數據服務系統實現OneService的設計，不清楚有什麼來源，不過相似於在業務架構中很常見的網關模式。數據質量、數據安全、元數據、生命週期管理也都是數據治理領域比較常見的概念，但一方面要實現針對大數據技術環境的落地，另外一方面更面向業務支持而非管控來設計。

實施數據中臺一般還須要制定不少規範或標準，這也能夠說是方法論的一方面。有不少規範是命名規範，其中數量最大的每每是數據倉庫中的表，上萬張表甚至更多都是很常見的，因此表的規範命名很是必要。一種好的表的命名規範，要反映其所在數倉分層、主題域、業務過程、時間週期等信息。計算任務也須要必定的命名規範。數據埋點也須要規範性的編碼位置信息、內容信息和事件信息。

03組織維度的方法論及其餘業

其餘類型的中臺也都有各自的方法論。如搜索中臺，B公司有比較詳細的對外分享的資料，其方法論主要體如今規範了搜索系統的關鍵流程，如內容引入和加工、離線訓練、在線召回和排序等，還會涉及到查詢改寫、展現設計等要點。

以上說的都是中臺技術維度的方法論，組織維度的方法論目前尚未看到好的系統性分析成果。在《企業IT架構轉型之道》中只有不多的篇幅介紹中臺組織維度的方法論，在另外一本講數據中臺的書中，乾脆就隻字沒提組織方面的內容。業界關於中臺組織的方法論，主要包括多職能小微團隊、業務架構師主導、協做溝通機制、輪崗、共建、考覈機制等。業界也有從通常性的組織管理維度（如垂直型組織、矩陣型組織等等）分析，過於寬泛，說了等於沒說。

中臺組織層面的方法論多是相對不成熟的，好比中臺和前臺、平臺之間的邊界和動向問題，彷佛沒有明確的方法。我認爲可能主流會符合「前臺->中臺->平臺「單向流動的中心法則。可能中臺組織的終極目標是發展爲平臺，由於仍是要追求把能力作成熟和標準，我這也多是很反動的說法。

做爲集團的創新業務孵化中心，網易杭研每時每刻都針對不少業務線要並行發展，爲此打造了一個又一個共享能力中心，想方設法提高創新效率。12年來感受摸索了一些關於中臺的建設經驗，固然可能更多的是教訓，這段經歷的體會後續我將會作個梳理，發出來供你們討論。

中臺建設的諮詢服務

說到諮詢，我首先想到的是技術進步的驅動力發生了很大的變化，從廠商和諮詢公司驅動變成了領先客戶驅動。以在線業務爲例，傳統的SOA和Web Services技術是傳統廠商驅動的。這些廠商本身不用產品但要賣產品，因此一不當心就把產品搞的沒必要要的複雜。另外這些廠商和諮詢公司原本就是共生共榮的關係，因此也得把產品搞的複雜一點吧，否則諮詢公司就沒生意了。新生代的微服務技術主要是領先的互聯網企業驅動的，本身造產品本身用，能簡單一點就簡單一點，最好是作成各個業務部門本身就能用。

因此新生代的中臺技術是盡力將諮詢的必要性儘可能下降的，可是由於當前實踐中臺的都是很大的互聯網企業，業務複雜度不可避免的很高，對於大多數想要實踐中臺的非互聯網企業來講，仍然是須要諮詢服務。

現狀是，當前中臺的諮詢很是欠缺。由於這些中臺都是互聯網企業搞的，當前的廠商和諮詢公司都沒什麼能力作這塊的諮詢。咱們能夠看到一些諮詢公司，不懂中臺，把什麼都往中臺的概念上湊。當前也就互聯網企業或有很強互聯網企業背景的團隊纔有能力作諮詢，但資源頗有限。但願諮詢公司們可以聚焦於真正的中臺，透徹理解什麼是中臺，提高本身的諮詢能力。

做者簡介

網易副總裁，網易杭州研究院執行院長 汪源
2006年獲浙江大學計算機專業博士學位，以後加入網易公司。現做爲網易杭州研究院執行院長，全面負責網易集團公共技術支撐工做與雲計算、大數據業務，主要包括雲計算與服務端架構、前端技術、大數據挖掘分析、信息安全、多媒體、運維、質量保障等方向。

點擊連接更多關於網易數據中臺