在做架構(gòu)設(shè)計的時候，一般會采用一些架構(gòu)模式，便于設(shè)計和以后需求變更時修改代碼。如果設(shè)計模式選擇得不正確那么很容易造成架構(gòu)的混亂，代碼也會變成怪物。
分層模式
分層模式
分層模式是最常見的模式。我們熟悉的MVC模式就是分層模式的一種。在進(jìn)行架構(gòu)設(shè)計的時候，如果一籌莫展，那么分層模式是很好的一種嘗試。在分層模式中，業(yè)務(wù)水平切分，分解到不同的層次中，每個層次要求僅相鄰的兩個層次之間可以進(jìn)行交互，不可以跨層次進(jìn)行調(diào)用。一般架構(gòu)會被分成3到5層，具體視架構(gòu)規(guī)模而定，大規(guī)模的架構(gòu)可能會超過5層。在分層模式中，可以很好的解耦，不需要跨層次感知下層的存在。這樣帶來的好處就是，如果因為某些原因切換了存儲，這個時候僅需要修改持久化層就好了，再上面的層次完全感知不到底層的變化。
例外情況
但是這種模式中也會存在些例外，底層有的時候需要對上上層進(jìn)行部分開放。比如新增加了一個層次，為了適配可能會對一些請求放行，即允許部分跨級調(diào)用。
分層模式需要注意的時候，層次必須要做處理，如果當(dāng)前層次僅僅是對請求的轉(zhuǎn)換，那么就要考慮是否層次拆分得有問題。如果僅做請求轉(zhuǎn)換，那么帶來的僅是性能損失和增加新請求時額外的轉(zhuǎn)換代碼。
事件模式
事件模式1
事件模式2
事件模式有兩種形式：
1.帶有協(xié)調(diào)器。協(xié)調(diào)器作為事件總的入口，監(jiān)聽到事件之后，編排調(diào)用處理器，使事件按照業(yè)務(wù)邏輯進(jìn)行處理和消費，即協(xié)調(diào)器監(jiān)聽到事件之后，將事件寫入第一個處理器，處理器處理完畢后，協(xié)調(diào)器再將下一步的業(yè)務(wù)邏輯事件寫到下一個處理器，由此完成業(yè)務(wù)邏輯。
2.不帶有協(xié)調(diào)器，業(yè)務(wù)流程的處理靠每個處理器走下去。一個請求到來之后，感興趣的處理器會處理事件，并產(chǎn)生一個新的事件，并將事件發(fā)布到消息隊列，對新消息感興趣的處理器再繼續(xù)處理新的事件，并再次產(chǎn)生新事件。
這種模式很好的做到了解耦，每個處理器只需要處理自己感興趣的事件即可。但是因為這些事件都是異步消息，所以容錯很難處理。
微內(nèi)核模式
微內(nèi)核模式
微內(nèi)核模式也是一種比較常見的模式，比如我們熟悉的eclipse、MySQL存儲引擎等。在微內(nèi)核中，核心的業(yè)務(wù)邏輯包含在內(nèi)核中，插件提供對功能的加強(qiáng)。一般情況下，內(nèi)核邏輯是穩(wěn)定的，新的需求只需要修改某個插件或者新增插件。插件的邏輯比較專注，只需要關(guān)注插件內(nèi)的邏輯即可。對于內(nèi)核和插件需要規(guī)劃好連接接口。一定要注意，接口要全面，不能僅局限于當(dāng)前，不然業(yè)務(wù)邏輯增加時再增加接口可能會影響到已經(jīng)存在的插件，使插件不得不進(jìn)行升級。
