背景在 21 年，中臺拆分在 21 年，以下為中臺拆分的過程心得，帶有一定的主觀，偏向于中小團(tuán)隊中臺建設(shè)參考（這里的中小團(tuán)隊指 3-100 人的團(tuán)隊），對于大型團(tuán)隊不太適用，畢竟大型團(tuán)隊人中 / 技術(shù)充足。

前言

這里的中臺架構(gòu)不是平臺，也不是微服務(wù)，使用的是微服務(wù)架構(gòu)，這兩個是不一樣的概述。中臺建設(shè)開源項目 alinesno-cloud 開始，社區(qū)建議沉淀和企業(yè)實踐 3 年左右，于 21 年進(jìn)行拆分，指導(dǎo)思想為輕中臺，小前臺，大平臺，為了更適應(yīng)行業(yè)發(fā)展，更好的企業(yè)落地，整合出新中臺模型，每個企業(yè)中臺建設(shè)不一，這里針對的是自己帶隊建設(shè)過程，我有我思。

原中臺架構(gòu)是怎么樣的

中臺的概念很早接觸，前期從企業(yè)上云，再到 DevOps，技術(shù)中臺，研發(fā)中臺還有業(yè)務(wù)中臺的建設(shè)，中臺原帶有的架構(gòu)設(shè)計概念，更偏向于企業(yè)可復(fù)用的組件，多個業(yè)務(wù)線共用的服務(wù)，結(jié)合主流的微服務(wù)技術(shù)，包括 dubbo/cloud 體系 /k8s 容器化一系列的業(yè)務(wù)實踐，結(jié)合出來的中臺架構(gòu)，如下圖：

建設(shè)思想基于大中臺、小前臺指導(dǎo)，上面的架構(gòu)圖也是目前行業(yè)最常見的，也是原中臺的架構(gòu)和設(shè)計參考，也是解決了過程中的一部分問題，但是也帶來了新的問題產(chǎn)生，但總的來說，是進(jìn)步的，解決了傳統(tǒng)研發(fā)中的弊端，包括維護(hù)、升級、自動化、發(fā)布、版本更新、重復(fù)建設(shè)等等，對架構(gòu)的重構(gòu)，帶來新的企業(yè)機(jī)遇點(diǎn)。以下從幾個角度進(jìn)行闡述：

沉淀幾年過程中帶來的問題

為什么一定要拆分重構(gòu)

拆分過程是怎么升級處理

中臺要拆成什么最終形態(tài)

沉淀幾年過程中帶來的問題

中臺架構(gòu)解決了很多以前傳統(tǒng)項目開發(fā)的問題，使得研發(fā)過程整體變得自動化，中步也產(chǎn)生了一個新的問題：中臺太重。

維護(hù)中臺過程重

由于前期大量的微服務(wù)技術(shù)體系，多組件整合，架構(gòu)體系相對于一般的中小團(tuán)隊來說，已經(jīng)較為龐大，基于 gitlab 的管理，原有的業(yè)務(wù)組件不斷的增加能力，同時組件不斷增加，前期單一基線，源碼包由原來的十幾個工程，迅速變成上百個工程，幾百個組件，而且每一個業(yè)務(wù)項目的建設(shè)，就會增加新的中臺能力沉淀，當(dāng)然，這也是前期的初衷，也達(dá)到這個期望。

中臺越來越龐大，對于中臺團(tuán)隊來說，帶來另一個致命性的，組件的關(guān)聯(lián)性。南寧本地團(tuán)隊有一定的特點(diǎn)，一個是流動性，另一個是人員的培養(yǎng)性，這幾個帶來的問題，就是除了中臺小組的幾個人，其它人很難維護(hù)中臺，同時由于前期放在同一個基線，代碼量巨大，增加和修改功能，都需要極度的小心和避免影響項目，新人更加無從下手。工作量立桿見影的往上提升，甚至后面有些組件基本上不沉淀了，太多了無法維護(hù)。項目組開發(fā)過程中，出一個簡單的問題，找人找問題都很難，業(yè)務(wù)響應(yīng)速度下降，項目組不滿程度突顯。

前期通過招人，培養(yǎng)，文檔來解決，后來發(fā)現(xiàn)，這也是一個艱難的工作，特別是文檔，幾百個組件的文檔，對應(yīng)的文檔同步工作量也是龐大的，有很多陳舊的文檔跟新功能對不上，特意找了寫文檔的人，但是產(chǎn)出還是沒有達(dá)到預(yù)期。

另一個包括多項目，多版本，新舊版本維護(hù)等，這些維護(hù)過程來說，積累多，量也大。過程中不斷增加的中間件環(huán)境，整個中間件技術(shù)寬度就很大，技術(shù)鏈路越來越長。

基于以上種種，針對于中小團(tuán)隊來說，原來小組對中臺的管理，每個組件的升級管理，維護(hù)中臺過程較重。

團(tuán)隊成長技術(shù)債過重

中臺從基礎(chǔ)框架，技術(shù)平臺，研發(fā)中臺，數(shù)據(jù)中臺，還包括后期的智能平臺規(guī)劃，整體平臺的技術(shù)債過重。原有的技術(shù)體系超過 120 個技術(shù)框架或者工具，每一個技術(shù)點(diǎn)都要求研發(fā)人員擁有快速學(xué)習(xí)和掌握的能力，需要消耗大量的周期時間。

架構(gòu)體系更新太重

技術(shù)中臺和研發(fā)中臺的搭建，到后期的業(yè)務(wù)中臺整合，前期考慮到中小團(tuán)隊，形成統(tǒng)一技術(shù)路線，這相對來說是好的，同時也避免了各種框架的混亂。但是在后期，要升級的時候，這個問題就是另一個災(zāi)難了。

前期考慮多架構(gòu)融合，業(yè)務(wù)可選，在調(diào)整升級幾個版本之后，發(fā)現(xiàn)，新舊項目切合越來越難融合。

創(chuàng)新和升級受約束

中臺立于同一個基線的管理，同時過大的關(guān)聯(lián)性，在新的業(yè)務(wù)組件建設(shè)中，帶著沉重的中臺包袱，用還是不用中臺就成了一個問題，甚至有一些感覺雞肋。用了，后期在其它項目使用可能會帶著一連串的中臺組件，比如一個簡單的業(yè)務(wù)新組件，后來帶的是注冊中心，消息中心，緩存中心，還有 n 個關(guān)聯(lián)的中臺組件，甚至有可能找不清，鏈路過程找不到，去掉，發(fā)現(xiàn)有些工程又跑不起來，不去掉，又太重。過程需要討論，這過程無形中又消耗去時間。

另一個是單獨(dú)升級的組件的，可能無形中又影響其它引用的服務(wù)，考慮加版本，但是你根本就不清楚到底有哪些接入，無法確定是否升級，然后又需要討論，僅僅找到相應(yīng)的負(fù)責(zé)人確定方向，過程中無形又消耗時間周期，更可怕的是，前期的負(fù)責(zé)人可能自己都會遺忘前期的設(shè)計思路，或者負(fù)責(zé)這塊的人員已經(jīng)離職了。

為什么一定要拆分重構(gòu)

在長期的沉淀過程中，慢慢形成資產(chǎn)，但是也造成了隱形的約束。

產(chǎn)生強(qiáng)大的內(nèi)耗

內(nèi)耗跟消化過程有一定的區(qū)別，前期的團(tuán)隊的對中臺的理解和運(yùn)用，基本上已經(jīng)很熟悉，新人進(jìn)入，基本上一個星期內(nèi)就可以了解熟悉接入項目過程，這里的內(nèi)耗，指的更多的是團(tuán)隊對中臺的管理，圍繞中臺問題和管理上的消耗，這些基本上是無形的，開始基本上無感。

無形中產(chǎn)生的錯誤的架構(gòu)思維

中臺架構(gòu)的思維，無形中影響著很多項目開發(fā)人員，技術(shù)經(jīng)理，基本上內(nèi)部已經(jīng)形成約定的規(guī)范，照著上面的思維整合項目，項目無形中，也同步形成了很多組件，形成組件雖然是對的，但是由于架構(gòu)思維的偏差，形成的是大量重復(fù)的組件，這些組件的兼容性還有共性是比較大的，在進(jìn)行多個項目之后，會發(fā)現(xiàn)可能形成多套服務(wù)架構(gòu)。在這里多套也是沒有問題，重點(diǎn)的問題，這幾套的維護(hù)人員，支撐人員，還有管理人員等等都是分散的，業(yè)務(wù)也是分散的，這個一下就會形成無限的服務(wù)組件，甚至有可能是指數(shù)級的增長。

對于大型團(tuán)隊，比如上千人的團(tuán)隊來說，可能問題不大，但是對于中小團(tuán)隊來說，這幾乎是災(zāi)難性的，外加上人員流動緣故，另一個是地方人才等問題，可能很快就會變成團(tuán)隊壓力負(fù)擔(dān)，最后產(chǎn)生一個疑問，還要不要使用這個技術(shù)中臺。

制約企業(yè)戰(zhàn)略規(guī)劃

前期中臺架構(gòu)，過分依賴于技術(shù)組件的復(fù)用性，偏向于技術(shù)體系，沒有能從解決方案思維架構(gòu)上的整合，無法跟進(jìn)當(dāng)前行業(yè)的發(fā)展。

中臺的建設(shè)，團(tuán)隊的消化，項目的接入，業(yè)務(wù)的維護(hù)過程，整個下來，中小團(tuán)隊少的可能 1 年，重的可能 3-5 年，這個過程基本上團(tuán)隊沒有精力再思考其它，對一般的企業(yè)來說，有限的資源力量，就無形中成為一種制約。

拆分過程是怎么升級處理

拆分思維從大中臺，小前臺，轉(zhuǎn)變成輕中臺，小前臺，大平臺架構(gòu)指導(dǎo)。

中臺怎么拆

一個基線的拆分，每個組件針對顆粒度形成一個單獨(dú)的管理基線，同時明確中臺的管理邊界，哪些可集成，哪些不可集成，哪些需要放棄，哪些需要重點(diǎn)建設(shè)，進(jìn)行重點(diǎn)精度升級，在架構(gòu)上形成邊界。

明確中臺版本的管理，穩(wěn)定版本的管理，一定確定出穩(wěn)定版，同時劃分明確中臺組基線的管理范圍，中臺組件范圍，非團(tuán)隊或者企業(yè)核心組件，不做整合，做好分界線。

明確上下游關(guān)系，每個組件提供標(biāo)準(zhǔn)穩(wěn)定接口，明確上下游組件，另一個是提取出核心業(yè)務(wù)領(lǐng)域，面向接口編程，如下圖：

這樣無論外圍技術(shù)升級和劃分，核心業(yè)務(wù)領(lǐng)域盡量少動，切換的是領(lǐng)域外圍，形成穩(wěn)定的企業(yè)核心資產(chǎn)和版本，同時避免技術(shù)升級帶來的核心業(yè)務(wù)代碼變動。

去掉非通用協(xié)議，當(dāng)然，也可以不去掉，主要看技術(shù)債和團(tuán)隊問題，針對于我們團(tuán)隊，當(dāng)時直接全量升級，從 RPC 協(xié)議調(diào)整成 Http 協(xié)議，如果是 cloud 技術(shù)，這個問題就可以免掉了。

后期怎么升級維護(hù)

基于中臺服務(wù)的拆分，各個業(yè)務(wù)組件和服務(wù)，都有可能變成一個單獨(dú)的業(yè)務(wù)線，在設(shè)計和方案，還有新技術(shù)的增加上面，新需求新市場變動變動上面，變得相當(dāng)?shù)妮p量，不再需要關(guān)心過多的中臺包袱，開發(fā)人員的思維和思緒更偏向于這個組件的完善上面。

每個服務(wù)的架構(gòu)和變動上面，就會變得很輕量，升級維護(hù)可以根據(jù)每個組件和負(fù)責(zé)人不同方案，進(jìn)行最合適的升級處理。需要添加的服務(wù)和模塊，就不再是有累贅，過程的指導(dǎo)由中臺運(yùn)營手冊去做管理指導(dǎo)，形成輕量級的公共組件和服務(wù)。

提供出來的接口和服務(wù)，在不影響其它人的引用即可，同時做好前后兼容即可，側(cè)面增大了 k 中臺服務(wù)組件的包容性，通過中臺定制的管理運(yùn)營規(guī)范，按一般的 java 項目管理維護(hù)即可，這里就不再過多闡述。

中臺要拆成什么結(jié)果形態(tài)

這里的形態(tài)，整個過程由單體到服務(wù)化，再到微服務(wù)，大中臺小前臺，再到進(jìn)一步升級的結(jié)果形態(tài)。

基于新中臺模型架構(gòu)

中臺包括很多層面，不僅僅是技術(shù)，更多的是業(yè)務(wù)的掛鉤，不僅僅是技術(shù)的改變，更多是模式的改變，比如規(guī)劃、產(chǎn)品、沉淀、落地、資源整合等一套體系，而不是說，我們就做那么個框架或是技術(shù)平臺，而是一個更高一層的思想架構(gòu)提升，這里定義的新中臺的模型包括以下幾點(diǎn)：

產(chǎn)品：企業(yè)團(tuán)隊沉淀能力體現(xiàn)

解決方案：客戶業(yè)務(wù)價值體現(xiàn)

組織架構(gòu)：價值落地的保障體現(xiàn)

技術(shù)：技術(shù)是落地的直接能力輸出

合作體系：業(yè)務(wù)發(fā)展能力體現(xiàn)

沉淀：發(fā)展和突破點(diǎn)積累體現(xiàn)

結(jié)合上面的新中臺闡述落地體系，從幾個角度思考愿景方向和發(fā)展走向形勢參考，主要思考的幾個點(diǎn)：

新解決方案：業(yè)務(wù)價值能力輸出

新服務(wù)模式：客戶業(yè)務(wù)價值輸出

新發(fā)展模式：S2B 商業(yè)模式輸出

從整體上表述新中臺的模型和愿景方向，也是數(shù)字化社區(qū)的目標(biāo)和愿景，整體愿景期望的已不僅僅是數(shù)字化，更多的是以數(shù)字化為基礎(chǔ)，進(jìn)行更好的發(fā)展方向。

行業(yè)產(chǎn)品形態(tài)能力輸出

行業(yè)模式，不僅僅是目前的業(yè)務(wù)維護(hù)，更多的是基于新中臺架構(gòu)行業(yè)發(fā)展地位和企業(yè)發(fā)展的基礎(chǔ)。

相應(yīng)的市面上產(chǎn)品示例門戶體現(xiàn)參考：

釘釘門戶

金蝶云蒼穹門戶

總結(jié)

以上為中臺拆分過程的一些過程和思路，每個架構(gòu)師或者技術(shù)負(fù)責(zé)人有自己的思路，上面是自己在整合過程的總結(jié)。