架構：常用架構模式

在做架構設計的時候，一般會採用一些架構模式，便於設計和以後需求變更時修改代碼。如果設計模式選擇得不正確那麼很容易造成架構的混亂，代碼也會變成怪物。

分層模式

分層模式

分層模式是最常見的模式。我們熟悉的MVC模式就是分層模式的一種。在進行架構設計的時候，如果一籌莫展，那麼分層模式是很好的一種嘗試。在分層模式中，業務水平切分，分解到不同的層次中，每個層次要求僅相鄰的兩個層次之間可以進行交互，不可以跨層次進行調用。一般架構會被分成3到5層，具體視架構規模而定，大規模的架構可能會超過5層。在分層模式中，可以很好的解耦，不需要跨層次感知下層的存在。這樣帶來的好處就是，如果因為某些原因切換了存儲，這個時候僅需要修改持久化層就好了，再上面的層次完全感知不到底層的變化。

例外情況

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

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

事件模式

事件模式1

事件模式2

事件模式有兩種形式：

1.帶有協調器。協調器作為事件總的入口，監聽到事件之後，編排調用處理器，使事件按照業務邏輯進行處理和消費，即協調器監聽到事件之後，將事件寫入第一個處理器，處理器處理完畢後，協調器再將下一步的業務邏輯事件寫到下一個處理器，由此完成業務邏輯。

2.不帶有協調器，業務流程的處理靠每個處理器走下去。一個請求到來之後，感興趣的處理器會處理事件，併產生一個新的事件，並將事件發佈到消息隊列，對新消息感興趣的處理器再繼續處理新的事件，並再次產生新事件。

這種模式很好的做到了解耦，每個處理器只需要處理自己感興趣的事件即可。但是因為這些事件都是異步消息，所以容錯很難處理。

微內核模式

微內核模式

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