“忽如一夜春風來，千樹萬樹梨花開”，中臺的概念就如這句詩所描述得一樣一瞬間在IT圈里火了起來，好像不討論中臺就任何解決方案就黯然失色了。中臺(數據中臺、業務中臺、技術中臺、AI中臺……)的概念可謂漫天飛舞，我希望在下面的文章中結合真實的實踐案例，就大家最關心的問題從概念到實踐層面做一些解讀。

中臺是什么

在解讀中臺的概念之前我們先看一下“中臺”這個詞的來源。中臺很早的時候由美軍作戰體系演化而來。通過中后臺的強大炮火能力支持前線小團隊的快速判斷，引領整個進攻的完成。意味著讓聽得到炮火聲的人能及時呼喚到炮火。

對于“中臺到底是什么”這個問題，不同的人不同的理解。有的人認為是增加部分業務功能，或者基于場景的業務微服務集聚中心，也叫API Center，如用戶中心、訂單中心、產品中心等，也稱之為“業務中臺”。有的人認為中臺就是各種技術組件的堆積，如Spring Boot，Devops, 微服務開發框架，Docker等，也稱之為“技術中臺”。

要搞清楚中臺到底是什么，必須追本溯源，回歸初心。得從各類“中臺”概念中抽出來，以更高的視野和視角來看，虛擬主機，中臺到底能給企業帶來什么價值?

經過30年的信息化建設，制造業積累了無數的企業管理信息系統，如ERP, MES, PLM, SRM, CRM等。所有這些信息系統都是以流程驅動為核心，解決企業各類管理效率問題。經過多年的開發和建設，這些系統變得臃腫不堪，總結起來就是又慢又貴。就如下圖的大齒輪。

而隨著科學技術的發展，企業面臨的不確定性越來越高，產品復雜性逐步增加，生產過程復雜性逐步增強，客戶定制化需求逐步增多，供應鏈協同復雜性逐步增高。企業的競爭本質上演變為優化資源配置效率的競爭，或者理解為以數據服務業務化來響應瞬息萬變的市場變化。前臺應運而生，就如同下圖中的小齒輪，專注于小而美，快速創新迭代，快速響應用戶需求。內部用戶要訪問多個系統才能獲取諸如產品圖紙、 供應商信息、 庫存等數據，導致其無法快速變化和直接被使用，以支持前臺快速的創新需求。管理層也難以依據營銷、研發、制造、服務等各系統間大數據整合進行實時分析和決策洞察。

而這兩個不同速度齒輪的驅動就去需要一個耦合的齒輪：中臺。它可以快速聚合后臺的數據與能力，通過平臺的快速開發、分析、服務編排等能力，提供前臺更多的創新能力、試錯能力。

舉個例子：比如采購給供應商下發一張圖紙這個非常小場景。采購就得先學會PLM去搜索一張圖紙，同時要學會ERP去看看圖紙對應的原材料的庫存情況，甚至要學會使用SRM系統看一下供應商給的采購價格。簡單的一個場景，由于后臺系統的復雜性，以及部門的局限性導致數據無法形成及時性和協同性給終端用戶，也就是無法真正做到以用戶為中心。

如果一定要給一個定義，我愿意總結為：“中臺是一種思想，是一種體系”。這種思想主要是為了加速數據驅動價值的過程。

中臺與SOA/ESB的區別?

那中臺這個概念和我們以往企業在架構信息化系統過程中經常提到的SOA/ESB又有什么區別呢?

SOA更多的是一種軟件架構設計的模型和方法論，它的主要特性是面向服務的分布式計算，服務的重用，服務間松散耦合，支持服務的封裝，服務注冊和自動發現，以服務契約方式定義服務交互方式。

而ESB則更容易理解，它是中心化SOA的具體實現，主要是解決異構系統間整合的常見問題，比如服務連通、路由、消息豐富、服務的注冊/查找/發布等服務的管理、服務監控和質量保證等。

再回顧一下中臺，中臺是因前臺的敏捷性而生，是將后臺系統中需要被前臺調用業務能力、數據通過模型聚合的方式關聯到中臺，同時通過Service API的方式供前臺快速調用，以響應前臺的快速創新與變化，為前臺提供更強大的炮火支援。

SOA/ESB與中臺相比主要面向系統集成，項目實施平均成本高昂，牽涉大量的協同開發，無數據分析能力，面臨性能和擴展性的風險。無論從成本還是效率的角度，都體現了傳統項目建設方式帶來的業務迭代能力不足。