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