作者：京東零售 徐開廷

本文大約1.7萬字，閱讀需要13分鐘。

導(dǎo)讀：近幾年，除AIGC外，軟件領(lǐng)域相關(guān)比較大的變化，就是各相關(guān)業(yè)務(wù)領(lǐng)域開始如火如荼地建設(shè)中臺(tái)和去中臺(tái)化了。本文不探討中臺(tái)對(duì)公司組織架構(gòu)涉及的變化和影響，只是從中臺(tái)化演進(jìn)的思路，及使用的底層支撐技術(shù)框架進(jìn)行分析探討，重點(diǎn)對(duì)中臺(tái)及前臺(tái)協(xié)作涉及到的擴(kuò)展點(diǎn)及熱部署包的底層技術(shù)細(xì)節(jié)，結(jié)合京東實(shí)際落地情況，對(duì)涉及的核心技術(shù)框架進(jìn)行源碼初探分析，探討技術(shù)框架的考慮點(diǎn)，拓寬大家的思路，歡迎大家審閱。

1、序言

中臺(tái)及其建設(shè)，區(qū)別于單體應(yīng)用建設(shè)及微服務(wù)建設(shè)，最大的差異在于中臺(tái)建設(shè)有一個(gè)較為獨(dú)特的概念，即前臺(tái)角色。中臺(tái)建設(shè)并采用標(biāo)準(zhǔn)協(xié)議，開放了一系列標(biāo)準(zhǔn)豐富的能力供前臺(tái)角色去編排、擴(kuò)展使用。從外部的視角來看，其實(shí)看不到中臺(tái)和前臺(tái)，單純還是功能交付，外界的感知沒有太大的差異；從產(chǎn)研的視角來看，功能交付是中臺(tái)能力疊加一系列前臺(tái)個(gè)性化能力的結(jié)合物，職責(zé)上期望通過中臺(tái)底層能力建設(shè)和前臺(tái)個(gè)性化能力增強(qiáng)，兩方獨(dú)立開發(fā)，再通過底層技術(shù)支撐框架來將兩方能力進(jìn)行結(jié)合，期望達(dá)到中臺(tái)、前臺(tái)角色分工清晰，獨(dú)立交付，提升交付速度的美好愿望。

從上述定義就可以看到，在外部視角感知不強(qiáng)的情況下，交付速度其實(shí)是個(gè)很明顯的衡量指標(biāo)。中臺(tái)建設(shè)成功的標(biāo)準(zhǔn)，重點(diǎn)并不在于對(duì)中臺(tái)建設(shè)的豐富能力進(jìn)行衡量，也不在于前臺(tái)開發(fā)了多少獨(dú)立的擴(kuò)展能力，仍在于同之前未建設(shè)中臺(tái)相比，交付速度是否有質(zhì)的提升。若這個(gè)關(guān)鍵指標(biāo)沒有變化，預(yù)估此類建設(shè)思路也會(huì)出現(xiàn)相關(guān)的變化及轉(zhuǎn)型，轉(zhuǎn)型的下一步思路和方法也有不少，不在這里探討。

后續(xù)的內(nèi)容，均會(huì)聚焦中臺(tái)的底層技術(shù)支撐框架（后文簡(jiǎn)稱為Matrix），來將中臺(tái)、前臺(tái)兩方能力進(jìn)行結(jié)合的技術(shù)細(xì)節(jié)和考慮點(diǎn)進(jìn)行展開。

在筆者看來，Matrix框架，作為京東實(shí)施PaaS化相關(guān)的技術(shù)解決方案，期望的是建立劃分合理的業(yè)務(wù)領(lǐng)域，完成業(yè)務(wù)建模及抽象，分離出核心邏輯及高頻個(gè)性化業(yè)務(wù)，并將個(gè)性化的邏輯隔離出來，期望交給名為前臺(tái)的組織或者部門去共建開發(fā)，來達(dá)成中臺(tái)邏輯穩(wěn)定，前臺(tái)可以并行開發(fā)，最終提升交付效率的目的。

當(dāng)然，在京東或者其他商業(yè)化公司，應(yīng)用系統(tǒng)覆蓋的業(yè)務(wù)領(lǐng)域及技術(shù)方向存在多種，包括但不限于各端的APP等前臺(tái)、各端的web前臺(tái)、各應(yīng)用后端系統(tǒng)、各數(shù)據(jù)算法平臺(tái)、各報(bào)表運(yùn)營(yíng)平臺(tái)等等。目前的Matrix框架對(duì)其他某些領(lǐng)域可能存在不適應(yīng)的情況，在筆者看來，著實(shí)屬于正常情況。世界上的工具萬萬千，刀槍劍戟 斧鉞鉤叉 閑棍槊棒 鞭锏錘抓；各類解決方案千千萬，很難存在一個(gè)錘子可以砸所有的釘子。但是只要總體的理念是合適的，并為其他各類適配此理念的工具提供合適成長(zhǎng)的土壤，預(yù)判此解決方案可以逐步豐滿成熟。

2、底層支撐框架分析

分析前提：我們只聚焦與中臺(tái)底層支撐框架，其他如中臺(tái)的業(yè)務(wù)領(lǐng)域切分、領(lǐng)域建模等內(nèi)容暫不涉及。需要注意的是，本次原理探究，是從使用人員及業(yè)務(wù)應(yīng)用的角度出發(fā)，而非從真正對(duì)Matrix設(shè)計(jì)者的角度出發(fā)，對(duì)Matrix原理的探索難免會(huì)存在以偏概全的毛病，對(duì)其全貌也必然會(huì)存在描述不準(zhǔn)確的情況。加之框架底層也在不斷豐富和完善，很多技術(shù)內(nèi)容存在不斷變更和發(fā)展，本文描述的內(nèi)容在短時(shí)間內(nèi)也會(huì)存在描述不再準(zhǔn)確的情況。但是好在基本原理應(yīng)該是準(zhǔn)確的，內(nèi)容描述的過程中，如有錯(cuò)誤，歡迎大家指正。

本文重點(diǎn)對(duì)底層支撐框架涉及的幾個(gè)核心技術(shù)點(diǎn)進(jìn)行展開：前臺(tái)包熱部署設(shè)計(jì)原理、前中臺(tái)隔離原理、前臺(tái)業(yè)務(wù)身份設(shè)計(jì)原理。

3、前臺(tái)包熱部署設(shè)計(jì)原理

在中臺(tái)化的實(shí)施路徑上，伴隨的節(jié)奏一般為：中臺(tái)能力改造升級(jí)-->中臺(tái)開放標(biāo)準(zhǔn)擴(kuò)展能力-->前臺(tái)使用標(biāo)準(zhǔn)擴(kuò)展能力完成個(gè)性化開發(fā)-->前中臺(tái)發(fā)布集成。其中發(fā)布集成有2種可選的方式，一種是中臺(tái)和前臺(tái)采用手工半自動(dòng)化的方式進(jìn)行集成，另外一種是中臺(tái)和前臺(tái)使用全自動(dòng)的方式進(jìn)行集成。全自動(dòng)的方式，就免不了需要將前臺(tái)的功能包，采用“熱部署”的方式部署至中臺(tái)相關(guān)的應(yīng)用系統(tǒng)中。

本文對(duì)前臺(tái)包發(fā)布、熱部署的技術(shù)方案及思路進(jìn)行探究，讓我們的讀者了解其設(shè)計(jì)理念。這樣以后在工作中遇到類似前臺(tái)包發(fā)布相關(guān)的問題，亦或者后續(xù)有機(jī)會(huì)使用并研究其他類似的技術(shù)框架，均可以做到舉一反三，心中了然。

3.1、熱部署基本原理

在開始介紹之前，假定我們作為底層框架的設(shè)計(jì)方，可以嘗試回答下方的三個(gè)問題，并與后面給出的結(jié)果進(jìn)行對(duì)比，看看與自己預(yù)判的答案是否一致。若不一致，本文應(yīng)該對(duì)你有些幫助，可以細(xì)細(xì)品鑒；若一致，那么恭喜你，說明你的技術(shù)功底相當(dāng)扎實(shí)，對(duì)相關(guān)的原理及實(shí)踐了解透徹。

問題：

1）使用前臺(tái)擴(kuò)展包，在發(fā)布平臺(tái)操作完成（完成推送、生效）后，應(yīng)用端進(jìn)行擴(kuò)容上線，擴(kuò)展點(diǎn)包是否可以自動(dòng)拉取加載、自動(dòng)掛載運(yùn)行？

2）使用前臺(tái)擴(kuò)展包，在發(fā)布平臺(tái)操作完成（完成推送、生效）前，應(yīng)用端進(jìn)行擴(kuò)容上線，擴(kuò)展點(diǎn)包是否可以自動(dòng)拉取加載、自動(dòng)掛載運(yùn)行？

3）使用前臺(tái)擴(kuò)展包，在發(fā)布平臺(tái)對(duì)部分容器完成前臺(tái)包灰度推送，但沒有觸發(fā)生效，此時(shí)對(duì)這些容器執(zhí)行重啟操作，推送的前臺(tái)包是否會(huì)掛載運(yùn)行？

4）在測(cè)試環(huán)境亦或是其他環(huán)境，一不小心刪除了熱部署包路徑及對(duì)應(yīng)的文件，會(huì)有什么問題？如何解決？

在開始回答上面的問題之前，我們要先來給大家介紹下PaaS化下幾個(gè)相關(guān)的名詞，及這些名詞背后的相互作用的關(guān)系。

可以先看下如下的架構(gòu)設(shè)計(jì)圖（筆者自己理解，與官方理解可能存在一定的差異）：

??

相關(guān)名詞及對(duì)應(yīng)的業(yè)務(wù)含義簡(jiǎn)要說明：

1）控制臺(tái)相關(guān)：前臺(tái)或者中臺(tái)相關(guān)組織或角色在控制臺(tái)操作上傳前臺(tái)包，控制臺(tái)將相關(guān)的包信息寫入至相關(guān)存儲(chǔ)，并主動(dòng)通知應(yīng)用系統(tǒng)，應(yīng)用系統(tǒng)內(nèi)的Matrix SDK接收到通知后，執(zhí)行相關(guān)的熱更新及其他操作

2）Matrix SDK相關(guān)：熱部署的包變更、發(fā)布等均依賴遠(yuǎn)端的控制臺(tái)操作，在控制臺(tái)操作審批通過后，遠(yuǎn)端的控制臺(tái)將信息變更寫入到相關(guān)存儲(chǔ)，并發(fā)送變更通知到各個(gè)docker應(yīng)用實(shí)例，各docker實(shí)例接受變更通知并執(zhí)行如熱部署等不同的操作。docker實(shí)例執(zhí)行熱部署的工作主要有：從遠(yuǎn)程私服下載jar到本地目錄，并執(zhí)行一系列的操作流程，包括但不限于前臺(tái)包卸載、前臺(tái)包更新等，其中前臺(tái)包更新包括但不限于：前臺(tái)包類加載、前臺(tái)包類初始化、前臺(tái)包生命周期管理、前臺(tái)包動(dòng)態(tài)代理管理等。所謂萬丈高樓平地起，Matrix平臺(tái)框架的功能再復(fù)雜，實(shí)際的地基就是基于這一點(diǎn)，并在基礎(chǔ)夯實(shí)疊加其他各類優(yōu)化和加強(qiáng)的功能，大家可以仔細(xì)領(lǐng)悟。

3）應(yīng)用層執(zhí)行相關(guān)：中臺(tái)應(yīng)用層，在執(zhí)行至擴(kuò)展點(diǎn)相關(guān)的業(yè)務(wù)邏輯時(shí)，會(huì)動(dòng)態(tài)代理至Matrix SDK，并由SDK接管邏輯，并確認(rèn)業(yè)務(wù)是否命中相關(guān)的業(yè)務(wù)身份，在在業(yè)務(wù)身份命中后執(zhí)行前臺(tái)包的實(shí)際邏輯。

4）監(jiān)控及安全相關(guān)：控制臺(tái)及Matrix SDK相互合作，采集心跳、擴(kuò)展點(diǎn)執(zhí)行時(shí)間等各類統(tǒng)計(jì)維度數(shù)據(jù)，此處也是一個(gè)較為復(fù)雜的體系，不詳細(xì)展開。

備注：以上架構(gòu)圖，只是筆者理解的Matrix技術(shù)框架的示意圖，僅供參考。

?

前臺(tái)包發(fā)布、熱部署及管理相關(guān)的主要的鏈路示意圖如下所示：

??

從圖中可以看到，我們的前臺(tái)包發(fā)布、熱部署存在“推”、“拉”兩條數(shù)據(jù)鏈路，兩條數(shù)據(jù)鏈路也分別適配不同的業(yè)務(wù)場(chǎng)景，如下詳細(xì)展開。

3.1.1、“推”鏈路

此鏈路的全過程可以表述為：軟件實(shí)施人員在控制臺(tái)，通過推送、生效等可視化界面工具操作完成后，控制臺(tái)會(huì)將用戶操作數(shù)據(jù)實(shí)時(shí)寫入至相關(guān)的數(shù)據(jù)中心，數(shù)據(jù)中心依賴的核心組件DUCC（一種類似ZK的存儲(chǔ)介質(zhì)）會(huì)對(duì)外發(fā)布實(shí)時(shí)變更消息。集成了SDK的應(yīng)用容器收到DUCC變更消息通知后，感知控制臺(tái)的操作并依據(jù)操作類型不同做出差異化的反映：SDK依據(jù)操作的不同指令，在應(yīng)用容器中執(zhí)行不同的業(yè)務(wù)操作。

目前SDK中的操作策略指令包括但不限于如下4類：

1）推送：對(duì)應(yīng)的功能可表述為：SDK接收到指令后，從遠(yuǎn)端文件服務(wù)器將相關(guān)版本的前臺(tái)包下載至應(yīng)用容器的固定目錄中。此功能在Matrix技術(shù)框架中中對(duì)應(yīng)的處理類為：PublishActionImpl。

2）生效：對(duì)應(yīng)的功能可表述為：SDK接收到指令后，從遠(yuǎn)端文件服務(wù)器將相關(guān)版本的前臺(tái)包下載至應(yīng)用容器的固定目錄中，并執(zhí)行前臺(tái)包的熱加載功能（具體熱加載的功能說明，可以參考第二篇文章，此處不在贅述）。此功能在Matrix技術(shù)框架中中對(duì)應(yīng)的處理類為：TakeEffectActionImpl。

3）卸載：對(duì)應(yīng)的功能可表述為：SDK接收到指令后，將相關(guān)的前臺(tái)包從容器中卸載，并處理注銷相關(guān)的數(shù)據(jù)（備注：此功能在藏經(jīng)閣控制臺(tái)默認(rèn)情況下不會(huì)展示，我們平常情況下看不到這個(gè)功能菜單）。此功能在Matrix技術(shù)框架中中對(duì)應(yīng)的處理類為：UnloadActionImpl。

4）探活：對(duì)應(yīng)的功能可表述為：SDK接收到指令后，從當(dāng)前的容器服務(wù)器發(fā)送相關(guān)的心跳包，用以采集監(jiān)控當(dāng)前容器服務(wù)器相關(guān)的實(shí)時(shí)狀態(tài)數(shù)據(jù)。此功能在Matrix技術(shù)框架中中對(duì)應(yīng)的處理類為：DoAliveActionImpl。

“推”鏈路適用的場(chǎng)景為：應(yīng)用的場(chǎng)景為實(shí)時(shí)性要求較強(qiáng)的相關(guān)場(chǎng)景，包括但不限于新版本灰度及發(fā)布、版本回滾及控制、版本下線及監(jiān)控等。此類場(chǎng)景要求在控制臺(tái)執(zhí)行相關(guān)的操作步驟后，控制臺(tái)及相關(guān)的應(yīng)用容器在短時(shí)間內(nèi)（秒級(jí)或者毫秒級(jí)內(nèi)）做出實(shí)時(shí)反映。主打的就是保障通知的及時(shí)性。

3.1.2、“拉”鏈路

此鏈路的全過程可以表述為：軟件實(shí)施人員，在相關(guān)的容器部署平臺(tái)，通過對(duì)容器進(jìn)行擴(kuò)容等操作，完成應(yīng)用擴(kuò)容。在對(duì)擴(kuò)容的機(jī)器進(jìn)行發(fā)布上線的時(shí)候，集成了SDK的應(yīng)用容器，會(huì)自動(dòng)從數(shù)據(jù)中心獲取相關(guān)的應(yīng)用元數(shù)據(jù)，在識(shí)別到元數(shù)據(jù)中存在部署版本的時(shí)候，自動(dòng)從從遠(yuǎn)端文件服務(wù)器將最新生效版本的前臺(tái)包下載至應(yīng)用容器的固定目錄中，并執(zhí)行前臺(tái)包的熱加載功能。

此處需要注意一點(diǎn)，在京東現(xiàn)有環(huán)境內(nèi)，容器擴(kuò)容包含2步操作：1）部署平臺(tái)創(chuàng)建新的docker環(huán)境，完成應(yīng)用實(shí)例的創(chuàng)建，并處理復(fù)制更新好相關(guān)的鏡像環(huán)境；2）軟件實(shí)施人員對(duì)擴(kuò)容出來的應(yīng)用實(shí)例，執(zhí)行發(fā)布上線等操作。其中“拉”鏈路出現(xiàn)的時(shí)機(jī)出現(xiàn)在步驟二中。從邏輯代碼中，我們可以看到，在應(yīng)用系統(tǒng)發(fā)布上線后，在spring的生命周期內(nèi)，Matrix會(huì)執(zhí)行相關(guān)“拉”邏輯。

“拉”鏈路適用的場(chǎng)景為：

1）對(duì)實(shí)時(shí)性要求不是很高的場(chǎng)景，如應(yīng)用擴(kuò)容等；

2）“推”鏈路無法觸達(dá)或觸達(dá)成本較高的場(chǎng)景。其中第二種場(chǎng)景有很多細(xì)分的業(yè)務(wù)場(chǎng)景，比如軟件實(shí)施人員對(duì)容器中的部分目錄文件執(zhí)行了誤刪除等操作，或者容器中的部分目錄文件出現(xiàn)了不可預(yù)知的損壞等異常場(chǎng)景。

?

3.1.3 、“推”和“拉”兩條鏈路設(shè)計(jì)理念說明

從上面可以看到，“推”和“拉”兩條鏈路都有其獨(dú)自適應(yīng)的應(yīng)用場(chǎng)景，那么筆者提出一個(gè)問題，是否有可能只保留其中的一條鏈路呢？讀者在不看后方的內(nèi)容時(shí)可提取思考一下，為什么Matrix框架會(huì)執(zhí)行如此設(shè)計(jì)呢？

在直接得出結(jié)論前，我們可以假定一下若只存在單鏈路，然后看看在單鏈路的情況下相關(guān)的復(fù)雜場(chǎng)景及其對(duì)應(yīng)的解決方案，最后我們?cè)賮砭C合評(píng)定最優(yōu)方案。

1、只存在“推”單鏈路：

需要應(yīng)對(duì)的復(fù)雜場(chǎng)景：應(yīng)用擴(kuò)容。

復(fù)雜場(chǎng)景下需要解決的問題：在應(yīng)用擴(kuò)容時(shí)，在“推”鏈路下，數(shù)據(jù)中心如何能快速感知到擴(kuò)容容器的存在，同時(shí)對(duì)此類場(chǎng)景實(shí)時(shí)下發(fā)處理消息降低實(shí)施成本。

可選的解決方案：在應(yīng)用擴(kuò)容發(fā)布時(shí)，應(yīng)用端主動(dòng)向數(shù)據(jù)中心發(fā)送相關(guān)的消息，獲取數(shù)據(jù)中心最新的應(yīng)用數(shù)據(jù)等；數(shù)據(jù)中心接收到消息后，再實(shí)時(shí)下發(fā)相關(guān)的處理消息。應(yīng)用容器接收到消息后，再執(zhí)行下載前臺(tái)包、熱更新等前臺(tái)包部署操作。

弊端：應(yīng)用擴(kuò)容發(fā)布后，按一般情況，應(yīng)用即可對(duì)外提供服務(wù)。為了防止出現(xiàn)應(yīng)用已對(duì)外提供了服務(wù)，但是相關(guān)的前臺(tái)包還沒有拉取到應(yīng)用本地，導(dǎo)致相關(guān)的擴(kuò)展點(diǎn)出現(xiàn)“空轉(zhuǎn)”等情況。為了解決此問題，上方提及的可選的解決方案，務(wù)必要保障實(shí)時(shí)性特別高，即務(wù)必保障在系統(tǒng)啟動(dòng)并對(duì)外提供服務(wù)前，快速完成解決方案。那么怎么保障？最好的辦法就是在未處理成功前，設(shè)定系統(tǒng)沒有啟動(dòng)成功，不能對(duì)外提供服務(wù)。如此，此方案落地層面，涉及SDK和數(shù)據(jù)中心一來一回兩次交互，存在方案較為復(fù)雜，存在后續(xù)維護(hù)運(yùn)維成本高的問題；同時(shí)還存在消息鏈路太長(zhǎng)，導(dǎo)致整個(gè)項(xiàng)目的啟動(dòng)時(shí)長(zhǎng)變得不可控，擴(kuò)容體驗(yàn)變得極差的問題。

?

2、只存在“拉”單鏈路：

需要應(yīng)對(duì)的復(fù)雜場(chǎng)景：軟件實(shí)施人員在控制臺(tái)實(shí)時(shí)操作“發(fā)布”、“推包”等操作。

復(fù)雜場(chǎng)景下需要解決的問題：軟件實(shí)施人員執(zhí)行的操作，在“拉”鏈路下，在應(yīng)用端要可以及時(shí)感知到。

可選的解決方案：可選的方案有2個(gè)：1）控制臺(tái)和應(yīng)用端建立直接聯(lián)系，在控制臺(tái)完成相關(guān)操作后，直接通過聯(lián)系渠道將操作傳遞給應(yīng)用端；2）應(yīng)用端定時(shí)獲取數(shù)據(jù)中心的最新應(yīng)用狀態(tài)數(shù)據(jù)。但是方案一基本變相等同于是“推”鏈路，此處可以忽略不計(jì)。方案二理論上可行，但是也存在2個(gè)弊端：1）定時(shí)的時(shí)長(zhǎng)不好控制，太長(zhǎng)了，則操作可被感知具有一定的延遲性，存在客戶體驗(yàn)不佳的情況；2）定時(shí)時(shí)長(zhǎng)太短了，多個(gè)應(yīng)用無腦同時(shí)請(qǐng)求數(shù)據(jù)中心，對(duì)數(shù)據(jù)中心的高可用提出了極高的要求。對(duì)此弊端，我們可選的方案有：制定業(yè)務(wù)可接收的延時(shí)時(shí)間，并定時(shí)去請(qǐng)求數(shù)據(jù)中心。并對(duì)請(qǐng)求時(shí)，請(qǐng)求數(shù)據(jù)和返回?cái)?shù)據(jù)存在數(shù)據(jù)過大的情況，采取數(shù)據(jù)極限裁剪、數(shù)據(jù)壓縮等方案。并設(shè)定獨(dú)立專業(yè)團(tuán)隊(duì)，通過建立雙數(shù)據(jù)中心等機(jī)制，保障數(shù)據(jù)中心的安全性及高可用性。

弊端：從根上來講，相關(guān)的通知鏈路總會(huì)存在或多或少的時(shí)延，客戶體驗(yàn)或多或少都有一定的影響；同時(shí)方案復(fù)雜性變高，維護(hù)成本變大。

小結(jié)：從上述兩處推測(cè)方案可以看到，單純只是采用一種解決方案，均存在較多的方案瑕疵。而將“推”和“拉”兩個(gè)方案進(jìn)行結(jié)合，并將方案應(yīng)用在其適應(yīng)的領(lǐng)域，則上述提及的弊端均可以以最小的成本來得以化解。而“推”、“拉”結(jié)合的解決方案，在業(yè)界的各類場(chǎng)景下，也存在廣泛運(yùn)用。大家可以多加領(lǐng)悟。

3.2、熱部署相關(guān)注意事項(xiàng)

1、需要注意控制大面積擴(kuò)容的節(jié)奏：從上述的表述中，我們可以看到，應(yīng)用在擴(kuò)容發(fā)布的時(shí)候，集成了SDK的應(yīng)用服務(wù)器，會(huì)從遠(yuǎn)端服務(wù)器拉取最新的前臺(tái)包至應(yīng)用服務(wù)器。假定我們的前臺(tái)包裁剪的大小比例不合理，一個(gè)前臺(tái)包的大小在300M及以上，加之我們擴(kuò)容采取的是大面積擴(kuò)容發(fā)布上線應(yīng)對(duì)線上緊急情況的場(chǎng)景，那么大促的某個(gè)瞬間，會(huì)存在同一時(shí)刻，應(yīng)用容器集中請(qǐng)求文件服務(wù)器，可能導(dǎo)致文件服務(wù)器過載，進(jìn)而導(dǎo)致下載失敗和發(fā)布上線啟動(dòng)不成功的情況。這種情況，我是頂不住，不知道你頂不頂?shù)米。?/p>

對(duì)于這種情況，推薦3類解決方案：1）每次只進(jìn)行小批量擴(kuò)容，保障擴(kuò)容數(shù)量的合理性；2）仍然采取大批量擴(kuò)容，但在應(yīng)用發(fā)布啟動(dòng)時(shí)采用小批量的方式分批進(jìn)行；3）在大面積擴(kuò)容時(shí)，通知Matrix相關(guān)同事，要求其對(duì)文件服務(wù)器及擴(kuò)容操作進(jìn)行重點(diǎn)保障。至于具體落地方案怎么選擇，大家可多加思考，并自由抉擇。

2、需要注意控制前臺(tái)包的大小：不管是“推”還是“拉”哪條鏈路，均會(huì)涉及到對(duì)前臺(tái)包從遠(yuǎn)端服務(wù)器下載至本地的操作。從感官上來，此項(xiàng)操作對(duì)網(wǎng)絡(luò)資源的消耗、應(yīng)用服務(wù)器本地資源的讀寫均會(huì)在瞬間造成較大的影響。如此，就要求我們的共建方前臺(tái)角色、中臺(tái)角色嚴(yán)格把控前臺(tái)包的大小，避免無關(guān)的包打入，控制前臺(tái)包的大小在相對(duì)合理的區(qū)間。

3.3、問題解答及分析

依據(jù)上方的講解，我們?cè)賮砜聪滦蜓灾刑峒暗娜齻€(gè)問題，來看看最終的答案，不知和你心中的答案是否一致呢？

問題1）使用前臺(tái)擴(kuò)展包，在發(fā)布平臺(tái)操作完成（完成推送、生效）后，應(yīng)用端進(jìn)行擴(kuò)容上線，擴(kuò)展點(diǎn)包是否可以自動(dòng)拉取加載、自動(dòng)掛載運(yùn)行？

答案：可以。此時(shí)應(yīng)用端擴(kuò)容上線，因?yàn)閼?yīng)用服務(wù)器上不存在任何前臺(tái)包，會(huì)采取“拉”鏈路，將相關(guān)的前臺(tái)包一次性拉取到本地進(jìn)行加載、自動(dòng)掛載運(yùn)行。

?

問題2）使用前臺(tái)擴(kuò)展包，在發(fā)布平臺(tái)操作完成（完成推送、生效）前，應(yīng)用端進(jìn)行擴(kuò)容上線，擴(kuò)展點(diǎn)包是否可以自動(dòng)拉取加載、自動(dòng)掛載運(yùn)行？

答案：可以。此時(shí)仍然是“拉”鏈路在生效，但是需要注意一點(diǎn)，次數(shù)“拉”鏈路拉取的數(shù)據(jù)，為發(fā)布平臺(tái)管理的上一次（如果有的話）上線的最新信息。在完成擴(kuò)容上線后，如果我們沒有在發(fā)布平臺(tái)對(duì)新擴(kuò)容的機(jī)器進(jìn)行推包、發(fā)布等操作，線上應(yīng)用會(huì)存在并運(yùn)行兩個(gè)版本的前臺(tái)包。

問題3）使用前臺(tái)擴(kuò)展包，在發(fā)布平臺(tái)對(duì)部分容器完成前臺(tái)包灰度推送，但沒有觸發(fā)生效，此時(shí)對(duì)這些容器執(zhí)行重啟操作，推送的前臺(tái)包是否會(huì)掛載運(yùn)行？

答案：不會(huì)。雖然說前臺(tái)包已完成灰度推送，相關(guān)的前臺(tái)包文件已在應(yīng)用容器中存在，但是容器執(zhí)行重啟操作時(shí)，SDK會(huì)自動(dòng)按分組、IP等檢測(cè)最新已生效的版本，若發(fā)現(xiàn)當(dāng)前版本并沒有生效，哪怕這個(gè)前臺(tái)包文件在容器中已存在，也不會(huì)掛載運(yùn)行。

問題4）在測(cè)試環(huán)境亦或是其他環(huán)境，一不小心刪除了熱部署包路徑及對(duì)應(yīng)的文件，會(huì)有什么問題？如何解決？

答案：分情況。

情況1：若是我們將前臺(tái)包相關(guān)的目錄進(jìn)行了整個(gè)移除，則在應(yīng)用容器再次進(jìn)行啟動(dòng)的時(shí)候，會(huì)執(zhí)行“拉”鏈路，將相關(guān)的前臺(tái)包一次性拉取到本地進(jìn)行加載、自動(dòng)掛載運(yùn)行。

情況2：若是我們講前臺(tái)包相關(guān)的目錄中的部分文件進(jìn)行移除（具體移除了哪類文件此處不詳細(xì)展開），“拉”鏈路識(shí)別前臺(tái)包文件已存在，“拉”鏈路不會(huì)得以執(zhí)行。但是因?yàn)槲募褤p毀，相關(guān)的數(shù)據(jù)不完整，SDK在記載的過程中，會(huì)拋出相關(guān)的錯(cuò)誤異常，并給出相關(guān)的錯(cuò)誤信息，最終呈現(xiàn)的效果為整個(gè)應(yīng)用啟動(dòng)失敗。

4、前中臺(tái)隔離原理

前文介紹的熱部署操作完畢后，前臺(tái)擴(kuò)展包，就可以正確在中臺(tái)相關(guān)的容器中完成部署了加載了。那么此處問題來了，前臺(tái)和中臺(tái)會(huì)共用某些相關(guān)的類，如何保障執(zhí)行的安全性及可靠性呢。那么就不得不提到了類隔離機(jī)制，和隔離機(jī)制背后的原理：雙親委派模型。

?

類隔離機(jī)制：前臺(tái)和中臺(tái)使用不同的ClassLoader來加載實(shí)現(xiàn)隔離，中臺(tái)使用默認(rèn)的ClassLoader，前臺(tái)使用自定義的ClassLoader，其中部分類為了避免沖突，前中臺(tái)共享了默認(rèn)的ClassLoader，這些類包括但不限于RPC框架、緩存框架等基礎(chǔ)組件包。

筆者早期工作的時(shí)候，在web應(yīng)用系統(tǒng)，使用Eclipse的osgi概念在開發(fā)處理相關(guān)的bundle包的時(shí)候，對(duì)于涉及web應(yīng)用中登錄的session等復(fù)雜的數(shù)據(jù)結(jié)構(gòu)進(jìn)行信息傳遞處理的時(shí)候，經(jīng)常出現(xiàn)2類及以上的ClassLoader協(xié)同出現(xiàn)問題，導(dǎo)致應(yīng)用系統(tǒng)出現(xiàn)一些莫名的、難以排查的ClassNotFoundException。表象為應(yīng)用的工程包明明存在，在執(zhí)行的時(shí)候就是會(huì)出現(xiàn)錯(cuò)誤的奇特場(chǎng)景。當(dāng)時(shí)初畢業(yè)，技術(shù)功底淺薄，對(duì)此類問題印象極其深刻。而在我們?cè)诰〇|的實(shí)際使用的過程中，暫無發(fā)現(xiàn)此類問題。如果大家有遇到此類問題，歡迎進(jìn)一步交流。

?

說到類加載，就不得不提Java體系中大名鼎鼎的“雙親委派模型”（英文描述為：parents delegation model）。有關(guān)這個(gè)描述，此處多說一點(diǎn)。中文含義中的“雙”，其實(shí)在英文描述中并沒有對(duì)應(yīng)的描述，也即“雙”不“雙”，其實(shí)不緊要，緊要的是“委派”二字。“雙親委派模型”的核心內(nèi)容，用稍粗鄙點(diǎn)的言語可以表述為：有事找爸爸（爸爸如果也有事，可以找他爸爸的爸爸，以此類推）。此設(shè)計(jì)理念的好處內(nèi)外網(wǎng)相關(guān)文章介紹得較多，此處不在贅述。

??

此模型的簡(jiǎn)要代碼可以表述如下：

    protected Class loadClass(String name,boolean resolve)
        throwsClassNotFoundException
    {
        synchronized(getClassLoadingLock(name)){
            // First, check if the class has already been loaded
            Class c =findLoadedClass(name);
            if(c ==null){
                long t0 =System.nanoTime();
                try{
                    if(parent !=null){
                        c = parent.loadClass(name,false);
                    }else{
                        c =findBootstrapClassOrNull(name);
                    }
                }catch(ClassNotFoundException e){
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if(c ==null){
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 =System.nanoTime();
                    c =findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if(resolve){
                resolveClass(c);
            }
            return c;
        }
    }

所謂“雙親委派模型”，從上述代碼可以看到，先檢查類是否被加載過（第6行），若沒有加載則調(diào)用父加載器進(jìn)行加載（第11行），若父加載器為空則默認(rèn)使用啟動(dòng)類加載器進(jìn)行加載（低13行）。可以看到，若都失敗，則調(diào)用當(dāng)前類加載器進(jìn)行加載（第24行）。是不是和上述找“爸爸”的描述，比較契合？

在Matrix框架下，中臺(tái)相關(guān)的邏輯和前臺(tái)相關(guān)的業(yè)務(wù)包，是由2個(gè)獨(dú)立的ClassLoader類分開管理，其中前臺(tái)相關(guān)的業(yè)務(wù)包，是由名為com.jd.matrix.core.classloader.BizClassLoader的類進(jìn)行管理。我們先來看下這個(gè)類的具體邏輯：

public class BizClassLoader extends URLClassLoader{
    public BizClassLoader(URL[] urls){
        super(urls);
    }

    protected ClassloadClass(String name,boolean resolve) throwsClassNotFoundException{
        Class clazz =null;
        clazz =this.findLoadedClass(name);
        if(clazz !=null){
            return clazz;
        }else{
            try{
                ClassLoader jdkClassLoader =ClassLoaderFactory.getJDKClassLoader();
                clazz = jdkClassLoader.loadClass(name);
                if(clazz !=null){
                    return clazz;
                }
            }catch(ClassNotFoundException exception){
            }

            if(ExportClassManager.match(name)){
                clazz =ClassLoaderFactory.getInternalClassLoader().loadClass(name);
                if(clazz !=null){
                    return clazz;
                }
            }

            try{
                clazz =this.findClass(name);
            }catch(ClassNotFoundException exception){
            }

            if(clazz ==null){
                clazz =ClassLoaderFactory.getInternalClassLoader().loadClass(name);
            }

            return clazz;
        }
    }

    protected Class findClass(String name) throws ClassNotFoundException{
        returnsuper.findClass(name);
    }}

從代碼邏輯可以看到，Matrix提供的類加載器，其實(shí)是破壞了“雙親委派模型”，破壞點(diǎn)從13行開始，若當(dāng)前類沒有加載，沒有調(diào)用父加載器進(jìn)行加載，而是使用了jdkClassLoader去加載；同時(shí)若開啟了Matrix包屏蔽的策略（21行），則會(huì)使用中臺(tái)的ClassLoader去加載。

此處破壞的妙處在于：前臺(tái)包可以找到并使用中臺(tái)包對(duì)應(yīng)的相關(guān)類；但是中臺(tái)包不可以找到并使用前臺(tái)包對(duì)應(yīng)的相關(guān)類。粗俗點(diǎn)可以描述為：大哥不知道小弟，但是小弟在大哥的開放區(qū)域，可以有限了解大哥。

從此處也可以看到，Matrix對(duì)于類加載的管理與控制，與OSGI等標(biāo)準(zhǔn)規(guī)范相比，安全性等管控方面要松弛得多。從嚴(yán)格意義上來，此類管理的方式，安全性其實(shí)并不足，若中臺(tái)開放的區(qū)域過大，加上前臺(tái)包被有心人動(dòng)手腳，其實(shí)是存在安全隱患，并防不勝防。

?

我們可以看到，Matrix會(huì)結(jié)合容器側(cè)的spring配置里的exportClassConfig屬性，使用自定義的類加載器(BizClassLoader)去加載垂直業(yè)務(wù)包里的類，主要有兩個(gè)核心內(nèi)容：

1、對(duì)于不同的前臺(tái)業(yè)務(wù)包里的類，分別使用BizClassLoader的不同實(shí)例去加載，對(duì)于垂直業(yè)務(wù)包里的自己開發(fā)的業(yè)務(wù)類，即使不同的垂直業(yè)務(wù)包中存在全限定名相同的類，但因?yàn)榧虞d他們的BizClassLoader實(shí)例不同，不會(huì)出現(xiàn)沖突問題，類隔離的要求能夠得到滿足。

2、對(duì)于exportClassConfig這個(gè)屬性配置的相關(guān)類（包含但不限于：中臺(tái)提供的sdk包所包含的類、基礎(chǔ)RPC框架類），不會(huì)由1里所提及的自定義的classLoader的實(shí)例去加載，只會(huì)由同一個(gè)類加載器（加載中臺(tái)容器業(yè)務(wù)類的appClassLoader）去加載，以此來保證中臺(tái)容器調(diào)用擴(kuò)展點(diǎn)實(shí)現(xiàn)時(shí)參數(shù)類型校驗(yàn)的一致性。

從上方的信息和代碼中，我們可以看到， 假定前臺(tái)和中臺(tái)存在相同包名、相同類名的類，在執(zhí)行前臺(tái)擴(kuò)展點(diǎn)的時(shí)候，分為前后2個(gè)步驟：1）執(zhí)行前臺(tái)包擴(kuò)展點(diǎn)的業(yè)務(wù)身份匹配邏輯；2）執(zhí)行前臺(tái)包擴(kuò)展點(diǎn)的實(shí)際業(yè)務(wù)邏輯。2者的區(qū)別，主要在于后者有一個(gè)主動(dòng)切換當(dāng)前類加載器的邏輯。也即在步驟1時(shí)，當(dāng)前的類加載器為應(yīng)用容器業(yè)務(wù)類的加載器；步驟2時(shí)，當(dāng)前的類加載器切換為獨(dú)立的類加載器。

5、前臺(tái)業(yè)務(wù)身份設(shè)計(jì)原理

中臺(tái)和前臺(tái)合作的巧妙之處，在于中臺(tái)開放了多種標(biāo)準(zhǔn)的、可擴(kuò)展的能力，前臺(tái)基于自己的不同的業(yè)務(wù)身份實(shí)現(xiàn)多種個(gè)性化業(yè)務(wù)場(chǎng)景。即一種中臺(tái)的能力，可對(duì)應(yīng)多個(gè)前臺(tái)擴(kuò)展部署包。那么運(yùn)行時(shí)，中臺(tái)如何知道應(yīng)該使用哪些前臺(tái)包呢？

這里就不得不提業(yè)務(wù)身份這個(gè)概念了，在中臺(tái)的建設(shè)思想中，每個(gè)前臺(tái)包都有自己獨(dú)立的業(yè)務(wù)身份。中臺(tái)系統(tǒng)運(yùn)行的時(shí)候，依次匹配前臺(tái)部署包，并選擇業(yè)務(wù)身份命中的前臺(tái)包執(zhí)行相關(guān)邏輯。

?

業(yè)務(wù)身份的識(shí)別方式：Matrix業(yè)務(wù)身份有2種識(shí)別方式

1、前臺(tái)包手工編寫識(shí)別業(yè)務(wù)身份。即在前臺(tái)自己在元數(shù)據(jù)（Annotation）定義自己獨(dú)立的parserClass ，識(shí)別方式，由前臺(tái)業(yè)務(wù)系統(tǒng)手工編寫識(shí)別。這種方式的好處是純手寫代碼，加上前中臺(tái)組合review的時(shí)候，一般不會(huì)出現(xiàn)功能問題及性能瓶頸。但是也會(huì)存在很大一個(gè)弊端，即對(duì)某個(gè)業(yè)務(wù)而言，是不是屬于自己的業(yè)務(wù)身份，是前臺(tái)自己說了算，在一般情況下是沒有問題的，但是如果前中臺(tái)reivew的機(jī)制失效了，前臺(tái)基于某些特定的原因，將前臺(tái)的業(yè)務(wù)身份識(shí)別方式調(diào)整擴(kuò)大或縮小，會(huì)導(dǎo)致影響的業(yè)務(wù)范圍也會(huì)對(duì)應(yīng)的增大或者縮小，影響范圍非常不可控。

從中臺(tái)建設(shè)初期來看，本來預(yù)計(jì)這種方式，以后一定會(huì)廢棄掉。從過去幾年的實(shí)踐經(jīng)驗(yàn)來看，這個(gè)地方預(yù)判錯(cuò)了，這種形式目前仍然是主流的形式，只是不同的系統(tǒng)對(duì)同一個(gè)業(yè)務(wù)身份的識(shí)別，邏輯千差萬別，在串聯(lián)業(yè)務(wù)流程的過程，確實(shí)會(huì)存在較為痛苦的情況。

??

2、中臺(tái)統(tǒng)一管控識(shí)別業(yè)務(wù)身份。在在前臺(tái)自己在元數(shù)據(jù)（Annotation）設(shè)置autoParser的值為true，此時(shí)不用前臺(tái)來判斷處理和業(yè)務(wù)身份相關(guān)的控制邏輯了，這個(gè)邏輯會(huì)內(nèi)置在中臺(tái)，中臺(tái)相關(guān)的業(yè)務(wù)身份的解析類為AutoBizCodeParser，此類的定義與實(shí)現(xiàn)框架與前臺(tái)包定義的方式無異，只是實(shí)現(xiàn)了平臺(tái)通用的能力：即由中臺(tái)來決定是否可以命中某一個(gè)業(yè)務(wù)身份，在管理平臺(tái)增加相關(guān)配置來匹配是否可命中業(yè)務(wù)身份。

核心的邏輯是Matrix內(nèi)置定義了一個(gè)簡(jiǎn)單的腳本模板，在系統(tǒng)采用熱部署指令，加載啟動(dòng)前臺(tái)包的時(shí)候，識(shí)別到前臺(tái)包包含App元數(shù)據(jù)（Annotation）是自動(dòng)識(shí)別業(yè)務(wù)身份的時(shí)候，會(huì)在系統(tǒng)內(nèi)按內(nèi)置的腳本模板采用javassist框架來初始化緩存一套字節(jié)碼。在實(shí)際去匹配前臺(tái)業(yè)務(wù)身份的時(shí)候，實(shí)際執(zhí)行的是此類字節(jié)碼來動(dòng)態(tài)判斷業(yè)務(wù)身份是否可以命中。字節(jié)碼的模板代碼如下所示：

需要注意一點(diǎn)，目前底層框架生成字節(jié)碼的時(shí)間點(diǎn)，并不是系統(tǒng)自動(dòng)加載或者熱部署生效的時(shí)候，而是嘗試命中業(yè)務(wù)邏輯的時(shí)候。預(yù)判肯定會(huì)存在執(zhí)行過程中第一次速度緩慢的情況，實(shí)際使用的時(shí)候可以多加注意。

#{ClassStart}
import java.util.*;
#{Package}
public class #{ClassName} {
   #{MethodInfo}
}
#{ClassEnd}

#{PackageStart}
import #{TypeName};

#{PackageEnd}

#{VarStart}
    #{Type} #{Var}=(#{Type})context.get("#{Var}");
#{VarEnd}

#{executeStart}
 public boolean execute(Map context){
       #{VarInfo}
       return #{Express};
    } 
 #{executeEnd} 
 
   
#{allStart}
    private boolean all(#{Var} ){

       Iterator iterator =#{Collection}.iterator();
        while (iterator.hasNext()) {
          #{ItemType} #{ItemVar}=(#{ItemType})iterator.next();
           if(!(#{Right})){
              return false;
            }

        }
        return true;
    } 
#{allEnd}

#{anyStart}
    private boolean any(#{Var} ){

        Iterator iterator = #{Collection}.iterator();
        while (iterator.hasNext()) {
          #{ItemType} #{ItemVar}=(#{ItemType})iterator.next();
           if((#{Right})){
              return true;
           }

        }
        return false;
    } 
#{anyEnd}

業(yè)務(wù)身份命中基本流程：此處其實(shí)無需多言，業(yè)務(wù)身份命中的邏輯其實(shí)隱含在前面介紹的前臺(tái)包業(yè)務(wù)邏輯實(shí)際執(zhí)行的地方，只是Matrix框架在執(zhí)行邏輯前，創(chuàng)造了一個(gè)類似會(huì)話（Session）的概念，在會(huì)話中去對(duì)業(yè)務(wù)身份是否命中執(zhí)行相關(guān)匹配邏輯，實(shí)際就是對(duì)相關(guān)的前臺(tái)業(yè)務(wù)包執(zhí)行fiter方法，判斷評(píng)估業(yè)務(wù)身份命中。在會(huì)話（Session）中對(duì)前臺(tái)包依次執(zhí)行filter去匹配業(yè)務(wù)身份。

存在的風(fēng)險(xiǎn)：

1）部分前臺(tái)包業(yè)務(wù)身份識(shí)別邏輯較重，會(huì)導(dǎo)致整體中臺(tái)邏輯運(yùn)行緩慢，存在性能風(fēng)險(xiǎn)；對(duì)應(yīng)的建議解決方案：業(yè)務(wù)身份識(shí)別邏輯一定要輕量級(jí)；

2）目前Matrix框架默認(rèn)仍然只是捕獲了Exception類別的異常，對(duì)于Throwable級(jí)別的異常仍然是沒有捕獲的。部分前臺(tái)包業(yè)務(wù)邏輯存在偶發(fā)性問題，執(zhí)行業(yè)務(wù)身份匹配filter邏輯時(shí)，若拋出Throwable級(jí)別的異常，會(huì)導(dǎo)致其余業(yè)務(wù)身份的前臺(tái)包也無法執(zhí)行。這真是一粒老鼠屎，搞壞一鍋粥。

?

業(yè)務(wù)身份基本原理：Matrix實(shí)際以業(yè)務(wù)身份來管理業(yè)務(wù)包與擴(kuò)展點(diǎn)，同一個(gè)業(yè)務(wù)身份，可以命中一個(gè)垂直擴(kuò)展點(diǎn)（代號(hào)為Y）和一些水平擴(kuò)展點(diǎn)（代號(hào)為X）。針對(duì)同一個(gè)待識(shí)別的業(yè)務(wù)規(guī)則，比如同一個(gè)sku或者同一個(gè)訂單而言，不可以命中多個(gè)業(yè)務(wù)身份，若實(shí)際命中了多個(gè)業(yè)務(wù)身份，Matrix會(huì)限制只會(huì)命中其中的某一個(gè)業(yè)務(wù)身份對(duì)應(yīng)的擴(kuò)展點(diǎn)方法。也即對(duì)這種業(yè)務(wù)場(chǎng)景，Matrix即使會(huì)命中多個(gè)業(yè)務(wù)身份的fiter方法，但是實(shí)際只會(huì)執(zhí)行其中唯一的一個(gè)業(yè)務(wù)身份對(duì)應(yīng)的擴(kuò)展點(diǎn)方法，具體命中的業(yè)務(wù)身份，初看有一定的隨機(jī)性，具體順序參加下方的描述。

業(yè)務(wù)身份的順序：從Matrix遍歷業(yè)務(wù)身份處理擴(kuò)展點(diǎn)的業(yè)務(wù)邏輯來看，業(yè)務(wù)身份的順序至關(guān)重要，排名靠前的業(yè)務(wù)身份，其對(duì)應(yīng)的擴(kuò)展點(diǎn)方法執(zhí)行的幾率會(huì)大于排期靠后的業(yè)務(wù)身份。經(jīng)排查，Matrix對(duì)業(yè)務(wù)身份排名的邏輯由業(yè)務(wù)身份（App）的三個(gè)屬性來共同確定，具體為：priority（由大到小）、version（由大到小）、code（由大到小）。在滿足上述排序規(guī)則的前提下確定業(yè)務(wù)身份的優(yōu)先級(jí)。假定業(yè)務(wù)上存在如下場(chǎng)景：對(duì)同一個(gè)訂單或者同一個(gè)sku的場(chǎng)景，同時(shí)可命中二級(jí)業(yè)務(wù)身份和三級(jí)業(yè)務(wù)身份，理論上業(yè)務(wù)期望三級(jí)業(yè)務(wù)身份被命中到。但是很不巧，priority、versionSpec等值設(shè)置不合理，導(dǎo)致二級(jí)業(yè)務(wù)身份被命中到出現(xiàn)與預(yù)期不一致的情況。對(duì)于此類場(chǎng)景，我們就需要制定嚴(yán)格的代碼規(guī)范，對(duì)前臺(tái)業(yè)務(wù)側(cè)限定其priority、version、code的數(shù)值，確保業(yè)務(wù)邏輯的正確性。

重點(diǎn)提示：業(yè)務(wù)身份的定義與使用，是業(yè)務(wù)系統(tǒng)出現(xiàn)問題最多的地方。業(yè)務(wù)身份在Matrix中是一個(gè)很重要的概念，其設(shè)計(jì)理念期待整個(gè)業(yè)務(wù)身份是一顆節(jié)點(diǎn)互不交叉的樹，但是在實(shí)際業(yè)務(wù)執(zhí)行的時(shí)候，經(jīng)常會(huì)存在業(yè)務(wù)身份重疊的情況。設(shè)計(jì)定義前臺(tái)包的人員，屬于兩個(gè)不同的部門，屬于兩撥不同的人，2者很難意識(shí)到業(yè)務(wù)存在交叉重疊的情況，已經(jīng)發(fā)生多次線上業(yè)務(wù)跑飛了出現(xiàn)與預(yù)期不一致的情況，后來花了大力氣來解決的場(chǎng)景。常見出現(xiàn)問題的案例舉例供大家參考：我們提供了一個(gè)擴(kuò)展點(diǎn)供前臺(tái)業(yè)務(wù)使用，其中一個(gè)前臺(tái)包的業(yè)務(wù)身份是大家電，另外一個(gè)前臺(tái)包的業(yè)務(wù)身份是五星。結(jié)果在實(shí)際業(yè)務(wù)上，同一個(gè)sku或者同一個(gè)訂單，既是大家電的業(yè)務(wù)，也是五星的業(yè)務(wù)。對(duì)于這種場(chǎng)景，如何解決呢？這個(gè)問題留給大家來思考。

Matrix對(duì)業(yè)務(wù)身份排名的具體代碼如下所示，代碼邏輯參見BizCodeSpec.compareTo方法：

    public int compareTo(BizCodeSpec o) {
        if (o == null) {
            return -1;
        } else if (this.priority != null && o.priority != null) {
            int ret = o.priority - this.priority;
            if (ret != 0) {
                return ret;
            } else if (this.versionSpec != null && o.versionSpec != null) {
                ret = this.versionSpec.compareTo(o.versionSpec);
                if (ret == 0) {
                    ret = o.bizCode.compareTo(this.bizCode);
                }

                return ret;
            } else {
                return 0;
            }
        } else {
            return 0;
        }
    }

最佳實(shí)踐：

1、一般而言，我們?cè)谠O(shè)計(jì)并編寫前臺(tái)包的時(shí)候，包名應(yīng)該具有前臺(tái)獨(dú)立的業(yè)務(wù)屬性，也即包名和中臺(tái)的包名應(yīng)該有一定的區(qū)隔。對(duì)于可能會(huì)和中臺(tái)包沖突的業(yè)務(wù)場(chǎng)景，我們可以在框架中進(jìn)行類名或者包名的排除。

2、中臺(tái)開放給前臺(tái)的包名范圍，應(yīng)該盡量限定在最小范圍，防止前臺(tái)不經(jīng)意的惡意行為。

除這2點(diǎn)外，可能還存在其他各類場(chǎng)景對(duì)應(yīng)的最佳實(shí)踐，有待我們進(jìn)一步探索。

6、思考

不管是中臺(tái)化也好，還是去中臺(tái)也好。核心思路，都在于如何以技術(shù)，服務(wù)好我們的業(yè)務(wù)。中臺(tái)化，亦或者是品類差異化思路，均為交付過程中選擇使用的差異化工具。但是工具背后，必然隱藏著對(duì)應(yīng)的落地技術(shù)關(guān)鍵點(diǎn)，而這些關(guān)鍵點(diǎn)，道理都是相通的。作為技術(shù)人員，持續(xù)思考，如何從漫天繁花中，找到底層最核心的癥結(jié)，不斷打磨豐富我們的產(chǎn)品，提供優(yōu)質(zhì)的服務(wù)，值得我們持續(xù)探索。

審核編輯 黃宇