例舉典型的需要建設中臺的場景，供參考判斷要不要建中臺。建設中臺需要考慮組織、技術(shù)支撐和方法論，往往還需要咨詢服務的幫助，本文可以作為思考中臺建設的大框架。

這是中臺系列的第二篇。上一篇什么是中臺，什么不是中臺闡釋清楚了中臺的概念，這一篇說明什么情況下可以考慮建中臺，如果要建要怎么建的問題。

要建設中臺，首先要考慮要不要建設中臺。話說的這么繞是因為現(xiàn)在有很多不明就理就想建中臺的。這個問題先做個初略的判斷。

1 要不要建設中臺

對業(yè)務中臺來說，比較符合的場景主要有：

• 業(yè)務系統(tǒng)研發(fā)團隊至少大幾十人以上（含外包的），需求多變化快，系統(tǒng)又涉及多個領(lǐng)域（比如做ERP、電商的），業(yè)務邏輯比較復雜。這時業(yè)務中臺可以把系統(tǒng)和業(yè)務領(lǐng)域劃分清楚，提高研發(fā)效率。

• 做相似行業(yè)的外包項目為主，業(yè)務規(guī)模也做的比較大的（一年有兩位數(shù)的項目）。這時業(yè)務中臺可以提升軟件復用，降低定制化成本，提高研發(fā)效率。如果你做外包，每個項目都完全不一樣，那中臺也救不了你。

此外還有以下場景可能不需要建設完整的中臺，但適合落地與中臺相關(guān)的微服務技術(shù)的：

• 大規(guī)?；ヂ?lián)網(wǎng)式在線系統(tǒng)，對穩(wěn)定性和彈性要求高當前搞不定的。微服務或業(yè)務中臺可以比較好的解決這些問題。

• 掉到IT豎井的坑里想爬出來的，通過項目外包做的系統(tǒng)無法管理和維護的。微服務或業(yè)務中臺可以對系統(tǒng)的API、文檔等進行有效管理，也能實現(xiàn)系統(tǒng)間的打通。

對數(shù)據(jù)中臺來說，比較符合的場景主要是數(shù)據(jù)產(chǎn)品比較多，每天要看數(shù)據(jù)如果沒數(shù)據(jù)就不知道怎么工作的運營人員比較多的業(yè)務。比如電商就是典型。如果這些數(shù)據(jù)產(chǎn)品和運營人員還在多個團隊，那基本上數(shù)據(jù)中臺沒跑了。如果經(jīng)常出現(xiàn)指標不一致、數(shù)據(jù)出錯、想要的數(shù)據(jù)不知道哪里有等問題，那基本上數(shù)據(jù)中臺也沒跑了。

并不是數(shù)據(jù)量大就需要建中臺，主要還是看用數(shù)據(jù)的姿勢是不是比較復雜，當前問題是不是比較多。對于這類符合的業(yè)務，數(shù)據(jù)中臺能把層層數(shù)據(jù)直到最上層的指標梳理清楚，提升數(shù)據(jù)質(zhì)量，從而提升運營效率。把數(shù)據(jù)理清楚了，往往還能降低數(shù)據(jù)存儲和數(shù)據(jù)開發(fā)人員的成本。

除了上述判斷，還有一條是同行對比。如果一個行業(yè)大家都有點躍躍欲試想弄中臺，那領(lǐng)先者一定要想辦法搶先（既然是領(lǐng)先者了，往往也符合上述標準），不然就可能被顛覆。跟隨者要不要想辦法搶先從而超越領(lǐng)先者呢？可能不好說吧，但如果領(lǐng)先者已經(jīng)建了，跟隨者一般得緊跟，否則真可能被甩開了。

如果根據(jù)上述邏輯覺得大致要考慮去搞一把中臺的話，那請繼續(xù)讀本文以下內(nèi)容，讀完本文后續(xù)內(nèi)容然后更具體的看看問題存不存在，條件是否具備。

要建設中臺，需要考慮組織、支撐技術(shù)、方法論這三個方面，往往還需要咨詢服務。

2 組織

中臺作為一種有業(yè)務屬性的共性能力，首先就需要一個懂業(yè)務、承擔業(yè)務職責的專職的組織機構(gòu)來負責。要不要建中臺，首先要看領(lǐng)導有沒有魄力去整合建立一個中臺組織。因為原來的平臺部通常不懂業(yè)務，懂業(yè)務的人各自分散在前臺業(yè)務部門，所以建立中臺組織往往涉及人員、組織架構(gòu)和部門職責的調(diào)整。正因為如此，中臺的建設往往需要作為一把手工程才能成功。

中臺組織關(guān)鍵要懂業(yè)務和承擔業(yè)務職責。舉個例子，一個大數(shù)據(jù)平臺的建設運維團隊不是一個中臺組織。一個團隊如果做了非常完善的中臺產(chǎn)品（如開發(fā)了數(shù)據(jù)中臺所需要的指標管理系統(tǒng)、數(shù)據(jù)倉庫開發(fā)系統(tǒng)、數(shù)據(jù)質(zhì)量管理系統(tǒng)等等），但只是把產(chǎn)品提供給業(yè)務方使用，這個團隊仍然不能說是中臺組織。只有當這個團隊承擔起指標體系的建設和管理、數(shù)據(jù)倉庫的設計和實施、數(shù)據(jù)質(zhì)量的保障等工作時，才可以說是中臺組織。而要做到這一點，這個組織肯定是比較了解業(yè)務的，它的目標和考核也一定與業(yè)務有相關(guān)性（肯定不只是平臺穩(wěn)定性這樣的非業(yè)務指標）。

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

這里特別說明一點的是如果不建設在線業(yè)務中臺，而只是采用微服務、云原生這些敏捷研發(fā)技術(shù)的話，可以不涉及組織方面的變動，就在原來的研發(fā)部實現(xiàn)轉(zhuǎn)型。通常來說也可以實現(xiàn)一定的系統(tǒng)可用率、彈性和研發(fā)效率方面的提升。

3 支撐技術(shù)

建設中臺一般需要一套支撐技術(shù)。

3.1、在線業(yè)務中臺支撐技術(shù)

建設在線業(yè)務中臺一般需要云原生、DevOps、微服務技術(shù)體系的支撐，這是因為：

• 微服務技術(shù)：中臺是一個獨立的組織負責并為多個前臺業(yè)務服務，因此需要一個標準的服務接口、成熟的服務治理能力和高效的敏捷研發(fā)技術(shù)。在當前的技術(shù)環(huán)境下，采用地球人都熟悉的REST風格的同步API、消息隊列異步通信作為標準的服務接口技術(shù)，采用服務框架（如Spring Cloud等）、API網(wǎng)關(guān)、APM等作為標準的服務治理和敏捷研發(fā)技術(shù)是最合適的選擇。不再建議采用傳統(tǒng)的基于ESB的服務化（SOA）技術(shù)，因為ESB產(chǎn)品過多的介入到業(yè)務邏輯中，導致前臺業(yè)務的變更往往需要中臺團隊的配合才能完成，這樣就失去了建設好中臺，支撐前臺高效創(chuàng)新的意義。此外，中心化的ESB軟件和復雜的基于XML的WS-xxx等協(xié)議也影響到系統(tǒng)的可用性和性能?？梢詤⒁奙artin Fowler在P of EAA中的評價，Web Services是應用集成而非應用開發(fā)的技術(shù)。

• DevOps技術(shù)：如果不通過DevOps使得各微服務都能自助式的部署更新，則微服務帶來的敏捷性就無從發(fā)揮，反而因為服務數(shù)量的增加導致研發(fā)效率的下降，因此持續(xù)集成、持續(xù)發(fā)布等DevOps技術(shù)一般是實現(xiàn)微服務的必備。

• 云原生技術(shù)：微服務和DevOps要求底層的基礎(chǔ)設施是靈活可編程的，否則根據(jù)Amdahl定律，只要有一個必須的環(huán)節(jié)是低效的，整體的效能也提不上去。需要強調(diào)的是中臺要敏捷，這一方面是因為中臺具備業(yè)務屬性，且支撐了非常豐富的前臺業(yè)務，前臺業(yè)務的敏捷性要求有一部分就會傳導的中臺層；另一方面是中臺的重要性使得其需要持續(xù)不斷的優(yōu)化，即便對外提供的服務不變，內(nèi)部實現(xiàn)也會經(jīng)常變。

• 分布式事務技術(shù)：實施微服務拆分后，復雜的業(yè)務流程不再能通過數(shù)據(jù)庫的事務機制來實現(xiàn)ACID特性，為此還需要服務層面的分布式事務處理技術(shù)。典型的分布式事務處理模型包括TCC、Saga、FMT等。其中TCC和Saga需要各服務實現(xiàn)定制化回滾邏輯，侵入性比較嚴重，用起來門檻比較高。FMT模式對于Java可以做到加一行注解（如@GlobalTransaction）即可實現(xiàn)分布式事務，剩下的由框架自動處理，用起來方便的多。Saga模式是Princeton的兩位研究者在1987年提出的，靈活性和并發(fā)度最好，但需要通過語義鎖等精細的設計才能發(fā)揮出來。

由此可見，在線業(yè)務中臺的技術(shù)支撐體系是相當復雜的，所幸的是Netflix、Google等世界領(lǐng)先的互聯(lián)網(wǎng)企業(yè)由于自身業(yè)務需要打造了很多實用的技術(shù)模塊，開源社區(qū)也貢獻了不少力量，CNCF組織又做了很好的匯集和標準化。通過將相關(guān)技術(shù)加以整合，已經(jīng)有了不錯的產(chǎn)品可用，如網(wǎng)易輕舟微服務就是一套產(chǎn)品化設計良好、功能豐富的在線業(yè)務中臺支撐技術(shù)產(chǎn)品。

一般而言，前臺也會和在線業(yè)務中臺一樣采用云原生等同樣的技術(shù)體系，這是因為前臺更需要敏捷性。在完善的中臺支撐之下，前臺會比較輕，還可以考慮采用FaaS Serverless技術(shù)，不過目前這方面的實踐還不多（特別在中國），相關(guān)的支撐技術(shù)也不是很成熟。

3.2、數(shù)據(jù)中臺支撐技術(shù)

建設數(shù)據(jù)中臺一般需要一整套如下典型的支撐技術(shù)：

• 指標管理系統(tǒng)：指標是中臺與前臺之間最關(guān)鍵的接口，也是建設數(shù)據(jù)中臺的牛鼻子，因為它是最核心的業(yè)務語言，且指標不一致、數(shù)據(jù)常出錯是建設數(shù)據(jù)中臺最常見的出發(fā)點。如果指標體系沒有統(tǒng)一的方法論，進行統(tǒng)一建設，那么就很難說是數(shù)據(jù)中臺。指標管理系統(tǒng)一般要實現(xiàn)一套一致的方法論（如原子 / 派生 / 復合指標、維度、修飾詞等），做好指標的業(yè)務和技術(shù)口徑管理，還需要支持指標的審批管理。數(shù)據(jù)中臺的指標無法交給各前臺業(yè)務自助式的建設。

• 數(shù)據(jù)服務系統(tǒng)：類似于在線業(yè)務中臺需要通過API網(wǎng)關(guān)提供標準化的服務，數(shù)據(jù)中臺也需要一個標準化的服務方式，通常稱為數(shù)據(jù)服務系統(tǒng)，也可以說是數(shù)據(jù)網(wǎng)關(guān)或數(shù)據(jù)門戶。類似于別的網(wǎng)關(guān)類產(chǎn)品，數(shù)據(jù)服務系統(tǒng)需要提供鑒權(quán)、日志審計、流控、協(xié)議轉(zhuǎn)換（如SQL Dialect之間的轉(zhuǎn)換）等功能，也應該發(fā)展多引擎融合查詢、邏輯模型等擴展功能以提高服務接口的穩(wěn)定性和實現(xiàn)的靈活性。

• 元數(shù)據(jù)管理系統(tǒng)：元數(shù)據(jù)管理是整個數(shù)據(jù)中臺的基礎(chǔ)和中心，所有的其他系統(tǒng)都依賴元數(shù)據(jù)管理。元數(shù)據(jù)管理首先要做好的當然是數(shù)據(jù)模式或目錄（catalog）的管理，至少要知道中臺里都有什么數(shù)據(jù)。對復雜的數(shù)據(jù)中臺來說，數(shù)據(jù)血緣也很重要。沒有血緣信息，不知道數(shù)據(jù)間的依賴關(guān)系，數(shù)據(jù)質(zhì)量肯定管不好，因為不知道一個數(shù)據(jù)的質(zhì)量問題怎么來，又進而會影響什么。同樣的如果沒有血緣，數(shù)據(jù)資產(chǎn)也肯定管不好，因為不知道什么數(shù)據(jù)有價值什么沒價值，這就像如果你不知道一個函數(shù)被誰調(diào)用，你就不知道它是不是死代碼一樣。元數(shù)據(jù)管理系統(tǒng)往往也需要提供一個基礎(chǔ)的訪問界面，通常稱之為數(shù)據(jù)地圖。

• 數(shù)據(jù)倉庫開發(fā)與管理系統(tǒng)：除了指標管理，數(shù)據(jù)倉庫的開發(fā)是將一大堆初始數(shù)據(jù)建設梳理成一個漂亮的數(shù)據(jù)中臺的核心過程。一般來講數(shù)據(jù)中臺更適合用Kimball的維度建模方法而非數(shù)據(jù)倉庫之父Bill Inmon所提倡的方法，這是因為Inmon強調(diào)頂層設計，而Kimball強調(diào)至下而上。如果要建設數(shù)據(jù)中臺，肯定是因為前臺業(yè)務復雜多變，這時強調(diào)頂層設計會導致中臺建設緩慢、僵化。因為中臺雖然應該是由組織高層決策，但目的卻是為了支持前臺業(yè)務，而不是為了控制。*支持而不是控制*，這一點絕不能本末倒置。

• 數(shù)據(jù)質(zhì)量管理系統(tǒng)：所有復雜的系統(tǒng)都需要專業(yè)的質(zhì)量管理，在線業(yè)務系統(tǒng)有一系列的彈力設計和APM等監(jiān)控運維工具，數(shù)據(jù)中臺也需要專業(yè)的質(zhì)量管理。數(shù)據(jù)質(zhì)量管理系統(tǒng)通常設計為支持豐富的稽核 / 校驗 / 比對規(guī)則，監(jiān)控數(shù)據(jù)是否準確、實時、一致，還要做到及時的報警，分析影響面，提供快速修復的手段等。但這些手段只能發(fā)現(xiàn)和補救問題，不能預防問題，要預防問題，還要通過測試工具減少代碼bug、通過資源彈性應對性能波動、通過優(yōu)先級調(diào)度優(yōu)先滿足重要業(yè)務需求等。相對來說，當前數(shù)據(jù)中臺領(lǐng)域的質(zhì)量管理沒有在線業(yè)務領(lǐng)域的成熟，如在線業(yè)務領(lǐng)域的測試手段遠比數(shù)據(jù)領(lǐng)域的精細，在線業(yè)務領(lǐng)域很常見的熔斷、限流、服務降級等模式在數(shù)據(jù)領(lǐng)域都沒有成熟的實踐方法（優(yōu)先級調(diào)度可以說是實現(xiàn)了部分的服務降級功能），隨著數(shù)據(jù)中臺越來越廣泛和重要，這些技術(shù)應該也需要持續(xù)發(fā)展，但技術(shù)上的挑戰(zhàn)不小。

• 數(shù)據(jù)安全管理系統(tǒng)：數(shù)據(jù)中臺因為匯集了組織所有有價值的數(shù)據(jù)資產(chǎn)，因此良好的安全管理是必須的。細粒度的權(quán)限和審計是基礎(chǔ)，一般的還需要隱私 / 敏感數(shù)據(jù)的脫敏處理、數(shù)據(jù)加密（特別是將數(shù)據(jù)托管在第三方平臺之上時）、數(shù)據(jù)泄漏防護（比方說一種常見的方法是限制將數(shù)據(jù)下載到本地的數(shù)據(jù)量）等技術(shù)。發(fā)展到高級階段甚至可能還需要聯(lián)邦學習、數(shù)據(jù)沙盒等技術(shù)。

• 數(shù)據(jù)資產(chǎn)管理系統(tǒng)：在數(shù)據(jù)質(zhì)量和安全單列的情況下，數(shù)據(jù)資產(chǎn)管理主要負責的是數(shù)據(jù)的生命周期管理、成本的統(tǒng)計分析與優(yōu)化等工作。

同時，數(shù)據(jù)中臺還需要強大的大數(shù)據(jù)計算引擎、數(shù)據(jù)集成 / 同步 / 交換引擎，還往往需要一套敏捷BI系統(tǒng)：

• 大數(shù)據(jù)計算引擎：數(shù)據(jù)中臺要管理的數(shù)據(jù)規(guī)模和復雜度往往都很高（否則搞中臺屬于為賦新詞強說愁），所以傳統(tǒng)的數(shù)據(jù)庫和數(shù)據(jù)倉庫基本上支撐不了。當前的技術(shù)環(huán)境下，基于Hadoop MapReduce或Spark幾乎是唯二的選擇，當然這也包括了這兩者之上的Hive和Spark SQL。能有SQL就用SQL，易于維護，也易于數(shù)據(jù)血緣的收集。除此之外，流處理可能還需要Flink，交互式查詢可能要引入Impala或GreenPlum。

• 數(shù)據(jù)集成 / 同步 / 交換引擎：一方面數(shù)據(jù)中臺需要強大的數(shù)據(jù)集成和同步能力才能吸納各方數(shù)據(jù)。集成和同步的概念相近，同步更強調(diào)實時性。另一方面，數(shù)據(jù)中臺往往由多種數(shù)據(jù)計算引擎構(gòu)成，就需要同步或交換引擎實現(xiàn)不同引擎見的數(shù)據(jù)交換。

• 敏捷BI系統(tǒng)：建設數(shù)據(jù)中臺通常最重要的目的是為了支持業(yè)務運營和決策，為此需要基于數(shù)據(jù)中臺進一步開發(fā)數(shù)據(jù)產(chǎn)品。敏捷BI系統(tǒng)是開發(fā)數(shù)據(jù)產(chǎn)品快速、輕型的手段，能夠盡快盡早的發(fā)揮數(shù)據(jù)中臺的價值。

此外，對于互聯(lián)網(wǎng)業(yè)務，統(tǒng)一的埋點引擎往往也是數(shù)據(jù)中臺所需要的。如果埋點的邏輯都不統(tǒng)一的話，建數(shù)據(jù)中臺的時候會發(fā)現(xiàn)數(shù)據(jù)的源頭就是亂的，后續(xù)也都沒法做。其他行業(yè)業(yè)務，數(shù)據(jù)采集也屬于基礎(chǔ)工作，也是要先做好的。

由此可見，建設數(shù)據(jù)中臺需要的技術(shù)支撐體系也是相當?shù)凝嫶螅瑥碗s。所幸的是這十年來Google等領(lǐng)先的企業(yè)、Hadoop / Spark等開源社區(qū)以及大量的產(chǎn)商大致聯(lián)合探索出了一條可行的路徑，方法論和技術(shù)路線都比較統(tǒng)一了。以此為基礎(chǔ)，就可以提供較成熟的數(shù)據(jù)中臺技術(shù)支撐產(chǎn)品，如網(wǎng)易杭研研發(fā)的“網(wǎng)易猛犸V6.0 + 網(wǎng)易有數(shù)”就是一套較完整的數(shù)據(jù)中臺產(chǎn)品。

 4 方法論

復雜事務都需要方法論的指導（和約束），組織管理有虛虛實實的一大套各種理論，研發(fā)有敏捷方法或IPD流程，中臺是復雜事務，所以也需要方法論。因為中臺建設涉及組織和技術(shù)兩個維度，所以中臺的方法論也應該要覆蓋這兩個維度。目前而言，技術(shù)維度的方法論相對成熟，因為復用了很多原有的方法論。

4.1、在線業(yè)務中臺方法論

對于業(yè)務中臺，微服務、網(wǎng)關(guān)、REST API及語義化版本控制、六邊形架構(gòu)是側(cè)重于技術(shù)架構(gòu)的方法論，DevOps、敏捷項目管理是側(cè)重于流程層面的方法論，領(lǐng)域驅(qū)動設計（DDD）是側(cè)重于業(yè)務架構(gòu)的方法論。要做好業(yè)務中臺，以上方法論大概都不可或缺。

大家可以看到，除了微服務跟中臺大致是同步發(fā)展的之外，其他方法論都是早前就存在的東西。正因為有這么多合適的方法論存在，中臺才變得可行，無論如何在短期內(nèi)要發(fā)展出這么多方法論是不現(xiàn)實的，因為方法論的威力不僅在于它要好，還在于它要流行。

技術(shù)架構(gòu)和流程方面的方法論已經(jīng)很流行，無需多說（六邊形架構(gòu)放在和DDD一起介紹）。值得關(guān)注的是領(lǐng)域驅(qū)動設計這么一個10多年前就被提出，這么多年一直不溫不火的方法論，突然在中臺領(lǐng)域似乎找到了它的最佳安身之所（也可以說中臺找到了DDD這么一根救命稻草？）。這樣的現(xiàn)象是會曇花一現(xiàn)，還是會長期持續(xù)，值得思考。

DDD的核心概念是通用語言和限界上下文。通用語言指的是在一個業(yè)務領(lǐng)域內(nèi)通用（但不是在更大的領(lǐng)域內(nèi)也完全通用的）的概念、術(shù)語等語言，限界上下文指的是相鄰通用語言之間“翻譯”的邊界，比如前臺業(yè)務的用戶可能要變成后臺清算的客戶。

我覺得DDD的通用語言和一直以來的領(lǐng)域建模是比較相似的，更具創(chuàng)新意義的是限界上下文。在架構(gòu)設計中，我們要不要構(gòu)造那種擁有非常多屬性，但每個使用者只使用少量屬性，或者屬性的名稱和含義對使用者來說不貼切的對象？如果沒有限界上下文的約束，可能會認為這樣畢竟實現(xiàn)了更多的復用，是好的，但用限界上下文的理念來看，這樣很可能是不好的。每個領(lǐng)域應該專注于自己領(lǐng)域的語言，領(lǐng)域之間要交互怎么辦？加一種翻譯機制，也就是限界上下文解決。

領(lǐng)域驅(qū)動和限界上下文的理念會自然延伸出六邊形架構(gòu)的設計。所謂六邊形架構(gòu)指的是一個程序的內(nèi)部只需要處理業(yè)務邏輯，他的數(shù)據(jù) / 請求從哪里來，數(shù)據(jù)要存儲到哪里去（或者領(lǐng)域事件要發(fā)布），都通過各種適配器完成。因為這樣的適配器可能較多，就不再像傳統(tǒng)的三層（三明治）架構(gòu)。不過如果六邊形只有一個Input和一個Output適配器的話，和三層架構(gòu)就還是差不多的。我想從三層架構(gòu)進化到六邊形架構(gòu)的主要原因還是因為現(xiàn)在的環(huán)境已經(jīng)從傳統(tǒng)的C / S或B / S這樣只有一個前端，也只有RDBMS這樣的一個后端發(fā)展到前面有Web / 移動等多個端，向后也有RDBMS / NoSQL等多個端，橫向也有服務化 / MQ等多個端的多端環(huán)境。我不知道哪天會不會發(fā)展出一個十面埋伏架構(gòu)出來。

4.2、數(shù)據(jù)中臺方法論

數(shù)據(jù)中臺的方法論也是博采眾長，最核心的來自于數(shù)據(jù)倉庫領(lǐng)域關(guān)于數(shù)據(jù)倉庫規(guī)劃實施和指標體系建設的方法。在數(shù)據(jù)倉庫領(lǐng)域，有兩套截然不同的方法之前一直是較勁的，一個是數(shù)據(jù)倉庫之父Bill Inmon所倡導的至上而下的方法，另一個是另一位大師級人物Kimball所倡導的至下而上的方法。在我理解，所謂Kimball的模式之所以說是至下而上，是因為基本上中臺團隊只負責從ODS到DWD到DWS就完了，往上就是所謂的ADS，其實已經(jīng)是面向各個業(yè)務（或者數(shù)據(jù)產(chǎn)品）了。你都可以說ADS層不屬于數(shù)倉。這樣的方法在中臺作為一種新生事務沒法有很強的話語權(quán)時顯然是更容易做出的選擇，可能未來中臺概念深入人心，集團高度重視，說不定Inmon方法又會重新流行？但也可以思考這種細節(jié)上都體現(xiàn)了領(lǐng)導的管理意志的中臺還是中臺嗎。指標設計的方法論基于Kimball方法中的粒度建模的方法，做了比較大的細化和改進。

劃分主題域是建數(shù)據(jù)中臺的常見實踐，不過主題域劃分與行業(yè)強相關(guān)，比如對零售業(yè)常見的有商品、交易、流量、用戶、營銷等域。

數(shù)據(jù)中臺統(tǒng)一通過數(shù)據(jù)服務系統(tǒng)實現(xiàn)OneService的設計，不清楚有什么來源，不過類似于在業(yè)務架構(gòu)中很常見的網(wǎng)關(guān)模式。數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全、元數(shù)據(jù)、生命周期管理也都是數(shù)據(jù)治理領(lǐng)域比較常見的概念，但一方面要實現(xiàn)針對大數(shù)據(jù)技術(shù)環(huán)境的落地，另一方面更面向業(yè)務支持而非管控來設計。

實施數(shù)據(jù)中臺通常還需要制定很多規(guī)范或標準，這也可以說是方法論的一方面。有很多規(guī)范是命名規(guī)范，其中數(shù)量最大的往往是數(shù)據(jù)倉庫中的表，上萬張表甚至更多都是很常見的，所以表的規(guī)范命名非常必要。一種好的表的命名規(guī)范，要反映其所在數(shù)倉分層、主題域、業(yè)務過程、時間周期等信息。計算任務也需要一定的命名規(guī)范。數(shù)據(jù)埋點也需要規(guī)范性的編碼位置信息、內(nèi)容信息和事件信息。

4.3、組織維度的方法論及其他

其他類型的中臺也都有各自的方法論。如搜索中臺，百度有比較詳細的對外分享的資料，其方法論主要體現(xiàn)在規(guī)范了搜索系統(tǒng)的關(guān)鍵流程，如內(nèi)容引入和加工、離線訓練、在線召回和排序等，還會涉及到查詢改寫、展示設計等要點。

以上說的都是中臺技術(shù)維度的方法論，組織維度的方法論目前還沒有看到好的系統(tǒng)性分析成果。在阿里中臺藍寶書（《企業(yè)IT架構(gòu)轉(zhuǎn)型之道》）中只有很少的篇幅介紹中臺組織維度的方法論，在另一本阿里講數(shù)據(jù)中臺的書中，干脆就只字沒提組織方面的內(nèi)容。阿里關(guān)于中臺組織的方法論，主要包括多職能小微團隊、業(yè)務架構(gòu)師主導、協(xié)作溝通機制、輪崗、共建、考核機制等。業(yè)界也有從一般性的組織管理維度（如垂直型組織、矩陣型組織等等）分析，過于寬泛，說了等于沒說。

中臺組織層面的方法論可能是相對不成熟的，比如中臺和前臺、平臺之間的邊界和動向問題，似乎沒有明確的方法。我認為可能主流會符合“前臺->中臺->平臺“單向流動的中心法則?？赡苤信_組織的終極目標是發(fā)展為平臺，因為還是要追求把能力做成熟和標準，我這也可能是很反動的說法。

作為集團的創(chuàng)新業(yè)務孵化中心，網(wǎng)易杭研每時每刻都針對很多業(yè)務線要并行發(fā)展，為此打造了一個又一個共享能力中心，千方百計提升創(chuàng)新效率。12年來感覺摸索了一些關(guān)于中臺的建設經(jīng)驗，當然可能更多的是教訓，這段經(jīng)歷的體會后續(xù)我將會做個梳理，發(fā)出來供大家討論。

5 咨詢

說到咨詢，我首先想到的是技術(shù)進步的驅(qū)動力發(fā)生了很大的變化，從產(chǎn)商和咨詢公司驅(qū)動變成了領(lǐng)先客戶驅(qū)動。以在線業(yè)務為例，傳統(tǒng)的SOA和Web Services技術(shù)是IBM、BEA等產(chǎn)商驅(qū)動的。產(chǎn)商自己不用產(chǎn)品但要賣產(chǎn)品，所以一不小心就把產(chǎn)品搞的不必要的復雜。另外產(chǎn)商和咨詢公司本來就是共生共榮的關(guān)系（像IBM咨詢和產(chǎn)品都做），所以也得把產(chǎn)品搞的復雜一點吧，不然咨詢公司就沒生意了。新生代的微服務技術(shù)主要是領(lǐng)先的互聯(lián)網(wǎng)企業(yè)驅(qū)動的，自己造產(chǎn)品自己用，能簡單一點就簡單一點，最好是做成各個業(yè)務部門自己就能用。

所以新生代的中臺技術(shù)是盡力將咨詢的必要性盡量降低的，但是因為當前實踐中臺的都是很大的互聯(lián)網(wǎng)企業(yè)，業(yè)務復雜度不可避免的很高，對于大多數(shù)想要實踐中臺的非互聯(lián)網(wǎng)企業(yè)來說，仍然是需要咨詢服務。

現(xiàn)狀是，當前中臺的咨詢非常欠缺。因為這些中臺都是互聯(lián)網(wǎng)企業(yè)搞的，當前的產(chǎn)商和咨詢公司都沒什么能力做這塊的咨詢。我們可以看到正是這些咨詢公司，還是在軟件咨詢領(lǐng)域很知名的，不懂中臺，把什么都往中臺的概念上湊。所以這樣的咨詢公司能做咨詢嗎？自己沒做過業(yè)務的產(chǎn)商那就更不用提了。當前也就互聯(lián)網(wǎng)企業(yè)或有很強互聯(lián)網(wǎng)企業(yè)背景的團隊才有能力做咨詢，但資源很有限。希望咨詢公司們能夠聚焦于真正的中臺，透徹理解什么是中臺，提升自己的咨詢能力。