概述

從傳統(tǒng)業(yè)務(wù)架構(gòu)的服務(wù)器發(fā)布，同時也包括項目管理開發(fā)流程，再到傳統(tǒng)的項目管理運維等進(jìn)行架構(gòu)升級，升級為業(yè)務(wù)中臺架構(gòu)，為下一步數(shù)據(jù)運營管理做好基礎(chǔ)。升級過程從團(tuán)隊、專家、業(yè)務(wù)、架構(gòu)等幾個維護(hù)進(jìn)行的調(diào)整，以適應(yīng)當(dāng)前IT行業(yè)的發(fā)展和數(shù)字化市場環(huán)境，在這個升級的過程不僅僅是技術(shù)項目的升級，更多的是組織架構(gòu)，團(tuán)隊技能的升級，以消除前期傳統(tǒng)模式留下的弊端。

升級過程闡述分三個維護(hù)，主要升級的成果點：

• 傳統(tǒng)系統(tǒng)架構(gòu)升級中臺系統(tǒng)架構(gòu)模式，即提取業(yè)務(wù)中臺，大中臺，小前臺模式

• 管理模式轉(zhuǎn)換成中臺組織架構(gòu)模式，即中臺專家支持，業(yè)務(wù)兵團(tuán)走前端

• 軟件項目開發(fā)轉(zhuǎn)換成行業(yè)產(chǎn)品型研發(fā)，即輸出項目的同時輸出中臺產(chǎn)品型服務(wù)

• 傳統(tǒng)的運維模式升級成自動化運維模式，即全方面的運維監(jiān)控體系，可自動化可預(yù)警

按前期-中期-后期三個時間段時間段。

#升級方案架構(gòu)

研發(fā)模式升級改造和業(yè)務(wù)中臺架構(gòu)，升級后方案如下：

#升級過程

中臺型的轉(zhuǎn)變需要整體團(tuán)隊的互相配合。每個節(jié)點做好自己的事情，需要上下一心的轉(zhuǎn)變，領(lǐng)導(dǎo)層的意識和可行性的架構(gòu)能力的支撐。

#前期

前期最主要的還是團(tuán)隊的意識，這里的團(tuán)隊包括的不僅僅是一個組，而是整個團(tuán)隊的上下意識，這個過程調(diào)整了組織結(jié)構(gòu)，這基本上將原有的項目管理模式歸由研發(fā)部進(jìn)行整體指導(dǎo)，主要是：

• 調(diào)整組織結(jié)構(gòu)，技術(shù)支撐下沉到研發(fā)部;

• 技術(shù)架構(gòu)重構(gòu)，進(jìn)行二次架構(gòu)的升級，形成全體升級轉(zhuǎn)變的指導(dǎo)思想

• 將升級戰(zhàn)略上升到團(tuán)隊最高層面，思想意識統(tǒng)一

以上兩步基本上解決了執(zhí)行的基礎(chǔ)保障，也是中臺架構(gòu)的基礎(chǔ)保障條件。

架構(gòu)升級的前期遇到的最突出的問題，舊系統(tǒng)的切換，這是一個矛盾點，在不違背團(tuán)隊過大的意愿下，調(diào)整的架構(gòu)設(shè)計，當(dāng)中也做了很多妥協(xié)，另一個是犧牲一部分技術(shù)妥協(xié)團(tuán)隊的接受，一步步推進(jìn)。從上而下的業(yè)務(wù)模式改變，主要包括幾個點：

• 虛擬機(jī)轉(zhuǎn)變成k8s容器化，升級虛擬機(jī)配置，減少服務(wù)器數(shù)量

• 發(fā)布過程集成docker容器化，同時調(diào)整最小配置，減少大家的學(xué)習(xí)成本

• 流量的切入轉(zhuǎn)換成對外nodeport的形式（rpc協(xié)議）

• 服務(wù)化設(shè)計保留原來的基礎(chǔ)工程結(jié)構(gòu)，業(yè)務(wù)集成CICD還有服務(wù)調(diào)用模式

上面幾步基本上解決了基礎(chǔ)層的問題點，還有過程持續(xù)構(gòu)建的弊端點，資源不穩(wěn)定點等。

#中前期

基礎(chǔ)層的解決和保障，最終還是回到業(yè)務(wù)建設(shè)上。

最可能出現(xiàn)問題的一點和沉淀能力的抽取考慮上，原業(yè)務(wù)架構(gòu)，比如原來就沒有考慮到這樣的方式，進(jìn)行的項目還有工程研發(fā)等，這個基本上最有可能導(dǎo)致后期上線不穩(wěn)定的因素，做了幾點：

• 培養(yǎng)和完善手冊，還有培訓(xùn)機(jī)制，將各個責(zé)任點下放

• 保留原服務(wù)工程的調(diào)用機(jī)制，盡量在k8s上進(jìn)行妥協(xié)和解決問題，實在不行的再調(diào)整業(yè)務(wù)代碼；

• 完善運維機(jī)制和監(jiān)控機(jī)制，原有的業(yè)務(wù)排查方式和發(fā)布式的轉(zhuǎn)變

• 多層面上進(jìn)行運維角度的整合，包括系統(tǒng)、日志、鏈路、流量、灰度等多個層面的保障

• 去掉一些不可控的業(yè)務(wù)節(jié)點，保留原運行模式，規(guī)避各類安全策略的問題，這也是一個妥協(xié)點

• 業(yè)務(wù)服務(wù)抽取可形成產(chǎn)品模塊，此從業(yè)務(wù)層面進(jìn)行妥協(xié)，調(diào)整代碼和項目結(jié)構(gòu)

• 多處運用消息機(jī)制，進(jìn)行業(yè)務(wù)模塊的解耦和可產(chǎn)品化調(diào)整，此也從業(yè)務(wù)層面上進(jìn)行妥協(xié)

基于以上多種結(jié)構(gòu)的調(diào)整，完成業(yè)務(wù)中臺架構(gòu)的雛形,在有項目的推進(jìn)。

#中期

此階段有可能產(chǎn)生風(fēng)暴期，項目總監(jiān)和項目經(jīng)理需要做好相關(guān)準(zhǔn)備

這是一個問題暴露階段，這個過程需要的全員的配合，這也是為什么在前期下放責(zé)任和思想 統(tǒng)一的原因點，一個架構(gòu)師，一個部門是無法支撐起團(tuán)隊能力的。

初期的驗證和轉(zhuǎn)換調(diào)整操作，基本上覺得沒什么問題，但現(xiàn)實是不可預(yù)知的， 一個場景是在前期基本上按k8s服務(wù)之間調(diào)用方式來進(jìn)行的，但是在內(nèi)外網(wǎng)絡(luò)隔離，還有外圍服務(wù)的時候，IP判斷的問題，還有各種第三方插件的問題等，還有各個使用群體上相應(yīng)表現(xiàn)情況。

類似于上面的場景，并不是說有多大困難，這個過程是團(tuán)隊會面對的問題，在最終解決下，會更進(jìn)一步的提升團(tuán)隊的能力點，最終達(dá)到內(nèi)部接受到自然狀態(tài)。

另一個是一些操作的不成熟，還有驗證性，需要大量的生產(chǎn)和測試驗證，以確?？尚行院秃笃诘姆€(wěn)定性，這些前期驗證環(huán)境有操作，但是也有很多未知，這些都是要面對克服的問題， 同樣需要整體團(tuán)隊的解決能力。

#后期

這里針對的是在架構(gòu)設(shè)計層支撐和中臺研發(fā)團(tuán)隊架構(gòu)的支撐上的后期。

到這一步的時候，業(yè)務(wù)中臺架構(gòu)基本上便向于穩(wěn)定，由原來的中臺架構(gòu)雛形，轉(zhuǎn)變成業(yè)務(wù)中臺架構(gòu)。不管是技術(shù)、團(tuán)隊、業(yè)務(wù)、專家還有各個場景下的沉淀都已經(jīng)有了沉淀能力，包括解決方案等，形成一套業(yè)務(wù)中臺能力點。

主要包括以下幾個點：

• 團(tuán)隊組織能力，形成中臺組織架構(gòu)保障，研發(fā)層和業(yè)務(wù)層

• 技術(shù)沉淀能力，形成技術(shù)中臺和研發(fā)支撐層

• 產(chǎn)品輸出能力，形成行業(yè)產(chǎn)品沉淀，形成基礎(chǔ)的行業(yè)標(biāo)準(zhǔn)產(chǎn)品組件

• 解決方案能力，在行業(yè)軟件中形成一套可行的解決方案

• 中臺業(yè)務(wù)能力，業(yè)務(wù)大中臺產(chǎn)出，小前臺業(yè)務(wù)建設(shè)的綜合能力

余下的，更多的是架構(gòu)設(shè)計的前期問題梳理和進(jìn)一步的優(yōu)化，各個管理功能的完善和進(jìn)一步沉淀產(chǎn)品能力，集成到中臺管理平臺上，同時在各個團(tuán)隊和小組之間進(jìn)行經(jīng)驗分享和總結(jié)。同時為下一個業(yè)務(wù)場景進(jìn)行梳理。

#其它

在業(yè)務(wù)中臺化建設(shè)的后期，各個業(yè)務(wù)偏向于穩(wěn)定，在中臺基礎(chǔ)上融入產(chǎn)品能力范圍。