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

前言

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

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

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

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

• 沉淀幾年過(guò)程中帶來(lái)的問(wèn)題
• 為什么一定要拆分重構(gòu)
• 拆分過(guò)程是怎么升級(jí)處理
• 中臺(tái)要拆成什么最終形態(tài)

沉淀幾年過(guò)程中帶來(lái)的問(wèn)題

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

維護(hù)中臺(tái)過(guò)程重

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

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

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

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

基于以上種種，針對(duì)于中小團(tuán)隊(duì)來(lái)說(shuō)，原來(lái)小組對(duì)中臺(tái)的管理，每個(gè)組件的升級(jí)管理，維護(hù)中臺(tái)過(guò)程較重。

團(tuán)隊(duì)成長(zhǎng)技術(shù)債過(guò)重

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拆分過(guò)程是怎么升級(jí)處理

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

中臺(tái)怎么拆

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

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

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

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

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

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

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

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

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

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

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

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

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

• 產(chǎn)品：企業(yè)團(tuán)隊(duì)沉淀能力體現(xiàn)
• 解決方案：客戶業(yè)務(wù)價(jià)值體現(xiàn)
• 組織架構(gòu)：價(jià)值落地的保障體現(xiàn)
• 技術(shù)：技術(shù)是落地的直接能力輸出
• 合作體系：業(yè)務(wù)發(fā)展能力體現(xiàn)
• 沉淀：發(fā)展和突破點(diǎn)積累體現(xiàn)

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

• 新解決方案：業(yè)務(wù)價(jià)值能力輸出
• 新服務(wù)模式：客戶業(yè)務(wù)價(jià)值輸出
• 新發(fā)展模式：S2B 商業(yè)模式輸出

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

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

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

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

• 釘釘門(mén)戶
• 金蝶云蒼穹門(mén)戶

總結(jié)

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