軟件架構模式
缺少規范架構的程序通常會變得緊耦合、脆弱、難以更改，缺少清晰的發展方向和願景。這本小書用50多頁介紹了常用的5種常見架構模式，相信不管是大牛還是萌新都會有所收獲，特別是對我這種偏愛系統設計、架構、模式的人。當然，此書也只是高層的討論，能夠起到歸納總結、理順思路的作用。如果想實際應用，還是需要從代碼入手，站在架構模式的角度分析優秀的項目源碼。
分層架構(Layered/N-tier Architecture)
分層架構的組件按垂直模式組織成多層，每一層表現為程序的一種角色。分層架構大概是最普遍的架構了，寫過java web的人大概都規規范范地寫過那什么dao、service、controller之類的包，每一層都是圍繞一種功能的抽象，各負其責，有利於系統開發、測試、管理和維護。分層架構圖如下：
一般來說，請求從上到下，下一層為上一層提供服務。這樣做得好處是起到了解耦和封裝的好處。然而有時候我們確實需要跨層訪問，於是乎可以做一些退步，讓某些層open。當然，這也是對結構的一種破壞。這種架構的一種典型反模式是，在某一層中只用少量的邏輯就到了下一層。解決辦法是使用二八定律，如果大約20%的請求很簡單的穿過該層，80%還是有些必要的邏輯，那么還是可以接受的，如果差距得大的話就得考慮將該層改為open。分層架構雖然簡單但很實用，很多優秀的程序都多多少少用到這種模式。
事件驅動架構（Event-Driven Architecture）
事件驅動架構是使用高解耦、單一用途的事件處理組件來異步接收和處理事件的架構。事件驅動也是十分流行的架構，特別是在分布式、異步系統中。這種架構模式有兩種拓撲結構，mediator和broker。mediator結構通常用在需要對一個事件組合多個步驟處理的情況，通過一個中心mediator來實現。broker結構通常用在需要將事件串在一起，並不通過中心化的mediator的情況。
Mediator結構
如下為mediator結構：
mediator結構包括4類組件：event queues， event mediator，event channels和event processors。事件首先到達event queue，通過event mediator接收的事件稱為init event，然后經過編排組合，生成process event並異步地發送到event channels中。event processors將從event channels中取出事件並進行響應。event queue組件可以是消息隊列、web服務端點等。需要注意的是，event mediator並不執行業務邏輯來編排process event，它只是知道處理init event的步驟，然后將每一步的執行事件異步發送到event channels。event mediator通常使用開源工具來實現（Spring Integration、Apache Camel或Mule ESB等）。event processor通常只處理單一的業務邏輯，並相互獨立。
Broker結構
如下為broker結構：
broker結構與mediator結構的不同之處是沒有event mediator組件。消息像一條鏈一樣通過輕量級的message broker被分發。當你需要簡單的事件處理流程，而不想使用事件編排中心的話，這是一個很好的選擇。該結構包含兩類主要組件：broker和event processors。broker包含了所有的event channels。與mediator結構不同，事件被一個event processor處理后會重新發布一個新的事件給broker，然后其他感興趣的processor就會進行處理。
事件驅動模型由於其天然的異步性，是一種相對復雜的模式。由於其異步性，很難保證事務的原子性。如果你的業務邏輯中很少有原子性的事務則可以選擇它。除此之外，事件驅動架構的代碼編寫、維護、管理都相對困難。盡管事件驅動有如此多麻煩問題（編程要求高），但是其異步特性和事件處理的機制是很多程序的首選。
微內核架構(Microkernel Architecture)
微內核架構又稱為插件架構，它能夠像添加插件一樣添加系統特性。想想眾多IDE可以安裝插件就知道它的好用了。圖示如下：
它包含兩類組件：core system和plug-in components。core system包含程序的最小化、最基本的系統功能。plug-in component是獨立的插件，用來擴充系統功能的。core system需要知道如何獲取到plug-in，並知道如何使用它們，一類通用的方式是一種plug-in注冊表的方式，其中包含plug-in的基本信息，如何控制，數據格式等等。core system和plug-in component之間要有某種contract，這樣core system就不要編寫特定的代碼來適配。
微內核架構可以作為一種嵌入式的或者說作為其他架構模式一部分的架構模式，如果你不能一次性實現整個系統架構，那么微內核架構模式可以作為你的設計的一部分。
微服務架構(Microservices Architecture)
微服務體系結構的每個組件都可以作為一個單獨的單元進行部署，允許通過有效且精簡的交付管道更容易地進行部署。微服務架構由於其實用性，成為代替單體架構、面向服務架構的選擇，並獲得了廣泛的關注。圖示如下：
service component包含了一到多個模塊來實現單一的功能，設計service component的粒度是設計微服務架構的挑戰之一。微服務將應用分離成多個部署單元，使每一個單元都可以單獨開發、部署、測試等，極大提高了開發效率、可測試性、可維護性等，可能這也是眾廠商追捧的原因。微服務是由面向服務(SOA)發展而來的，但是相比之下微服務通過簡化服務概念、減少服務編排需求、簡化服務接入等方法讓其更輕量。作者根據3種不同的使用場景又將微服務划分為API REST-based topology、application REST-based topology、centralized messaging topology三種結構。但是總體架構還是上圖的樣子。
基於空間的架構(Space-Based Architecture)
基於空間的架構模式也叫雲架構模式(cloud architecture pattern)，是設計用來解決擴展性和並發性問題的。在互聯網應用中，可以簡單分為web server、application server和database server三類，請求從前到后經過三類服務器，當流量劇增時，三類服務器都可能遇到瓶頸，特別是database，最難擴展，且決定了並發量。此模式性通過去掉中心化database server，使用可復制的內存數據網格來實現高擴展性。程序數據都存儲在內存中，在活動的process units中相互復制。process units可以在流量激增時動態啟動來應對高負荷。架構圖如下：
這種模式有兩類主要組件：process unit和virtula Middleware。process unit中包含了應用程序的組件，小的web應用可能將所有內容塞到一個unit中，大的web應用可能將功能分開部署到不同的unit中。通常來說，process unit中包含了應用組件、內存數據網格和用於失效備援的異步的持久化存儲組件。同時也包括一個復制引擎（replication engine）被virtual middleware使用來與其他unit交換數據。virtual middleware用於管理和通訊，包括了數據同步和請求處理的相關組件，有messaging grid、data grid、process grid和deploy manager。這些組件可以自己編碼實現，也可以購買三方產品。
- messaging grid：管理輸入請求和會話（session）信息。該組件決定請求分發到那個unit中。
- data grid：此模式中最重要且起決定性作用的組件。當數據更新時，該組件與unit中的replication engine交互。由於messaging grid可能將請求分發到任意一個unit中，所以unit中的數據必須時一致的，在實際中，數據的交互是並行的異步的，並且速度非常快（當然，即便很快，也需要解決一致性問題）。
- processing grid：如果unit是中存放了程序的一部分內容，那么由該組件來選擇轉發到不同類型的unit。
- deployment manager：管理unit的動態啟動和關閉，該組件監視流量情況，動態執行操作。該組件是實現可變擴展性的決定性組件。
總結
最后，是一個架構模型的總結表，在程序設計中可以根據實際需求來選擇不同的軟件架構模式。
