在過去幾年中臺項(xiàng)目的實(shí)踐中，我們團(tuán)隊(duì)積累了一套成熟的中臺服務(wù)中心建設(shè)思路，該思路包含了從業(yè)務(wù)調(diào)研到中臺設(shè)計(jì)開發(fā)的標(biāo)準(zhǔn)流程和方法論，值得企業(yè)在進(jìn)行中臺建設(shè)時(shí)參考。

我們把業(yè)務(wù)中臺的落地方法總結(jié)為一個(gè)流程圖，如圖4-1所示。從業(yè)務(wù)的調(diào)研與規(guī)劃開始，到產(chǎn)出中臺設(shè)計(jì)，大致步驟包括：

1）調(diào)研與規(guī)劃。

2）需求分析。

3）中臺設(shè)計(jì)。

4）開發(fā)實(shí)現(xiàn)。

（1）調(diào)研與規(guī)劃

業(yè)務(wù)的調(diào)研與規(guī)劃目標(biāo)是，從發(fā)展角度去看企業(yè)當(dāng)下的業(yè)務(wù)運(yùn)營情況和未來的業(yè)務(wù)規(guī)劃。這一步非常重要，業(yè)務(wù)規(guī)劃的長遠(yuǎn)度決定了業(yè)務(wù)中臺的高度。所以這里要求業(yè)務(wù)方綜合考慮企業(yè)自身的特性、新技術(shù)應(yīng)用、新業(yè)務(wù)發(fā)展趨勢等方面。這里列舉一個(gè)零售行業(yè)某企業(yè)的例子，如圖4-2所示。

從這個(gè)業(yè)務(wù)規(guī)劃中，能明確看到企業(yè)中臺建設(shè)的總體規(guī)劃，在不同階段對于會員、庫存、營銷以及供應(yīng)鏈方面的業(yè)務(wù)訴求。有了規(guī)劃，接下來的中臺分析設(shè)計(jì)就更加有的放矢，不會出現(xiàn)目標(biāo)混淆和不可持續(xù)發(fā)展的問題。

（2）需求分析

業(yè)務(wù)規(guī)劃之后就是需求分析，單純從中臺設(shè)計(jì)的角度來說，需求分析更關(guān)注粗粒度核心業(yè)務(wù)流程，并不關(guān)心業(yè)務(wù)層面具體的用戶交互和功能細(xì)節(jié)需求。一般業(yè)務(wù)系統(tǒng)和中臺架構(gòu)設(shè)計(jì)的需求調(diào)研都是同步進(jìn)行的，所以這里也不用分得太清晰。

需求分析的目標(biāo)是，從業(yè)務(wù)規(guī)劃的各種業(yè)務(wù)場景出發(fā)，梳理核心業(yè)務(wù)流程。業(yè)務(wù)流程的粒度需要包含這幾類：業(yè)務(wù)角色、業(yè)務(wù)實(shí)體、業(yè)務(wù)規(guī)則、已經(jīng)存在的業(yè)務(wù)系統(tǒng)的接口、外部系統(tǒng)或者平臺的服務(wù)和接口。這個(gè)過程是邊梳理業(yè)務(wù)流程邊識別業(yè)務(wù)實(shí)體，兩者相輔相成。

（3）中臺設(shè)計(jì)

從需求分析到中臺設(shè)計(jì)有兩條路徑，如前面圖4-1所示。路徑A是從業(yè)務(wù)域分析開始的完整過程，經(jīng)過流程分析、時(shí)序圖分析和聚合分析，最后得出中臺設(shè)計(jì)方案；路徑B針對業(yè)務(wù)比較明確和相對簡單的場景，或者行業(yè)已經(jīng)有類似的業(yè)務(wù)沉淀（行業(yè)模型庫），可以基于這些模型庫進(jìn)行迭代，直接基于已有的方案開始迭代推演。下面我們演示路徑A的方法和過程。

這時(shí)就會遇到企業(yè)客戶經(jīng)常提出的問題—我們的公司到底需要幾個(gè)中心？這些中心怎么出來的？這些中心是什么樣子？

中臺設(shè)計(jì)一般分兩個(gè)階段：業(yè)務(wù)中心分析和業(yè)務(wù)中心設(shè)計(jì)。業(yè)務(wù)中心分析是從業(yè)務(wù)流程紛繁復(fù)雜的業(yè)務(wù)場景出發(fā)分解出目標(biāo)業(yè)務(wù)中心，業(yè)務(wù)中心設(shè)計(jì)需要完成中心的概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。

階段1：業(yè)務(wù)中心分析

這一步需要架構(gòu)師具有深度的行業(yè)業(yè)務(wù)理解能力和軟件分析設(shè)計(jì)能力，中臺既是前臺業(yè)務(wù)的基石，也是銜接前后臺業(yè)務(wù)的中樞，所以中臺設(shè)計(jì)一定要從企業(yè)核心業(yè)務(wù)場景和流程出發(fā)。

第一步，識別整個(gè)體系中最核心的業(yè)務(wù)流程，如圖4-3所示。從這些流程出發(fā)，分析流程中參與進(jìn)來的關(guān)鍵業(yè)務(wù)和數(shù)據(jù)實(shí)體，一一列舉。從核心到邊緣，從前臺到后臺、從后臺到前臺，正向流程、逆向流程，正常流程、異常流程，完整分析之后，你會得到一個(gè)企業(yè)業(yè)務(wù)實(shí)體的全景圖，這個(gè)圖包括用戶、會員、企業(yè)組織架構(gòu)、商品、交易（批發(fā)、零售），等等。

這個(gè)過程做得越細(xì)越好。在這個(gè)過程中，不要給自己設(shè)定用戶中心、商品中心的概念，這時(shí)候你的眼里應(yīng)該沒有中心和業(yè)務(wù)系統(tǒng)的邊界，只關(guān)注流程和實(shí)體本身。流程梳理完全是從具體業(yè)務(wù)場景出發(fā)，忠實(shí)于用戶期望的業(yè)務(wù)需求，不要被現(xiàn)在實(shí)際的流程和系統(tǒng)所束縛。

圖4-4展示了O2O場景下一個(gè)線上下單、線下物流送貨的處理流程中，把所有跨系統(tǒng)流程全部梳理后得到的流程全景圖。

第二步，把第一步分析的業(yè)務(wù)流程全景圖聚合分析，從不同業(yè)務(wù)領(lǐng)域來歸納分析產(chǎn)生的業(yè)務(wù)和數(shù)據(jù)實(shí)體。這時(shí)你會發(fā)現(xiàn)，整個(gè)大圖中最關(guān)鍵的那些業(yè)務(wù)實(shí)體與絕大多數(shù)的流程都有關(guān)系，而且和絕大多數(shù)的業(yè)務(wù)場景都有交互。通常，這時(shí)你所要找的適合納入中臺的業(yè)務(wù)領(lǐng)域就呼之欲出了，比如會員域、商品域、交易域、庫存域，等等。這時(shí)就可以初步確定中臺的基本輪廓。

圖4-5是從上面梳理的業(yè)務(wù)流程全景圖出發(fā)，分析流程中的主要業(yè)務(wù)對象，歸類整理形成核心業(yè)務(wù)域，這些業(yè)務(wù)域?qū)⒊蔀橄乱徊椒?wù)中心設(shè)計(jì)的基礎(chǔ)。

第三步，對這些初步確定的業(yè)務(wù)域進(jìn)行進(jìn)一步分析，分析業(yè)務(wù)域相互之間的依賴關(guān)系、復(fù)雜度、實(shí)體之間的親密度等。不同業(yè)務(wù)場景得到的結(jié)果可能大不一樣，例如，有的企業(yè)積分營銷活動還不是很規(guī)范，也不成熟，在第一、二步的分析中可能會把積分賬戶放在會員域，因?yàn)橛脩糇詴r(shí)會贈送初始積分，這是很自然的事情。

而有的企業(yè)營銷活動非常成熟，會員消費(fèi)行為會導(dǎo)致積分賬戶變化，同時(shí)積分營銷活動又會消費(fèi)積分，所以會把積分賬戶放在交易域。

這一步需要基于一些服務(wù)化設(shè)計(jì)原則（參見后面的“服務(wù)化設(shè)計(jì)原則”部分）把這種初篩后的業(yè)務(wù)域的邊界清晰化，有些需要把某些實(shí)體從A業(yè)務(wù)域放進(jìn)B業(yè)務(wù)域；有時(shí)需要去偽存真，把一些噪音型的對象剔除，讓它們回歸本來的前臺或者后臺；還有一些需要火眼金睛，把本該進(jìn)入但是卻由于業(yè)務(wù)場景覆蓋度不夠暫時(shí)沒有進(jìn)入業(yè)務(wù)域的業(yè)務(wù)實(shí)體有預(yù)判性地拉進(jìn)來。這一步需要架構(gòu)師有豐富的分布式架構(gòu)、服務(wù)化設(shè)計(jì)、中臺設(shè)計(jì)的經(jīng)驗(yàn)。

基于上一步的產(chǎn)出再用時(shí)序圖的形式分析應(yīng)用與業(yè)務(wù)域之間的關(guān)系，如圖4-6所示，如果做得細(xì)致一點(diǎn)，這個(gè)過程可以進(jìn)一步細(xì)化出調(diào)用過程之中參與的業(yè)務(wù)實(shí)體。注意，這里的時(shí)序圖是基于業(yè)務(wù)域得出的，不是舊有系統(tǒng)依賴關(guān)系的時(shí)序圖。

分析業(yè)務(wù)規(guī)劃中的業(yè)務(wù)場景和用例會產(chǎn)出完整的基于中臺業(yè)務(wù)域架構(gòu)的調(diào)用關(guān)系，再把這些時(shí)序圖按業(yè)務(wù)域進(jìn)行分類歸集。時(shí)序圖中和業(yè)務(wù)域的每一次交互算一次“觸點(diǎn)”，按業(yè)務(wù)域把所有觸點(diǎn)進(jìn)行聚合，如圖4-7所示，通過觸點(diǎn)數(shù)我們可以直觀地看出來這些“業(yè)務(wù)域”的活躍度以及與業(yè)務(wù)場景的依賴程度。這時(shí)可以結(jié)合上節(jié)介紹的判斷標(biāo)準(zhǔn)、團(tuán)隊(duì)的資源以及業(yè)務(wù)規(guī)劃，定義出第一批可以升級到“中心”的業(yè)務(wù)域。

通過業(yè)務(wù)域與實(shí)體對象之間的依賴關(guān)系、業(yè)務(wù)域復(fù)雜度、業(yè)務(wù)實(shí)體之間的親密度對業(yè)務(wù)域做進(jìn)一步的聚類，這樣就可以將每一個(gè)業(yè)務(wù)實(shí)體歸類到合適的業(yè)務(wù)域。

通過這三個(gè)步驟，基本可以確定在當(dāng)前規(guī)劃的業(yè)務(wù)場景下，我們的中臺到底應(yīng)該有幾個(gè)中心，分別是哪些中心。

從業(yè)務(wù)調(diào)研得出中臺服務(wù)中心的設(shè)計(jì)，這一步現(xiàn)在很多企業(yè)做得非常隨意，一般都參考一些互聯(lián)網(wǎng)公司的實(shí)際經(jīng)驗(yàn)或者基于自己對中臺的理解，看到相關(guān)的流程就照搬過來，結(jié)果很可能會“水土不服”。在這里，我們推薦的方法是從企業(yè)的實(shí)際情況和具體需求出發(fā)，進(jìn)行科學(xué)分析，從客觀分析中總結(jié)得來。

階段2：業(yè)務(wù)中心設(shè)計(jì)

階段1分析出了有幾個(gè)中心以及中心邊界，這一階段要完成中心的詳細(xì)設(shè)計(jì)工作。在這個(gè)階段中，不是簡單地根據(jù)業(yè)務(wù)需求劃分模塊后把這些模塊落到中臺層就是中臺了，這樣設(shè)計(jì)出來的中臺只是具體的業(yè)務(wù)模塊下沉，缺乏抽象建模的過程，讓中臺的能力和擴(kuò)展能力都非常有限，這不能成為稱職的中臺。業(yè)務(wù)中臺一定要經(jīng)歷從具體到抽象的建模過程，中臺設(shè)計(jì)的核心是對業(yè)務(wù)抽象建模。

服務(wù)中心是業(yè)務(wù)中臺最核心的架構(gòu)元素，看起來和原來的應(yīng)用系統(tǒng)的模塊名稱差不多，但是在本質(zhì)上提升了維度。中心是拉通所有前后端系統(tǒng)的相關(guān)功能模塊，進(jìn)行統(tǒng)一抽象設(shè)計(jì)，用一個(gè)統(tǒng)一的模型去支持前后臺不同業(yè)務(wù)場景的需求，如圖4-8所示。

我們從三個(gè)維度來描述一個(gè)完整的業(yè)務(wù)中心設(shè)計(jì)：業(yè)務(wù)模型、數(shù)據(jù)模型、服務(wù)能力，一個(gè)服務(wù)中心通過業(yè)務(wù)模型描述業(yè)務(wù)承載邏輯，通過數(shù)據(jù)模型描述數(shù)據(jù)的底層規(guī)范，通過服務(wù)能力描述服務(wù)接口契約。通過這三個(gè)維度明確一個(gè)服務(wù)中心的設(shè)計(jì)，每個(gè)服務(wù)中心設(shè)計(jì)說明書要產(chǎn)出這三個(gè)核心概念。圖4-9是一個(gè)會員中心的設(shè)計(jì)示例。

維度一：業(yè)務(wù)模型

業(yè)務(wù)模型是一個(gè)比較難直接定義的概念，我們拿一個(gè)實(shí)際的例子來說明。一家多業(yè)態(tài)經(jīng)營的房地產(chǎn)企業(yè)，旗下有傳統(tǒng)的商業(yè)地產(chǎn)、住宅、物業(yè)，隨著業(yè)務(wù)的拓展也有酒店、旅游門票，甚至?xí)l(fā)展出社區(qū)零售的業(yè)務(wù)。如果這家企業(yè)選擇中臺架構(gòu)，那么商品中心應(yīng)該是什么樣子？

從任何一個(gè)單一維度去看這家企業(yè)對商品的需求，可能差異都非常大，商業(yè)地產(chǎn)類的商品是租售的鋪位，住宅類的商品是商品房，物業(yè)是服務(wù)類商品，酒店和旅游門票是類似于電子憑證類的虛擬商品，社區(qū)零售是通常意義上的百貨商品。我們對這些商品模型進(jìn)行每種業(yè)務(wù)場景的建模，都會面對這些模型的業(yè)務(wù)術(shù)語、模型結(jié)構(gòu)，它們完全不一樣。地產(chǎn)商品屬性特別多，商品描述復(fù)雜但是模型結(jié)構(gòu)單一，需要支持復(fù)雜組合查詢；社區(qū)零售類商品種類會比較多，變化比較快，用戶并發(fā)量較高，商品描述結(jié)構(gòu)都比較簡單；酒店和旅游門票類商品要求分類特別清晰，簡單易管理。

如果基于“煙囪式”架構(gòu)來設(shè)計(jì)，針對這幾種商品都可以推導(dǎo)出相應(yīng)的模型。如果用中臺架構(gòu)，就需要對這幾種業(yè)態(tài)的商品模型需求進(jìn)行再一次抽象，用一個(gè)通用的模型支持多種場景需求?？梢杂弥髯宇惸縼頋M足商品分類管理需求；用產(chǎn)品、屬性、屬性值、子屬性來滿足多業(yè)態(tài)商品多樣化描述需求；用標(biāo)簽來支持商品離散化管理需求；用前后臺類目分離來滿足基于前臺類目的營銷和基于后臺類目管理的需求。通過這樣的抽象，我們建立了如圖4-10所示的業(yè)務(wù)模型。

注意，基于這樣的方法設(shè)計(jì)的業(yè)務(wù)模型，需要與上層業(yè)務(wù)對接的業(yè)務(wù)術(shù)語做一個(gè)統(tǒng)一。比如，對于地產(chǎn)類業(yè)務(wù)，如果原來是基于項(xiàng)目、分期、樓棟建立的樹形結(jié)構(gòu)，就要對應(yīng)到現(xiàn)在的類目體系上（對地產(chǎn)業(yè)態(tài)建立業(yè)務(wù)約束規(guī)范實(shí)現(xiàn)對接）；如果原來是社區(qū)零售業(yè)務(wù)，應(yīng)該對應(yīng)到現(xiàn)在的商品類目管理體系下，這就是中臺的業(yè)務(wù)模型。

商品偏于主數(shù)據(jù)模型結(jié)構(gòu)，但是不要因此就誤以為服務(wù)中心的模型都是主數(shù)據(jù)模型，交易時(shí)要統(tǒng)一交易流程，營銷時(shí)要統(tǒng)一規(guī)則：針對不同的業(yè)務(wù)領(lǐng)域，有不同的建模訴求；基于業(yè)務(wù)但一定要高于業(yè)務(wù)。如果做不到模型層面的抽象統(tǒng)一，那就只是具體業(yè)務(wù)形態(tài)的模塊下沉，中臺的價(jià)值難以發(fā)揮。

維度二：數(shù)據(jù)模型

數(shù)據(jù)模型是服務(wù)中心底層的數(shù)據(jù)層實(shí)現(xiàn)，包括OLTP和OLAP兩種場景。根據(jù)業(yè)務(wù)的需求，可能需要結(jié)合分布式數(shù)據(jù)庫技術(shù)。

與交易相關(guān)的業(yè)務(wù)場景中，最常見的數(shù)據(jù)模型方案是定義實(shí)體關(guān)系模型，如果對擴(kuò)展性有要求，則可結(jié)合分布式數(shù)據(jù)庫技術(shù)形成方案。數(shù)據(jù)模型的第一個(gè)職責(zé)是明確數(shù)據(jù)的業(yè)務(wù)規(guī)范，為業(yè)務(wù)數(shù)據(jù)化和數(shù)據(jù)中臺建設(shè)做好基礎(chǔ)準(zhǔn)備工作。

維度三：服務(wù)能力

服務(wù)能力是中臺業(yè)務(wù)能力對外的服務(wù)契約，外部系統(tǒng)通過接入中臺的服務(wù)來使用中臺。服務(wù)列表包括兩部分：第一部分是針對中心的外部用戶部分，這部分要明確服務(wù)的接口契約，包括使用的通信協(xié)議、安全鑒權(quán)方案、服務(wù)的請求報(bào)文和響應(yīng)報(bào)文、服務(wù)的具體業(yè)務(wù)含義以及調(diào)用的上下文、異常情況等；第二部分是服務(wù)的開發(fā)實(shí)現(xiàn)，這部分內(nèi)容需要設(shè)計(jì)者畫出服務(wù)的業(yè)務(wù)流程、業(yè)務(wù)邊界、異常處理等。

上面已經(jīng)完成了中臺的設(shè)計(jì)，在進(jìn)入具體的開發(fā)之前，為了保證設(shè)計(jì)的中臺模型能滿足真實(shí)的業(yè)務(wù)場景，最好將中臺的服務(wù)放入具體的業(yè)務(wù)流程中進(jìn)行驗(yàn)證，也可以基于服務(wù)的mock實(shí)現(xiàn)來進(jìn)行驗(yàn)證。這個(gè)過程可能比較煩瑣，但是通過這個(gè)驗(yàn)證過程，可以發(fā)現(xiàn)中臺的業(yè)務(wù)模型抽象是否正確，使用是否方便，服務(wù)是否完整，發(fā)現(xiàn)設(shè)計(jì)中模型的問題，再快速迭代修改。如果所有的業(yè)務(wù)場景都能通過這樣的驗(yàn)證，那么中臺的設(shè)計(jì)方案是可行的。

（4）開發(fā)實(shí)現(xiàn)

開發(fā)實(shí)現(xiàn)基于服務(wù)接口規(guī)范、數(shù)據(jù)模型和業(yè)務(wù)流程進(jìn)行，當(dāng)數(shù)據(jù)模型和服務(wù)能力都具備后，開發(fā)者就能進(jìn)行詳細(xì)設(shè)計(jì)和開發(fā)了。這里并沒有特殊之處，但需要開發(fā)人員掌握分布式、服務(wù)化相關(guān)的一些開發(fā)原則和技術(shù)，特別是在分布式體系下，引入了一些在傳統(tǒng)一體化架構(gòu)體系下不太關(guān)注的技術(shù)原則，比如分布式事務(wù)、異步、冪等問題。相關(guān)技術(shù)可參考《企業(yè)IT架構(gòu)轉(zhuǎn)型之道》一書。

本文由機(jī)械工業(yè)出版社獨(dú)家授權(quán)發(fā)布，中臺圣經(jīng)——《企業(yè)IT架構(gòu)轉(zhuǎn)型之道》作者鐘華新作！《數(shù)字化轉(zhuǎn)型的道與術(shù)：以平臺思維為核心支撐企業(yè)戰(zhàn)略可持續(xù)發(fā)展》。