背景在 21 年摄咆，中臺拆分在 21 年凡蚜，以下為中臺拆分的過程心得，帶有一定的主觀豆同，偏向于中小團隊中臺建設參考（這里的中小團隊指 3-100 人的團隊）番刊，對于大型團隊不太適用，畢竟大型團隊人中 / 技術充足影锈。

前言

這里的中臺架構不是平臺芹务，也不是微服務，使用的是微服務架構鸭廷，這兩個是不一樣的概述枣抱。中臺建設開源項目 alinesno-cloud 開始，社區(qū)建議沉淀和企業(yè)實踐 3 年左右辆床，于 21 年進行拆分佳晶，指導思想為輕中臺，小前臺讼载，大平臺轿秧，為了更適應行業(yè)發(fā)展，更好的企業(yè)落地咨堤，整合出新中臺模型菇篡，每個企業(yè)中臺建設不一，這里針對的是自己帶隊建設過程一喘，我有我思驱还。

原中臺架構是怎么樣的

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

建設思想基于大中臺享郊、小前臺指導览祖，上面的架構圖也是目前行業(yè)最常見的，也是原中臺的架構和設計參考炊琉，也是解決了過程中的一部分問題展蒂，但是也帶來了新的問題產(chǎn)生，但總的來說苔咪，是進步的锰悼，解決了傳統(tǒng)研發(fā)中的弊端，包括維護团赏、升級箕般、自動化、發(fā)布舔清、版本更新丝里、重復建設等等，對架構的重構体谒，帶來新的企業(yè)機遇點杯聚。以下從幾個角度進行闡述：

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

為什么一定要拆分重構

拆分過程是怎么升級處理

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

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

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

維護中臺過程重

由于前期大量的微服務技術體系，多組件整合故响，架構體系相對于一般的中小團隊來說傀广，已經(jīng)較為龐大，基于 gitlab 的管理彩届，原有的業(yè)務組件不斷的增加能力伪冰，同時組件不斷增加，前期單一基線惨缆，源碼包由原來的十幾個工程糜值，迅速變成上百個工程，幾百個組件坯墨，而且每一個業(yè)務項目的建設寂汇，就會增加新的中臺能力沉淀，當然捣染，這也是前期的初衷骄瓣，也達到這個期望。

中臺越來越龐大耍攘，對于中臺團隊來說榕栏，帶來另一個致命性的，組件的關聯(lián)性蕾各。南寧本地團隊有一定的特點扒磁，一個是流動性，另一個是人員的培養(yǎng)性式曲，這幾個帶來的問題妨托，就是除了中臺小組的幾個人，其它人很難維護中臺吝羞，同時由于前期放在同一個基線兰伤，代碼量巨大，增加和修改功能钧排，都需要極度的小心和避免影響項目敦腔，新人更加無從下手。工作量立桿見影的往上提升恨溜，甚至后面有些組件基本上不沉淀了符衔，太多了無法維護。項目組開發(fā)過程中糟袁，出一個簡單的問題柏腻，找人找問題都很難，業(yè)務響應速度下降系吭，項目組不滿程度突顯五嫂。

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

另一個包括多項目晰洒，多版本朝抖，新舊版本維護等，這些維護過程來說谍珊，積累多治宣，量也大。過程中不斷增加的中間件環(huán)境砌滞，整個中間件技術寬度就很大侮邀，技術鏈路越來越長。

基于以上種種贝润，針對于中小團隊來說绊茧，原來小組對中臺的管理，每個組件的升級管理打掘，維護中臺過程較重按傅。

團隊成長技術債過重

中臺從基礎框架，技術平臺胧卤，研發(fā)中臺唯绍，數(shù)據(jù)中臺，還包括后期的智能平臺規(guī)劃枝誊，整體平臺的技術債過重况芒。原有的技術體系超過 120 個技術框架或者工具，每一個技術點都要求研發(fā)人員擁有快速學習和掌握的能力叶撒，需要消耗大量的周期時間绝骚。

架構體系更新太重

技術中臺和研發(fā)中臺的搭建，到后期的業(yè)務中臺整合祠够，前期考慮到中小團隊压汪，形成統(tǒng)一技術路線，這相對來說是好的古瓤，同時也避免了各種框架的混亂止剖。但是在后期，要升級的時候落君，這個問題就是另一個災難了穿香。

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

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

中臺立于同一個基線的管理洒宝，同時過大的關聯(lián)性购公，在新的業(yè)務組件建設中，帶著沉重的中臺包袱雁歌，用還是不用中臺就成了一個問題宏浩，甚至有一些感覺雞肋。用了将宪，后期在其它項目使用可能會帶著一連串的中臺組件，比如一個簡單的業(yè)務新組件橡庞，后來帶的是注冊中心较坛，消息中心，緩存中心扒最，還有 n 個關聯(lián)的中臺組件丑勤，甚至有可能找不清，鏈路過程找不到吧趣，去掉法竞，發(fā)現(xiàn)有些工程又跑不起來，不去掉强挫，又太重岔霸。過程需要討論，這過程無形中又消耗去時間俯渤。

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

為什么一定要拆分重構

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

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

內(nèi)耗跟消化過程有一定的區(qū)別厌处，前期的團隊的對中臺的理解和運用鳖谈，基本上已經(jīng)很熟悉尾序，新人進入多矮，基本上一個星期內(nèi)就可以了解熟悉接入項目過程捧存，這里的內(nèi)耗懦铺，指的更多的是團隊對中臺的管理，圍繞中臺問題和管理上的消耗贯要，這些基本上是無形的暖侨，開始基本上無感。

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

中臺架構的思維崇渗，無形中影響著很多項目開發(fā)人員字逗，技術經(jīng)理，基本上內(nèi)部已經(jīng)形成約定的規(guī)范宅广，照著上面的思維整合項目葫掉，項目無形中，也同步形成了很多組件跟狱，形成組件雖然是對的俭厚，但是由于架構思維的偏差，形成的是大量重復的組件驶臊，這些組件的兼容性還有共性是比較大的挪挤，在進行多個項目之后，會發(fā)現(xiàn)可能形成多套服務架構关翎。在這里多套也是沒有問題扛门，重點的問題，這幾套的維護人員纵寝，支撐人員尖飞，還有管理人員等等都是分散的，業(yè)務也是分散的店雅，這個一下就會形成無限的服務組件政基，甚至有可能是指數(shù)級的增長。

對于大型團隊闹啦，比如上千人的團隊來說沮明，可能問題不大，但是對于中小團隊來說窍奋，這幾乎是災難性的荐健，外加上人員流動緣故，另一個是地方人才等問題琳袄，可能很快就會變成團隊壓力負擔江场，最后產(chǎn)生一個疑問，還要不要使用這個技術中臺窖逗。

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

前期中臺架構址否，過分依賴于技術組件的復用性，偏向于技術體系碎紊，沒有能從解決方案思維架構上的整合佑附，無法跟進當前行業(yè)的發(fā)展樊诺。

中臺的建設，團隊的消化音同，項目的接入词爬，業(yè)務的維護過程，整個下來权均，中小團隊少的可能 1 年顿膨，重的可能 3-5 年，這個過程基本上團隊沒有精力再思考其它叽赊，對一般的企業(yè)來說恋沃，有限的資源力量，就無形中成為一種制約蛇尚。

拆分過程是怎么升級處理

拆分思維從大中臺芽唇，小前臺顾画，轉(zhuǎn)變成輕中臺取劫，小前臺，大平臺架構指導研侣。

中臺怎么拆

一個基線的拆分谱邪，每個組件針對顆粒度形成一個單獨的管理基線，同時明確中臺的管理邊界庶诡，哪些可集成惦银，哪些不可集成，哪些需要放棄末誓，哪些需要重點建設扯俱，進行重點精度升級，在架構上形成邊界喇澡。

明確中臺版本的管理迅栅，穩(wěn)定版本的管理，一定確定出穩(wěn)定版晴玖，同時劃分明確中臺組基線的管理范圍读存，中臺組件范圍，非團隊或者企業(yè)核心組件呕屎，不做整合让簿，做好分界線。

明確上下游關系秀睛，每個組件提供標準穩(wěn)定接口尔当，明確上下游組件，另一個是提取出核心業(yè)務領域蹂安，面向接口編程居凶，如下圖：

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

去掉非通用協(xié)議弄兜，當然药蜻，也可以不去掉，主要看技術債和團隊問題替饿，針對于我們團隊语泽，當時直接全量升級，從 RPC 協(xié)議調(diào)整成 Http 協(xié)議视卢，如果是 cloud 技術踱卵，這個問題就可以免掉了。

后期怎么升級維護

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

每個服務的架構和變動上面原朝，就會變得很輕量驯嘱，升級維護可以根據(jù)每個組件和負責人不同方案，進行最合適的升級處理喳坠。需要添加的服務和模塊鞠评，就不再是有累贅，過程的指導由中臺運營手冊去做管理指導丙笋，形成輕量級的公共組件和服務谢澈。

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

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

這里的形態(tài)，整個過程由單體到服務化钉答，再到微服務础芍，大中臺小前臺，再到進一步升級的結(jié)果形態(tài)数尿。

基于新中臺模型架構

中臺包括很多層面仑性，不僅僅是技術，更多的是業(yè)務的掛鉤右蹦，不僅僅是技術的改變诊杆，更多是模式的改變，比如規(guī)劃何陆、產(chǎn)品晨汹、沉淀、落地贷盲、資源整合等一套體系淘这，而不是說，我們就做那么個框架或是技術平臺巩剖，而是一個更高一層的思想架構提升铝穷，這里定義的新中臺的模型包括以下幾點：

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

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

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

技術：技術是落地的直接能力輸出

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

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

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

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

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

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

從整體上表述新中臺的模型和愿景方向呻疹，也是數(shù)字化社區(qū)的目標和愿景吃引，整體愿景期望的已不僅僅是數(shù)字化刽锤，更多的是以數(shù)字化為基礎，進行更好的發(fā)展方向并思。

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

行業(yè)模式，不僅僅是目前的業(yè)務維護宋彼，更多的是基于新中臺架構行業(yè)發(fā)展地位和企業(yè)發(fā)展的基礎。

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

釘釘門戶

金蝶云蒼穹門戶

總結(jié)

以上為中臺拆分過程的一些過程和思路输涕，每個架構師或者技術負責人有自己的思路，上面是自己在整合過程的總結(jié)莱坎。