在做架構(gòu)設(shè)計(jì)的時(shí)候，一般會采用一些架構(gòu)模式，便于設(shè)計(jì)和以后需求變更時(shí)修改代碼。如果設(shè)計(jì)模式選擇得不正確那么很容易造成架構(gòu)的混亂，代碼也會變成怪物。

分層模式

分層模式

分層模式是最常見的模式。我們熟悉的MVC模式就是分層模式的一種。在進(jìn)行架構(gòu)設(shè)計(jì)的時(shí)候，如果一籌莫展，那么分層模式是很好的一種嘗試。在分層模式中，業(yè)務(wù)水平切分，分解到不同的層次中，每個(gè)層次要求僅相鄰的兩個(gè)層次之間可以進(jìn)行交互，不可以跨層次進(jìn)行調(diào)用。一般架構(gòu)會被分成3到5層，具體視架構(gòu)規(guī)模而定，大規(guī)模的架構(gòu)可能會超過5層。在分層模式中，可以很好的解耦，不需要跨層次感知下層的存在。這樣帶來的好處就是，如果因?yàn)槟承┰蚯袚Q了存儲，這個(gè)時(shí)候僅需要修改持久化層就好了，再上面的層次完全感知不到底層的變化。

例外情況

但是這種模式中也會存在些例外，底層有的時(shí)候需要對上上層進(jìn)行部分開放。比如新增加了一個(gè)層次，為了適配可能會對一些請求放行，即允許部分跨級調(diào)用。

分層模式需要注意的時(shí)候，層次必須要做處理，如果當(dāng)前層次僅僅是對請求的轉(zhuǎn)換，那么就要考慮是否層次拆分得有問題。如果僅做請求轉(zhuǎn)換，那么帶來的僅是性能損失和增加新請求時(shí)額外的轉(zhuǎn)換代碼。

事件模式

事件模式1

事件模式2

事件模式有兩種形式：

1.帶有協(xié)調(diào)器。協(xié)調(diào)器作為事件總的入口，監(jiān)聽到事件之后，編排調(diào)用處理器，使事件按照業(yè)務(wù)邏輯進(jìn)行處理和消費(fèi)，即協(xié)調(diào)器監(jiān)聽到事件之后，將事件寫入第一個(gè)處理器，處理器處理完畢后，協(xié)調(diào)器再將下一步的業(yè)務(wù)邏輯事件寫到下一個(gè)處理器，由此完成業(yè)務(wù)邏輯。

2.不帶有協(xié)調(diào)器，業(yè)務(wù)流程的處理靠每個(gè)處理器走下去。一個(gè)請求到來之后，感興趣的處理器會處理事件，并產(chǎn)生一個(gè)新的事件，并將事件發(fā)布到消息隊(duì)列，對新消息感興趣的處理器再繼續(xù)處理新的事件，并再次產(chǎn)生新事件。

這種模式很好的做到了解耦，每個(gè)處理器只需要處理自己感興趣的事件即可。但是因?yàn)檫@些事件都是異步消息，所以容錯(cuò)很難處理。

微內(nèi)核模式

微內(nèi)核模式

微內(nèi)核模式也是一種比較常見的模式，比如我們熟悉的eclipse、MySql存儲引擎等。在微內(nèi)核中，核心的業(yè)務(wù)邏輯包含在內(nèi)核中，插件提供對功能的加強(qiáng)。一般情況下，內(nèi)核邏輯是穩(wěn)定的，新的需求只需要修改某個(gè)插件或者新增插件。插件的邏輯比較專注，只需要關(guān)注插件內(nèi)的邏輯即可。對于內(nèi)核和插件需要規(guī)劃好連接接口。一定要注意，接口要全面，不能僅局限于當(dāng)前，不然業(yè)務(wù)邏輯增加時(shí)再增加接口可能會影響到已經(jīng)存在的插件，使插件不得不進(jìn)行升級。