本文將例舉典型的需要建設中臺的場景，供參考判斷要不要建中臺。建設中臺需要考慮組織、技術支撐和方法論，往往還需要諮詢服務的幫助，本文也可以作為思考中臺建設的大框架。
要不要建設中臺？
要建設中臺，首先要考慮要不要建設中臺。話說的這麼繞是因為現在有很多不明就理就想建中臺的。這個問題先做個初略的判斷。
業務中臺的典型場景
對業務中臺來說，比較符合的場景主要有：
業務系統研發團隊至少大幾十人（含外包的），需求多變化快，系統又涉及多個領域（比如做 ERP、電商的），業務邏輯比較複雜。這時業務中臺可以把系統和業務領域劃分清楚，提高研發效率。
做相似行業的外包項目為主，業務規模也做的比較大的（一年有兩位數的項目）。這時業務中臺可以提升軟件複用，降低定製化成本，提高研發效率。如果你做外包，每個項目都完全不一樣，那中臺也救不了你。
此外還有以下場景可能不需要建設完整的中臺，但適合落地與中臺相關的微服務技術的：
大規模互聯網式在線系統，對穩定性和彈性要求高當前搞不定的。微服務或業務中臺可以比較好的解決這些問題。
掉到 IT 豎井的坑裡想爬出來的，通過項目外包做的系統無法管理和維護的。微服務或業務中臺可以對系統的 API、文檔等進行有效管理，也能實現系統間的打通。
數據中臺的典型場景
對數據中臺來說，比較符合的場景主要是數據產品比較多，每天要看數據如果沒數據就不知道怎麼工作的運營人員比較多的業務。比如電商就是典型。如果這些數據產品和運營人員還在多個團隊，那基本上數據中臺沒跑了。如果經常出現指標不一致、數據出錯、想要的數據不知道哪裡有等問題，那基本上數據中臺也沒跑了。
並不是數據量大就需要建中臺，主要還是看用數據的姿勢是不是比較複雜，當前問題是不是比較多。對於這類符合的業務，數據中臺能把層層數據直到最上層的指標梳理清楚，提升數據質量，從而提升運營效率。把數據理清楚了，往往還能降低數據存儲和數據開發人員的成本。
除了上述判斷，還有一條是同行對比。如果一個行業大家都有點躍躍欲試想弄中臺，那領先者一定要想辦法搶先（既然是領先者了，往往也符合上述標準），不然就可能被顛覆。跟隨者要不要想辦法搶先從而超越領先者呢？可能不好說吧，但如果領先者已經建了，跟隨者一般得緊跟，否則真可能被甩開了。
如果根據上述邏輯覺得大致要考慮去搞一把中臺的話，那請繼續讀本文以下內容，讀完本文後續內容然後更具體的看看問題存不存在，條件是否具備。要建設中臺，需要考慮組織、支撐技術、方法論這三個方面，往往還需要諮詢服務。
中臺組織
中臺作為一種有業務屬性的共性能力，首先就需要一個懂業務、承擔業務職責的專職的組織機構來負責。要不要建中臺，首先要看領導有沒有魄力去整合建立一箇中臺組織。因為原來的平臺部通常不懂業務，懂業務的人各自分散在前臺業務部門，所以建立中臺組織往往涉及人員、組織架構和部門職責的調整。正因為如此，中臺的建設往往需要作為一把手工程才能成功。
中臺組織關鍵要懂業務和承擔業務職責。舉個例子，一個大數據平臺的建設運維團隊不是一箇中臺組織。一個團隊如果做了非常完善的中臺產品（如開發了數據中臺所需要的指標管理系統、數據倉庫開發系統、數據質量管理系統等等），但只是把產品提供給業務方使用，這個團隊仍然不能說是中臺組織。只有當這個團隊承擔起指標體系的建設和管理、數據倉庫的設計和實施、數據質量的保障等工作時，才可以說是中臺組織。而要做到這一點，這個組織肯定是比較瞭解業務的，它的目標和考核也一定與業務有相關性（肯定不只是平臺穩定性這樣的非業務指標）。
中臺組織的層次與中臺的層次最好是對應的，BU 級的中臺組織最好直接向 BU 老大或分管的 CXO 彙報，企業的中臺組織最好直接向 CEO 或分管的 CXO 彙報。
這裡特別說明一點的是如果不建設在線業務中臺，而只是採用微服務、雲原生等技術的話，可以不涉及組織方面的大規模變動，就在原來的研發部實現轉型。通常來說也可以實現一定的系統可用率、彈性和研發效率方面的提升。
中臺建設的支撐技術
建設中臺一般需要一套支撐技術。
在線業務中臺支撐技術
建設在線業務中臺一般需要雲原生、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 技術，不過目前這方面的實踐還不多（特別在中國），相關的支撐技術也不是很成熟。
數據中臺支撐技術
建設數據中臺一般需要一整套如下典型的支撐技術：
指標管理系統：指標是中臺與前臺之間最關鍵的接口，也是建設數據中臺的牛鼻子，因為它是最核心的業務語言，且指標不一致、數據常出錯是建設數據中臺最常見的出發點。如果指標體系沒有統一的方法論，進行統一建設，那麼就很難說是數據中臺。指標管理系統一般要實現一套一致的方法論（如原子 / 派生 / 複合指標、維度、修飾詞等），做好指標的業務和技術口徑管理，還需要支持指標的審批管理。數據中臺的指標無法交給各前臺業務自助式的建設。
數據服務系統：類似於在線業務中臺需要通過 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 流程，中臺是複雜事務，所以也需要方法論。因為中颱建設涉及組織和技術兩個維度，所以中臺的方法論也應該要覆蓋這兩個維度。目前而言，技術維度的方法論相對成熟，因為複用了很多原有的方法論。
在線業務中臺方法論
對於業務中臺，微服務、網關、REST API 及語義化版本控制、六邊形架構是側重於技術架構的方法論，DevOps、敏捷項目管理是側重於流程層面的方法論，領域驅動設計（DDD）是側重於業務架構的方法論。要做好業務中臺，以上方法論大概都不可或缺。
大家可以看到，除了微服務跟中臺大致是同步發展的之外，其他方法論都是早前就存在的東西。正因為有這麼多合適的方法論存在，中臺才變得可行，無論如何在短期內要發展出這麼多方法論是不現實的，因為方法論的威力不僅在於它要好，還在於它要流行。
技術架構和流程方面的方法論已經很流行，無需多說（六邊形架構放在和 DDD 一起介紹）。值得關注的是領域驅動設計這麼一個 10 多年前就被提出，這麼多年一直不溫不火的方法論，突然在中臺領域似乎找到了它的最佳安身之所。這樣的現象是會曇花一現，還是會長期持續，值得思考。
DDD 的核心概念是通用語言和限界上下文。通用語言指的是在一個業務領域內通用（但不是在更大的領域內也完全通用的）的概念、術語等語言，限界上下文指的是相鄰通用語言之間“翻譯”的邊界，比如前臺業務的用戶可能要變成後臺清算的客戶。
我覺得 DDD 的通用語言和一直以來的領域建模是比較相似的，更具創新意義的是限界上下文。在架構設計中，我們要不要構造那種擁有非常多屬性，但每個使用者只使用少量屬性，或者屬性的名稱和含義對使用者來說不貼切的對象？如果沒有限界上下文的約束，可能會認為這樣畢竟實現了更多的複用，是好的，但用限界上下文的理念來看，這樣很可能是不好的。每個領域應該專注於自己領域的語言，領域之間要交互怎麼辦？加一種翻譯機制，也就是限界上下文解決。
領域驅動和限界上下文的理念會自然延伸出六邊形架構的設計。所謂六邊形架構指的是一個程序的內部只需要處理業務邏輯，他的數據 / 請求從哪裡來，數據要存儲到哪裡去（或者領域事件要發佈），都通過各種適配器完成。因為這樣的適配器可能較多，就不再像傳統的三層（三明治）架構。不過如果六邊形只有一個 Input 和一個 Output 適配器的話，和三層架構就還是差不多的。我想從三層架構進化到六邊形架構的主要原因還是因為現在的環境已經從傳統的 C / S 或 B / S 這樣只有一個前端，也只有 RDBMS 這樣的一個後端發展到前面有 Web / 移動等多個端，向後也有 RDBMS / NoSQL 等多個端，橫向也有服務化 / MQ 等多個端的多端環境。我不知道哪天會不會發展出一個十面埋伏架構出來。
數據中臺方法論
數據中臺的方法論也是博採眾長，最核心的來自於數據倉庫領域關於數據倉庫規劃實施和指標體系建設的方法。在數據倉庫領域，有兩套截然不同的方法之前一直是較勁的，一個是數據倉庫之父 Bill Inmon 所倡導的至上而下的方法，另一個是另一位大師級人物 Kimball 所倡導的至下而上的方法。在我理解，所謂 Kimball 的模式之所以說是至下而上，是因為基本上中臺團隊只負責從 ODS 到 DWD 到 DWS 就完了，往上就是所謂的 ADS，其實已經是面向各個業務（或者數據產品）了。你都可以說 ADS 層不屬於數倉。這樣的方法在中臺作為一種新生事務沒法有很強的話語權時顯然是更容易做出的選擇，可能未來中臺概念深入人心，集團高度重視，說不定 Inmon 方法又會重新流行？但也可以思考這種細節上都體現了領導的管理意志的中臺還是中臺嗎。指標設計的方法論基於 Kimball 方法中的粒度建模的方法，做了比較大的細化和改進。
劃分主題域是建數據中臺的常見實踐，不過主題域劃分與行業強相關，比如對零售業常見的有商品、交易、流量、用戶、營銷等域。
數據中臺統一通過數據服務系統實現 OneService 的設計，不清楚有什麼來源，不過類似於在業務架構中很常見的網關模式。數據質量、數據安全、元數據、生命週期管理也都是數據治理領域比較常見的概念，但一方面要實現針對大數據技術環境的落地，另一方面更面向業務支持而非管控來設計。
實施數據中臺通常還需要制定很多規範或標準，這也可以說是方法論的一方面。有很多規範是命名規範，其中數量最大的往往是數據倉庫中的表，上萬張表甚至更多都是很常見的，所以表的規範命名非常必要。一種好的表的命名規範，要反映其所在數倉分層、主題域、業務過程、時間週期等信息。計算任務也需要一定的命名規範。數據埋點也需要規範性的編碼位置信息、內容信息和事件信息。
組織維度的方法論及其他業
其他類型的中臺也都有各自的方法論。如搜索中臺，B 公司有比較詳細的對外分享的資料，其方法論主要體現在規範了搜索系統的關鍵流程，如內容引入和加工、離線訓練、在線召回和排序等，還會涉及到查詢改寫、展示設計等要點。
以上說的都是中臺技術維度的方法論，組織維度的方法論目前還沒有看到好的系統性分析成果。在《企業 IT 架構轉型之道》中只有很少的篇幅介紹中臺組織維度的方法論，在另一本講數據中臺的書中，乾脆就隻字沒提組織方面的內容。業界關於中臺組織的方法論，主要包括多職能小微團隊、業務架構師主導、協作溝通機制、輪崗、共建、考核機制等。業界也有從一般性的組織管理維度（如垂直型組織、矩陣型組織等等）分析，過於寬泛，說了等於沒說。
中臺組織層面的方法論可能是相對不成熟的，比如中臺和前臺、平臺之間的邊界和動向問題，似乎沒有明確的方法。我認為可能主流會符合“前臺 -> 中臺 -> 平臺“單向流動的中心法則。可能中臺組織的終極目標是發展為平臺，因為還是要追求把能力做成熟和標準，我這也可能是很反動的說法。
作為集團的創新業務孵化中心，網易杭研每時每刻都針對很多業務線要並行發展，為此打造了一個又一個共享能力中心，千方百計提升創新效率。12 年來感覺摸索了一些關於中臺的建設經驗，當然可能更多的是教訓，這段經歷的體會後續我將會做個梳理，發出來供大家討論。
中臺建設的諮詢服務
說到諮詢，我首先想到的是技術進步的驅動力發生了很大的變化，從廠商和諮詢公司驅動變成了領先客戶驅動。以在線業務為例，傳統的 SOA 和 Web Services 技術是傳統廠商驅動的。這些廠商自己不用產品但要賣產品，所以一不小心就把產品搞的不必要的複雜。另外這些廠商和諮詢公司本來就是共生共榮的關係，所以也得把產品搞的複雜一點吧，不然諮詢公司就沒生意了。新生代的微服務技術主要是領先的互聯網企業驅動的，自己造產品自己用，能簡單一點就簡單一點，最好是做成各個業務部門自己就能用。
所以新生代的中臺技術是盡力將諮詢的必要性儘量降低的，但是因為當前實踐中臺的都是很大的互聯網企業，業務複雜度不可避免的很高，對於大多數想要實踐中臺的非互聯網企業來說，仍然是需要諮詢服務。
現狀是，當前中臺的諮詢非常欠缺。因為這些中臺都是互聯網企業搞的，當前的廠商和諮詢公司都沒什麼能力做這塊的諮詢。我們可以看到一些諮詢公司，不懂中臺，把什麼都往中臺的概念上湊。當前也就互聯網企業或有很強互聯網企業背景的團隊才有能力做諮詢，但資源很有限。希望諮詢公司們能夠聚焦於真正的中臺，透徹理解什麼是中臺，提升自己的諮詢能力。
CIO之家 www.ciozj.com 微信公眾號:imciow
閱讀更多 CIO之家 的文章
