我把整個研發中臺拆分過程的一些心得總結

語言: CN / TW / HK

背景在21年,中臺拆分在21年,以下為中颱拆分的過程心得,帶有一定的主觀,偏向於中小團隊中臺建設參考(這裡的中小團隊指3-100人的團隊),對於大型團隊不太適用,畢竟大型團隊人中/技術充足。

前言

這裡的中臺架構不是平臺,也不是微服務,使用的是微服務架構,這兩個是不一樣的概述。中臺建設開源專案alinesno-cloud開始,社群建議沉澱和企業實踐3年左右,於21年進行拆分,指導思想為輕中臺,小前臺,大平臺,為了更適應行業發展,更好的企業落地,整合出新中臺模型,每個企業中臺建設不一,這裡針對的是自己帶隊建設過程,我有我思。

原中臺架構是怎麼樣的

中臺的概念很早接觸,前期從企業上雲,再到DevOps,技術中臺,研發中臺還有業務中臺的建設,中臺原帶有的架構設計概念,更偏向於企業可複用的元件,多個業務線共用的服務,結合主流的微服務技術,包括dubbo/cloud體系/k8s容器化一系列的業務實踐,結合出來的中臺架構,如下圖:

建設思想基於大中臺、小前臺指導,上面的架構圖也是目前行業最常見的,也是原中臺的架構和設計參考,也是解決了過程中的一部分問題,但是也帶來了新的問題產生,但總的來說,是進步的,解決了傳統研發中的弊端,包括維護、升級、自動化、釋出、版本更新、重複建設等等,對架構的重構,帶來新的企業機遇點。以下從幾個角度進行闡述:

  • 沉澱幾年過程中帶來的問題
  • 為什麼一定要拆分重構
  • 拆分過程是怎麼升級處理
  • 中臺要拆成什麼最終形態

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

中臺架構解決了很多以前傳統專案開發的問題,使得研發過程整體變得自動化,中步也產生了一個新的問題:中臺太重。

維護中臺過程重

由於前期大量的微服務技術體系,多元件整合,架構體系相對於一般的中小團隊來說,已經較為龐大,基於gitlab的管理,原有的業務元件不斷的增加能力,同時元件不斷增加,前期單一基線,原始碼包由原來的十幾個工程,迅速變成上百個工程,幾百個元件,而且每一個業務專案的建設,就會增加新的中臺能力沉澱,當然,這也是前期的初衷,也達到這個期望。

中臺越來越龐大,對於中臺團隊來說,帶來另一個致命性的,元件的關聯性。南寧本地團隊有一定的特點,一個是流動性,另一個是人員的培養性,這幾個帶來的問題,就是除了中臺小組的幾個人,其它人很難維護中臺,同時由於前期放在同一個基線,程式碼量巨大,增加和修改功能,都需要極度的小心和避免影響專案,新人更加無從下手。工作量立杆見影的往上提升,甚至後面有些元件基本上不沉澱了,太多了無法維護。專案組開發過程中,出一個簡單的問題,找人找問題都很難,業務響應速度下降,專案組不滿程度突顯。

前期通過招人,培養,文件來解決,後來發現,這也是一個艱難的工作,特別是文件,幾百個元件的文件,對應的文件同步工作量也是龐大的,有很多陳舊的文件跟新功能對不上,特意找了寫文件的人,但是產出還是沒有達到預期。

另一個包括多專案,多版本,新舊版本維護等,這些維護過程來說,積累多,量也大。過程中不斷增加的中介軟體環境,整個中介軟體技術寬度就很大,技術鏈路越來越長。

基於以上種種,針對於中小團隊來說,原來小組對中臺的管理,每個元件的升級管理,維護中臺過程較重。

團隊成長技術債過重

中臺從基礎框架,技術平臺,研發中臺,資料中臺,還包括後期的智慧平臺規劃,整體平臺的技術債過重。原有的技術體系超過120個技術框架或者工具,每一個技術點都要求研發人員擁有快速學習和掌握的能力,需要消耗大量的週期時間。

架構體系更新太重

技術中臺和研發中臺的搭建,到後期的業務中臺整合,前期考慮到中小團隊,形成統一技術路線,這相對來說是好的,同時也避免了各種框架的混亂。但是在後期,要升級的時候,這個問題就是另一個災難了。

前期考慮多架構融合,業務可選,在調整升級幾個版本之後,發現,新舊專案切合越來越難融合。

創新和升級受約束

中臺立於同一個基線的管理,同時過大的關聯性,在新的業務元件建設中,帶著沉重的中臺包袱,用還是不用中臺就成了一個問題,甚至有一些感覺雞肋。用了,後期在其它專案使用可能會帶著一連串的中臺元件,比如一個簡單的業務新元件,後來帶的是註冊中心,訊息中心,快取中心,還有n個關聯的中臺元件,甚至有可能找不清,鏈路過程找不到,去掉,發現有些工程又跑不起來,不去掉,又太重。過程需要討論,這過程無形中又消耗去時間。

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

為什麼一定要拆分重構

在長期的沉澱過程中,慢慢形成資產,但是也造成了隱形的約束。

產生強大的內耗

內耗跟消化過程有一定的區別,前期的團隊的對中臺的理解和運用,基本上已經很熟悉,新人進入,基本上一個星期內就可以瞭解熟悉接入專案過程,這裡的內耗,指的更多的是團隊對中臺的管理,圍繞中臺問題和管理上的消耗,這些基本上是無形的,開始基本上無感。

無形中產生的錯誤的架構思維

中臺架構的思維,無形中影響著很多專案開發人員,技術經理,基本上內部已經形成約定的規範,照著上面的思維整合專案,專案無形中,也同步形成了很多元件,形成元件雖然是對的,但是由於架構思維的偏差,形成的是大量重複的元件,這些元件的相容性還有共性是比較大的,在進行多個專案之後,會發現可能形成多套服務架構。在這裡多套也是沒有問題,重點的問題,這幾套的維護人員,支撐人員,還有管理人員等等都是分散的,業務也是分散的,這個一下就會形成無限的服務元件,甚至有可能是指數級的增長。

對於大型團隊,比如上千人的團隊來說,可能問題不大,但是對於中小團隊來說,這幾乎是災難性的,外加上人員流動緣故,另一個是地方人才等問題,可能很快就會變成團隊壓力負擔,最後產生一個疑問,還要不要使用這個技術中臺。

制約企業戰略規劃

前期中臺架構,過分依賴於技術元件的複用性,偏向於技術體系,沒有能從解決方案思維架構上的整合,無法跟進當前行業的發展。

中臺的建設,團隊的消化,專案的接入,業務的維護過程,整個下來,中小團隊少的可能1年,重的可能3-5年,這個過程基本上團隊沒有精力再思考其它,對一般的企業來說,有限的資源力量,就無形中成為一種制約。

拆分過程是怎麼升級處理

拆分思維從大中臺,小前臺,轉變成輕中臺,小前臺,大平臺架構指導。

中臺怎麼拆

一個基線的拆分,每個元件針對顆粒度形成一個單獨的管理基線,同時明確中臺的管理邊界,哪些可整合,哪些不可整合,哪些需要放棄,哪些需要重點建設,進行重點精度升級,在架構上形成邊界。

明確中臺版本的管理,穩定版本的管理,一定確定出穩定版,同時劃分明確中臺組基線的管理範圍,中臺元件範圍,非團隊或者企業核心元件,不做整合,做好分界線。

明確上下游關係,每個元件提供標準穩定介面,明確上下游元件,另一個是提取出核心業務領域,面向介面程式設計,如下圖:

這樣無論外圍技術升級和劃分,核心業務領域儘量少動,切換的是領域外圍,形成穩定的企業核心資產和版本,同時避免技術升級帶來的核心業務程式碼變動。

去掉非通用協議,當然,也可以不去掉,主要看技術債和團隊問題,針對於我們團隊,當時直接全量升級,從RPC協議調整成Http協議,如果是cloud技術,這個問題就可以免掉了。

後期怎麼升級維護

基於中臺服務的拆分,各個業務元件和服務,都有可能變成一個單獨的業務線,在設計和方案,還有新技術的增加上面,新需求新市場變動變動上面,變得相當的輕量,不再需要關心過多的中臺包袱,開發人員的思維和思緒更偏向於這個元件的完善上面。

每個服務的架構和變動上面,就會變得很輕量,升級維護可以根據每個元件和負責人不同方案,進行最合適的升級處理。需要新增的服務和模組,就不再是有累贅,過程的指導由中臺運營手冊去做管理指導,形成輕量級的公共元件和服務。

提供出來的介面和服務,在不影響其它人的引用即可,同時做好前後相容即可,側面增大了k 中臺服務元件的包容性,通過中臺定製的管理運營規範,按一般的java專案管理維護即可,這裡就不再過多闡述。

中臺要拆成什麼結果形態

這裡的形態,整個過程由單體到服務化,再到微服務,大中臺小前臺,再到進一步升級的結果形態。

基於新中臺模型架構

中臺包括很多層面,不僅僅是技術,更多的是業務的掛鉤,不僅僅是技術的改變,更多是模式的改變,比如規劃、產品、沉澱、落地、資源整合等一套體系,而不是說,我們就做那麼個框架或是技術平臺,而是一個更高一層的思想架構提升,這裡定義的新中臺的模型包括以下幾點:

  • 產品:企業團隊沉澱能力體現
  • 解決方案:客戶業務價值體現
  • 組織架構:價值落地的保障體現
  • 技術:技術是落地的直接能力輸出
  • 合作體系:業務發展能力體現
  • 沉澱:發展和突破點積累體現

結合上面的新中臺闡述落地體系,從幾個角度思考願景方向和發展走向形勢參考,主要思考的幾個點:

  • 新解決方案:業務價值能力輸出
  • 新服務模式:客戶業務價值輸出
  • 新發展模式:S2B 商業模式輸出

從整體上表述新中臺的模型和願景方向,也是數字化社群的目標和願景,整體願景期望的已不僅僅是數字化,更多的是以數字化為基礎,進行更好的發展方向。

行業產品形態能力輸出

行業模式,不僅僅是目前的業務維護,更多的是基於新中臺架構行業發展地位和企業發展的基礎。

相應的市面上產品示例門戶體現參考:

  • 釘釘門戶
  • 金蝶雲蒼穹門戶

總結

以上為中颱拆分過程的一些過程和思路,每個架構師或者技術負責人有自己的思路,上面是自己在整合過程的總結。