曾幾何時，中臺一度被當做“變革靈藥”，嫁接在“前臺作戰單元”和“後臺資源部門”之間，實現企業各業務線的“打通”和全域業務能力集成，提高開發和服務效率。但在中臺如火如荼之際，我們可以發現各大企業又在反其道而行，紛紛不斷進行“拆中臺”，那麼中臺對於企業而言，究竟發揮了哪些作用，當前又出現了哪些問題？今天，我們特邀了高級研發管理專家、騰訊雲 TVP 程超老師，他將從搭中臺到拆中臺的風向轉變，探討企業軟件架構的底層邏輯。
中臺都在忽悠嗎？都被忽悠瘸了？我們都在悄悄淘汰中臺，你們還在建？最近網上充斥大量文章和觀點，都在說中臺過時。爲什麼會這樣說？是因爲成本與複雜性？技術限制與業務變化？還是因爲組織變化？爲什麼會這樣呢？且聽我一一分析。
衆所周知，中臺是指企業內部的中間層平臺，負責連接上下游系統，提供數據和功能服務。而在過去幾年中臺概念曾經風靡一時，甚至被認爲是企業數字化轉型的關鍵。然而，近年來，一些企業確實出現了對中臺戰略的重新評估，不再像之前那樣盲目地追求中臺建設。其實，中臺的概念興起於企業數字化轉型的浪潮中，企業開始意識到傳統的前臺系統（如客戶端應用）與後臺系統（如企業資源規劃系統）之間的斷層，而中臺則被認爲是彌合這種斷層的理想方式。
值得一提的是，關於中臺的定義，業內大佬也曾經發表過一些觀點：
| 提煉各個業務條線的共性需求，並將這些打造成組件化的資源/能力包，然後以接口的形式提供給前臺各業務部門使用，這樣就可以最大限度地避免“重複造輪子”的問題，也讓每一個新的前臺業務創新能夠真正意義上“站在巨人的肩膀上”，而不用每次開闢一個新業務都像新建一家創業公司那麼艱難，甚或更爲艱難。——某企業資深架構師 鍾華 |
總結而言，中臺的核心點主要有以下三個：
- 中臺是爲前臺而生。
- 提煉各業務條線的共性需求。
- 減少“重複造輪子”的時間與資源浪費。
01四大層面解讀中臺備受追捧原因
2015年，業界首次提出“大中臺、小前臺”戰略，是想打造統一技術架構、產品支撐體系、數據共享平臺、安全體系等等，把整個組織“橫”過來，支撐多種多樣的業務形態。中臺似乎已經成爲行業標配，稍有規模的公司都建設了自己的中臺，掀起了一股強勁的中臺風。
中臺能夠解決哪些問題呢？在我看來，主要有以下四種：
- 項目重複造輪子嚴重，無法形成抽象共用
中臺提供了一種在企業內部建立統一的技術平臺或者服務平臺的模式。這個平臺可以被不同部門或者項目共享和複用，從而減少了重複開發的情況。隨着新業務的不斷接入，共享服務也從僅能提供單一的業務功能，不斷的自我進化成更健壯更強大的服務，不斷適應各種業務線的新需求。同時在數據積累方面，通過數據中臺將各業務的數據都沉澱下來，不斷地積累數據，發揮數據的最大威力。
- 業務變化快，緩慢的研發流程難以迅速響應
很多企業開發響應慢，其實大部分都是因爲數據問題，沒有做到實時、準確和統一。比如一家公司的訂單，分爲 C 端訂單，B 端訂單，共享單車訂單等等，這些訂單分管在不同部門中，想要做訂單統計、預測等就比較困難，各類型訂單彼此割裂，而如果企業只有一個訂單中心的話，數據就能夠在不同場景下感知到業務的變化和聯動。
- 提高資源利用率和研發效率
說起如何提高資源利用率和研發效率，我總結爲中颱建設五步法：插件化、服務化、配置化、異步化和數據化。這五步環環相扣，其中插件化就是提高研發效率的關鍵點，我們將對核心交易流程進行抽象建模設計，並通過流程引擎的改造，實現增加多個插件和擴展點。這樣，不同的業務場景可以根據需求自定義其個性化邏輯，將整個交易環節抽象爲一個流程框架，並在其基礎上引入一系列業務擴展。這種設計使得各業務間互不干擾，更靈活地滿足各自需求。
提高資源利用率，這也是必然的，服務、數據、組件等形成統一複用，各資源也不再分散，只需通過一套服務來做支撐，並且可以通過各業務線的忙閒情況，做資源的調控、比如某個業務線使用交易中臺服務，高峯時期是在早上8點到晚上12點，凌晨以後基本沒有業務量，則可以考慮把針對這個業務線的資源配置降低，從而實現降本增效。
- 提高系統穩定性和可靠性
一般來說系統的故障由三個方面引起，系統 bug、變更配置、併發流量變化。而技術中臺避免了各個部門爲解決自身技術問題而隨意修改系統設置和配置的情況，這樣做有助於防止整個系統因爲隨意修改而出現不穩定和安全問題。
02拆分中臺並非全盤否定中臺
前面我主要介紹了中臺能解決哪些問題，但其實很多企業在實際引入中臺的過程中，也遇到了很多問題：
- 中臺與前臺的邊界模糊
很多前臺的業務讓中臺接管開發，到底是接還是不接？中臺的角色和範圍缺乏明確界定，導致中臺與業務之間的責任劃分模糊不清，引發了重複建設、資源浪費和溝通成本等問題。
- 穩定性與靈活性的衝突
穩定與靈活一直是個矛盾體，中臺接入的業務線非常多，一旦出問題影響面巨大，代碼質量如何把控、上線流程如何穩定、業務如何做好隔離，都需要考慮清楚。
- 溝通障礙與目標差異
協調中臺團隊和業務團隊之間的溝通和合作，平衡雙方的需求和利益，以及處理中臺和業務之間的依賴和變更，都是一項複雜的管理任務。
- 中臺規劃與業務需求之間的平衡
中臺的服務需求和響應之間存在不匹配，這導致中臺無法滿足業務的多樣化和個性化需求。有時中臺過度迎合業務的短期需求，卻犧牲了其長期規劃和可持續發展。
- 利益分配
距離業務近的地方，比距離業務遠的地方更能得到公司增長的成果，中臺看似業務，其實只是沉澱，追求的是穩定和靈活。還有業務下沉的時候，會涉及到與中臺的業務交接，前臺業務必定會減少。如果是部門劃到中臺，是否會有人員變動？當中臺的服務價值和收益缺乏清晰界定，將難以有效衡量自身的貢獻和影響。
綜上，中臺看似很美好，但很多企業在實際落地的時候卻因爲遇到這些問題，導致陷入困境，中臺建設越建越複雜，甚至有些企業對中臺也逐漸失去了信心，反而成了阻礙企業發展的瓶頸。
近兩年業界開始風行“拆中臺”策略——將中臺變“薄”，拆分到多個獨立的業務單元。這使得很多企業又開始認爲中颱已成明日黃花，引進中臺並不是一個好選擇，甚至有些企業將自身發展不順的原因也歸在了中臺上面，一時間中臺被全盤否定了。
我個人則認爲拆分中臺並非全盤否定中臺，而是基於自身發展階段和市場環境的變化進行戰略調整和優化。“天下大事，合久必分，分久必合”，這就意味着在中臺的管理和戰略中，必須根據具體情況來做出分合的決策。有時候，將中臺進行分散管理或者分解成更小的部分可能更爲合適，因爲這樣有助於更好地滿足各個業務單位的需求，提高靈活性和適應性。互聯網大廠們將龐大而僵化的共享中臺重新組織爲靈活的業務域中臺，可以更好適應具體業務場景和用戶需求，既能保留中臺提供通用能力和協同效率的優勢，又能增加中臺的靈活性和個性化。
03企業應該因地制宜選擇是否需要中臺
首先，我想強調的是，“中臺”本身並不是一個新的架構思想，這個架構思想早在若干年以前就已經有了，很多企業已經是這麼做了，就像面向對象編程語言中（Java）高內聚，低耦合，便是這種思想。
當企業處在初創期，隨着業務發展產生多條業務線或產品線的時候，就會面臨協同方面的挑戰，如果每條業務線都要自己成立技術、運維、數據等部門，這樣顯然是非常浪費人力和資源的。爲了適應快速發展的業務，就需要成立中臺部門，來抽取、複用共性的東西，形成統一，這樣既能滿足“小前臺，大中臺”策略，讓業務快跑搶佔市場，中臺提供穩定的炮火支援，又能提高協同和研發效率。參考示意圖如下：
當企業已經渡過初創期，發展已經具有較大規模時，各條業務線人員和業務場景也比初創時更加龐大和複雜，企業了將面臨更加多樣化的市場，以及強大的響應能力，甚至每條業務線都要獨立去創新，這樣統一的中臺部門就會變成瓶頸，人員、響應時間、需求變化和溝通等都會成爲阻礙多樣化需求的絆腳石。這時候企業就需要根據市場需要，將龐大而僵化的大共享中臺，拆分到各業務單元中，將中臺下沉到各業務單元中，這樣既能保留中臺的通用和協同能力，又能針對具體業務和場景不斷增加靈活性和定製性。參考示意圖如下：
總而言之，中臺不是一直不變的，它需要根據市場需求不斷進化，演變成能夠滿足當前企業市場需要的形態。中臺不是萬能的，它只是企業數字化轉型的一種重要實現路徑，我們不能對中臺有過高的期望，而是應該理性地迴歸到企業數字化轉型的價值上來。
作者簡介
程超，騰訊雲 TVP，高級研發管理專家，14年 Java 研發經驗，8年技術管理和架構經驗，曾任京東架構師，易寶支付和松果出行架構技術負責人，熟悉支付和電商領域，擅長微服務生態建設和運維監控，對 Dubbo、Spring Cloud 和 gRPC 等微服務框架有深入研究，並應用於項目，幫助過多家公司進行過微服務建設和改造，目前正在建設業務中臺。 合著作品《深入分佈式緩存》和《高可用可伸縮微服務架構》，極客時間每日一課講師和出品人，CSDN 博主專家。