摘要：能不能只修改其中的一部分代碼并且進(jìn)行熱更新呢微內(nèi)核架構(gòu)插件架構(gòu)就適合來解決這個(gè)問題。微內(nèi)核架構(gòu)顧名思義，微內(nèi)核架構(gòu)的關(guān)鍵是內(nèi)核。微內(nèi)核架構(gòu)整體上由兩部分組成核心系統(tǒng)和插件模塊。微內(nèi)核架構(gòu)它的優(yōu)點(diǎn)是為遞進(jìn)設(shè)計(jì)和增量開發(fā)提供了方便。

如果第二次看到我的文章，歡迎下方掃碼訂閱我的個(gè)人公眾號（跨界架構(gòu)師）喲~
本文長度為3633字，建議閱讀10分鐘。
堅(jiān)持原創(chuàng)，每一篇都是用心之作～

如果我們的開發(fā)工作真的就如搭積木一般就好了，輪廓分明，個(gè)個(gè)分開，壞了哪塊積木換掉哪塊就好了。

但是，實(shí)際我們的工作中所面臨的可能只有一塊積木，而且還是一大塊，要換得一起換，要修得一起修。

Z哥在之前《分布式系統(tǒng)關(guān)注點(diǎn)（13）——「高內(nèi)聚低耦合」詳解》中提到的分層架構(gòu)它可以讓我們有意識的去做一些切分，但是換和修的難度還是根據(jù)切分的粒度大小來決定的。

有更好的方式嗎？這是顯然的。

我們來換一個(gè)思維看待這個(gè)問題。

不管是平時(shí)的系統(tǒng)升級也好、修復(fù)bug也好、擴(kuò)容也好，其實(shí)就是一場“手術(shù)”。通過這場“手術(shù)”來解決當(dāng)前面臨的一些問題。

那么分層架構(gòu)好比只是將一個(gè)人的手、腳、嘴、鼻等分的清清楚楚，但是整體還是緊密的耦合在一起。

怎么耦合的呢？我們?nèi)耸强俊把骸钡牧鲃舆B接起來的。這就好比在分布式系統(tǒng)中通過rpc框架連接起不同的節(jié)點(diǎn)一樣。

但是軟件與人不同，有2種不同的連接方式，除了「同步」的方式之外還有「異步」的方式。因?yàn)橛行r(shí)候你不需要知道其他系統(tǒng)的執(zhí)行結(jié)果，只要確保自己將其需要的數(shù)據(jù)傳遞給它了即可。

恰巧有一種架構(gòu)是這種模式的典型——事件驅(qū)動架構(gòu)（簡稱EDA，Event Driven Architecture）。

平時(shí)常見的MQ、本地消息表等運(yùn)用于數(shù)據(jù)傳遞的中轉(zhuǎn)環(huán)節(jié)，就是事件驅(qū)動架構(gòu)的思想體現(xiàn)。

事件驅(qū)動架構(gòu)又細(xì)分為兩種典型的實(shí)現(xiàn)方式，與Z哥之前在《分布式系統(tǒng)關(guān)注點(diǎn)（3）——「共識」的兄弟「事務(wù)」》中提到的Saga模式的2種實(shí)現(xiàn)方式類似，一種是中心化的、一種是去中心化的。

下面Z哥來舉個(gè)例子，讓你看起來更容易理解一些。（例子僅為了闡述是怎么工作的，真正的實(shí)施中還需要考慮如何保證數(shù)據(jù)一致性等問題，這部分可以參考之前發(fā)表的系列文章，文末帶傳送門）

傳統(tǒng)的電商場景中，用戶從購物車中點(diǎn)擊“提交”按鈕后，至少需要做這幾件事：生成一筆訂單、生成一筆支付記錄、給訂單匹配發(fā)貨的快遞公司。

在這個(gè)場景下，中心化和去中心化有什么不同呢？

這種模式擁有一個(gè)“上帝”。

但是“上帝”不會處理也不知道任何業(yè)務(wù)邏輯，它只編排事件。

除了中心化之外，它還有什么特點(diǎn)呢？Z哥給它的定義是“3+2結(jié)構(gòu)”。

這種模式中存在3種類型的主體：事件生產(chǎn)者、“上帝”（調(diào)停者）、事件處理者。然后中間夾著兩層隊(duì)列，以此結(jié)構(gòu)就能解耦。

就像這樣：事件生產(chǎn)者 --> 隊(duì)列 --> “上帝”（調(diào)停者） --> 隊(duì)列 --> 事件處理者。

那么回上面的這個(gè)例子中，事件生產(chǎn)者CartService發(fā)出了一個(gè)“訂單創(chuàng)建”事件，通過隊(duì)列傳遞給調(diào)停者。然后調(diào)停者根據(jù)事先制定好的編排規(guī)則對事件進(jìn)行相應(yīng)的轉(zhuǎn)換，也通過隊(duì)列做二次分發(fā)，傳遞給事件處理者。

可能你會問，這些好理解。但是，我之前也經(jīng)常看到什么編排編排的，到底編排該怎么做呢？

其實(shí)編排主要做兩件事：「事件轉(zhuǎn)換」和「事件發(fā)送」（對應(yīng)「服務(wù)編排」類框架的「調(diào)用」）。

「事件轉(zhuǎn)換」實(shí)質(zhì)就是給將要發(fā)送的事件對象的參數(shù)進(jìn)行賦值。賦值的數(shù)據(jù)來源于哪呢？

除了事件產(chǎn)生的源頭帶入的參數(shù)，還有持續(xù)累積的「上下文」，就如下圖中這樣的一個(gè)共享存儲空間。

可能你又會問，我怎么將多個(gè)事件處理者之間組合成一個(gè)上下文呢？

通過一個(gè)全局唯一的標(biāo)識即可，每次向“上帝”丟事件的時(shí)候把這個(gè)全局唯一標(biāo)識帶過去。

題外話：一般來說，還會在一個(gè)全局唯一標(biāo)識之下帶一個(gè)內(nèi)部唯一的「子流水號」，為了配合做接下去要講到的「事件發(fā)送」。
一是為了后續(xù)排查問題的時(shí)候清晰的知道這次調(diào)用產(chǎn)生的異常是從哪個(gè)上游系統(tǒng)來的。
二是為了便于觀測整個(gè)調(diào)用的邏輯是否符合編排時(shí)的預(yù)期。
怎么做呢？通過一個(gè)x.x.x.x格式的序號。比如，串行就是1，2，3。分支和并行就是2.1，2.2。分支+串行的結(jié)合就是1，2，2.1，2.2，3。

「事件發(fā)送」實(shí)質(zhì)就是負(fù)責(zé)事件流轉(zhuǎn)的邏輯控制，然后發(fā)往「事件處理者」去處理。它決定了是按順序還是分支進(jìn)行？是串行還是并行？

到這就不再展開了，要不然就跑題了，我們下次再細(xì)聊這部分內(nèi)容。

再強(qiáng)調(diào)一下，「事件轉(zhuǎn)換」和「事件發(fā)送」是你在實(shí)現(xiàn)“上帝”（調(diào)停者）功能的時(shí)候需要滿足的最基本的兩個(gè)功能哦。

中心化最大的優(yōu)勢是讓流程更加的“可見”了，同時(shí)也更容易去做一些監(jiān)控類的東西，系統(tǒng)規(guī)模越大，這個(gè)優(yōu)勢產(chǎn)生的效果越明顯。

但是一個(gè)最基本的“上帝”（調(diào)停者）實(shí)現(xiàn)起來還需要考慮數(shù)據(jù)一致性問題，所以，會大大增加它的實(shí)現(xiàn)復(fù)雜度。

因此，如果你面對的場景，業(yè)務(wù)沒有特別龐大，并且是比較穩(wěn)定的，或許用去中心化的方式也是不錯(cuò)的選擇。

這個(gè)模式由于沒有了“上帝”，因此每個(gè)事件處理者需要知道自己的下一個(gè)事件處理器是什么？需要哪些參數(shù)？以及隊(duì)列是哪個(gè)之類的東西。

但是整體結(jié)構(gòu)會變得簡單很多，從“3+2結(jié)構(gòu)”變成了“2+1結(jié)構(gòu)”。

結(jié)構(gòu)簡化背后的復(fù)雜度都跑到事件處理者開發(fā)人員編寫的業(yè)務(wù)代碼中去了。因?yàn)樗枰约喝ヘ?fù)責(zé)「事件轉(zhuǎn)換」和「事件發(fā)送」這兩個(gè)事情。

嗯，改造成事件驅(qū)動架構(gòu)之后，通過「隊(duì)列」的解耦和異步的事件流轉(zhuǎn)，系統(tǒng)的運(yùn)轉(zhuǎn)的確會更順暢。

但是有時(shí)候你可能想進(jìn)行更細(xì)粒度的控制，因?yàn)橐话闱闆r下，一個(gè)service中會處理很多業(yè)務(wù)環(huán)節(jié)，不太會只存在一個(gè)對外接口、一條業(yè)務(wù)邏輯。

在這樣的情況下，很多時(shí)候你可能需要修改的地方僅僅是其中的一個(gè)接口。能不能只修改其中的一部分代碼并且進(jìn)行「熱更新」呢？

微內(nèi)核架構(gòu)（插件架構(gòu)）就適合來解決這個(gè)問題。

顧名思義，微內(nèi)核架構(gòu)的關(guān)鍵是內(nèi)核。所以需要先找到并明確內(nèi)核是什么？然后將其它部分都視作“可拆卸”的部件。

好比我們一個(gè)人，大腦就是內(nèi)核，其它的什么都可以換，換完之后你還是你，但是大腦換了就不是你了。

微內(nèi)核架構(gòu)整體上由兩部分組成：核心系統(tǒng)和插件模塊。

核心系統(tǒng)內(nèi)又包含了微內(nèi)核、插件模塊，以及內(nèi)置的一些同樣以插件形式提供的默認(rèn)功能。

其中，微內(nèi)核主要負(fù)責(zé)插件的生命周期管理和控制插件模塊。

插件模塊則負(fù)責(zé)插件的加載、替換和卸載。

外部的插件如果要能夠接入進(jìn)來并順利運(yùn)行，前提先要有一個(gè)滿足標(biāo)準(zhǔn)接口規(guī)范的實(shí)現(xiàn)。

一個(gè)插件的標(biāo)準(zhǔn)接口至少會有這樣的2個(gè)方法需要具體的插件來實(shí)現(xiàn)：

public interface IPlugin{

    /// 

    /// 初始化配置
    /// 
    void InitializeConfig(Dictionary configs);
    
    /// 

    /// 運(yùn)行
    /// 
    void Run();
    
    ...
}

最后，插件之間彼此獨(dú)立，但核心系統(tǒng)知道哪里可以找到它們以及如何運(yùn)行它們。?

知道了這兩種具有“彈性”的架構(gòu)模式，你該如何判斷什么情況下需要搬出來用呢？

Z哥帶你來分析一下每一種架構(gòu)的優(yōu)缺點(diǎn)，就能發(fā)現(xiàn)它適用的場景。

它的優(yōu)點(diǎn)是：

通過「隊(duì)列」進(jìn)行解耦，使得面對快速變化的需求可以即時(shí)上線，而不影響上游系統(tǒng)。

由于「事件」是一個(gè)獨(dú)立存在的“標(biāo)準(zhǔn)化”溝通載體，可以利用這個(gè)特點(diǎn)銜接各種跨平臺、多語言的程序。如果再進(jìn)行額外的持久化，還能便于后續(xù)的問題排查。同時(shí)也可以對「事件」進(jìn)行反復(fù)的「重放」，對處理者的吞吐量進(jìn)行更真實(shí)的壓力測試。

更“動態(tài)”、容錯(cuò)性好?？梢院苋菀?，低成本地集成、再集成、再配置新的和已經(jīng)存在的事件處理者，也可以很容易的移除事件處理者。輕松的做擴(kuò)容和縮容。

在“上帝”模式下，對業(yè)務(wù)能有一個(gè)“可見”的掌控，更容易發(fā)現(xiàn)流程不合理或者被忽略的問題。同時(shí)能標(biāo)準(zhǔn)化一些技術(shù)細(xì)節(jié)，如「數(shù)據(jù)一致性」的實(shí)現(xiàn)方式等。

它的缺點(diǎn)是：

面對不穩(wěn)定的網(wǎng)絡(luò)問題、各種異常，想要處理好這些以確保一致性，需要比同步調(diào)用花費(fèi)很大的精力和成本。

無法像同步調(diào)用一般，操作成功后即代表可以看到最新的數(shù)據(jù)，需要容忍延遲或者對延遲做一些用戶體驗(yàn)上的額外處理。

那么，它所適用的場景就是：

對實(shí)時(shí)性要求不高的場景。

系統(tǒng)中存在大量的跨平臺、多語言的異構(gòu)環(huán)境。

以盡可能提高程序復(fù)用度為目的的場景。

業(yè)務(wù)靈活多變的場景。

需要經(jīng)常擴(kuò)容縮容的場景。

它的優(yōu)點(diǎn)是：

為遞進(jìn)設(shè)計(jì)和增量開發(fā)提供了方便。可以先實(shí)現(xiàn)一個(gè)穩(wěn)固的核心系統(tǒng)，然后逐漸地增加功能和特性。

和事件驅(qū)動架構(gòu)一樣，也可避免單一組件失效，而造成整個(gè)系統(tǒng)崩潰，容錯(cuò)性好。內(nèi)核只需要重新啟動這個(gè)組件，不致于影響其他功能。

它的缺點(diǎn)是：

由于主要的微內(nèi)核很小，所以無法對整體進(jìn)行優(yōu)化。每個(gè)插件都各自管各自的，甚至可能是由不同團(tuán)隊(duì)負(fù)責(zé)維護(hù)。

一般來說，為了避免在單個(gè)應(yīng)用程序中的復(fù)雜度爆炸，很少會啟用插件嵌套插件的模式，所以插件中的代碼復(fù)用度會差一些。

那么，它所適用的場景就是：

可以嵌入或者作為其它架構(gòu)模式的一部分。例如事件驅(qū)動架構(gòu)中，“上帝”的「事件轉(zhuǎn)換」就可以使用微內(nèi)核架構(gòu)實(shí)現(xiàn)。

業(yè)務(wù)邏輯雖然不同，但是運(yùn)行邏輯相同的場景。比如，定期任務(wù)和作業(yè)調(diào)度類應(yīng)用。

具有清晰的增量開發(fā)預(yù)期的場景。

好了，我們總結(jié)一下。

這次呢，Z哥向你介紹了「事件驅(qū)動架構(gòu)」的兩種實(shí)現(xiàn)模式和實(shí)現(xiàn)思路，以及「微內(nèi)核架構(gòu)」的實(shí)現(xiàn)思路。

并且奉上了對這兩種架構(gòu)模式的優(yōu)缺點(diǎn)與適用場景分析的最佳實(shí)踐。

希望對你有所啟發(fā)。

相關(guān)文章：

分布式系統(tǒng)關(guān)注點(diǎn)（1）——初識數(shù)據(jù)一致性

分布式系統(tǒng)關(guān)注點(diǎn)（2）——通過“共識”達(dá)成數(shù)據(jù)一致性

分布式系統(tǒng)關(guān)注點(diǎn)（3）——「共識」的兄弟「事務(wù)」

作者：Zachary

出處：https://www.cnblogs.com/Zacha...

如果你喜歡這篇文章，可以點(diǎn)一下文末的「贊」。

這樣可以給我一點(diǎn)反饋。: )

謝謝你的舉手之勞。

?關(guān)于作者：張帆（Zachary，個(gè)人微信號：Zachary-ZF）。堅(jiān)持用心打磨每一篇高質(zhì)量原創(chuàng)。歡迎掃描下方的二維碼~。
定期發(fā)表原創(chuàng)內(nèi)容：架構(gòu)設(shè)計(jì)丨分布式系統(tǒng)丨產(chǎn)品丨運(yùn)營丨一些思考。
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「技術(shù)」，送你一份我長期收集和整理的思維導(dǎo)圖。
如果你是運(yùn)營，面對不斷變化的市場束手無策。又或者想了解主流的運(yùn)營策略，以豐富自己的“倉庫”。歡迎關(guān)注我的公眾號「跨界架構(gòu)師」，回復(fù)「運(yùn)營」，送你一份我長期收集和整理的思維導(dǎo)圖。