摘要：事件處理器是自包含和獨立的，解耦于架構(gòu)。因其分布式和異步的性質(zhì)，事件驅(qū)動架構(gòu)的實現(xiàn)相對復雜，主要是由于它的異步和分布式特性。微內(nèi)核架構(gòu)微內(nèi)核架構(gòu)模式也被稱為插件架構(gòu)模式。

來自于O"Reilly免費的電子書：Software Architecture Patterns

分層架構(gòu)是最常見的架構(gòu)，也被稱為n層架構(gòu)。多年以來，許多企業(yè)和公司都在他們的項目中使用這種架構(gòu)，它已經(jīng)幾乎成為事實標準，因此被大多數(shù)架構(gòu)師、開發(fā)者和軟件設計者所熟知。比如MVC。

分層架構(gòu)的一個特性就是關注分離(separation of concerns)。在層中的組件只負責本層的邏輯。組件的劃分很容易讓它們實現(xiàn)自己的角色和職責，也比較容易地開發(fā)，測試管理和維護。

我們需要這樣的冗余，即使業(yè)務層沒有處理業(yè)務規(guī)則，也要通過業(yè)務層來調(diào)用數(shù)據(jù)層，這叫分層隔離。對于某些功能，如果我們從表現(xiàn)層直接訪問數(shù)據(jù)層，那么數(shù)據(jù)層后續(xù)的任何變動都將影響到業(yè)務層和表現(xiàn)層。

注意分層的開閉原則。如果某層是關閉的，那么每個請求都要經(jīng)過著一層。相反，如果該層是開放的，那么請求可以繞過這一層，直接到下一層。

分層隔離有利于降低整個應用程序的復雜度。某些功能并不需要經(jīng)過每一層，這時我們需要根據(jù)開閉原則來簡化實現(xiàn)。

分層架構(gòu)是SOLID原則的通用架構(gòu)，當我們不確定哪種架構(gòu)更合適的時候，分層架構(gòu)將是一個很好的起點。我們需要注意防止架構(gòu)陷入污水池反模式（architecture sinkhole anti-pattern）。

在這個模式中，請求流只是簡單的 穿過層次，不留一點云彩，或者說只留下一陣?青煙。比如說界面層響應了一個獲得數(shù)據(jù)的請求。響應層把這 個請求傳遞給了業(yè)務層，業(yè)務層也只是傳遞了這個請求到持久層，持久層對數(shù)據(jù)庫做簡單的SQL查詢獲得用戶的數(shù)據(jù)。這個數(shù)據(jù)按照原理返回，不會有任何的二次處理，返回到界面上。

每個分層架構(gòu)或多或少都可能遇到這種場景。關鍵在于這樣的請求有多少。80-20原則可以幫助你確定架構(gòu)是 否處于反污水模式。大概有百分之二十的請求僅僅是做簡單的穿越，百分之八十的請求會做一些業(yè)務邏輯操 作。然而，如果這個比例反過來，大部分的請求都是僅僅穿過層，不做邏輯操作。那么開放一些架構(gòu)層會比較好。不過由于缺少了層次隔離，項目會變得難以控制。

分層架構(gòu)可以演變?yōu)?strong>巨石應用（Monolith），導致代碼庫難以維護。
將所有功能都部署在一個web容器中運行的系統(tǒng)就叫做巨石型應用。巨石型應用有很多好處：IDE都是為開發(fā)單個應用設計的、容易測試——在本地就可以啟動完整的系統(tǒng)、容易部署——直接打包為一個完整的包，拷貝到web容器的某個目錄下即可運行。

但是，上述的好處是有條件的：應用不那么復雜。對于大規(guī)模的復雜應用，巨石型應用會顯得特別笨重：

要修改一個地方就要將整個應用全部部署（PS：在不同的場景下優(yōu)勢也變成了劣勢）；

編譯時間過長；回歸測試周期過長；

開發(fā)效率降低等。

巨石應用不利于更新技術(shù)框架，除非你愿意將系統(tǒng)全部重寫（代價太高你愿意老板也不愿意）。

我們看一下淘寶前幾年的架構(gòu)的例子：

這是一個標準的分層的架構(gòu)。每一層中又可以詳細的分成更細的層，比如服務層。

圍著著這個主架構(gòu)還有一些外圍的產(chǎn)品。比如監(jiān)控和審計。

不同的階段，不同的業(yè)務場景，不同的業(yè)務復雜度，不同的團隊，適合不同的分層。

有些分層是兼容低端情況（初創(chuàng)公司用起來也很美，還兼顧以后的發(fā)展和迭代），有些不兼容（團隊層次達不到，玩不轉(zhuǎn)）。

分層將導致復雜度的上升。（博弈）

注意接口和邊界。（不然白分）

事件驅(qū)動架構(gòu)（Event Driven Architecture）是一種流行的分布式異步架構(gòu)模式，用于創(chuàng)建可伸縮的應用程序。這種模式是自適應的，可用于小規(guī)模或者大規(guī)模的應用程序。它由高度解耦的，單一目的的事件處理組件組成，可以異步地接收和處理事件。

它包括兩個主要的拓撲結(jié)構(gòu)：調(diào)停者拓撲（Mediator Topology） 和 代理者拓撲（Broker Topology）。Mediator拓撲結(jié)構(gòu)需要你在一個事件通過mediator時精心安排好幾個步驟，而broker拓撲結(jié)構(gòu)無需mediator，而是由你串聯(lián)起幾個事件。這兩種拓撲架構(gòu)的特征和實現(xiàn)有很大的不同，所以你需要知道哪一個適合你。

Mediator拓撲結(jié)構(gòu)適合有多個步驟的事件，需要安排處理層次。

例如購買一只股票，首先會校驗這個交易，校驗股票交易是否符合各種規(guī)定，將它交給一個經(jīng)紀人，計算傭金，最后確認交易。所有這些都安排好各個步驟的順序，決定它們是否串行還是并行。

通常，架構(gòu)主要包含4種組件，事件隊列（Event Queue）、調(diào)停者（Mediator）、事件通道（Event Channel）和事件處理器（Event Processor）。客戶端創(chuàng)建事件，并將其發(fā)送到事件隊列，調(diào)停者接收事件并將其傳遞給事件通道。事件通道將事件傳遞給事件處理器，事件最終由事件處理器處理完成。

事件流是這樣開始的： 客戶端發(fā)送一個事件到事件隊列(event queues)中，它用來將事件傳送給event mediator。Event mediator收到初始的事件后，會發(fā)送額外的一些異步事件給event channels來執(zhí)行處理的每個步驟。Event processors監(jiān)聽event channels,接收事件并處理一些業(yè)務邏輯。

事件調(diào)停者不會處理也不知道任何業(yè)務邏輯，它只編排事件。事件調(diào)停者知道每種事件類型的必要步驟。業(yè)務邏輯或者處理發(fā)生在事件處理器中，事件通道、消息隊列或者消息主題用于傳遞事件給事件處理器。事件處理器是自包含和獨立的，解耦于架構(gòu)。理想情況下，每種事件處理器應只負責處理一種事件類型。

這里有兩種事件：初始事件和處理事件。Mediator會將初始事件編排成處理事件。它沒有具體的業(yè)務邏輯，只是一個協(xié)調(diào)者，負責將初始事件轉(zhuǎn)化成一個或者多個處理事件。

在事件驅(qū)動架構(gòu)中有十幾個甚至幾百個事件隊列都很正常。模式本身沒有限定事件隊列的實現(xiàn)方式。它可能是一個消息隊列，一個web service或者其它。

event channels 既可以是消息隊列，也可以是消息topic，大部分是消息topic，這樣可以由多個消息處理器(event processor)處理同一個消息。

消息處理器包含實際的業(yè)務邏輯。每個消息處理器都是自包含的，獨立的，高度解耦的，執(zhí)行單一的任務。這種模式可能有一些變種。作為架構(gòu)師，你應該理解每個實現(xiàn)的細節(jié)，確保這種解決方案適合你的需求。有一些開源的框架實現(xiàn)了這種架構(gòu)，如Spring Integration, Apache Camel, 或者 Mule ESB。

不像調(diào)停者拓撲，代理者拓撲不使用任何集中的編排，它沒有中心的Mediator。而是在事件處理器之間使用簡單的隊列或者集線器，事件處理器知道處理事件的下一個事件處理器。所有的事件串聯(lián)起來通過一個輕量級的消息broker如RabbitMQ，ActiveMQ，HornetQ等。如果你的消息比較簡單，不需要重新編排，就可以使用這種結(jié)構(gòu)。

如圖所示，它包含兩個組件broker和 event processor。broker中的event channel可以是消息隊列，消息topic或者它們的復合形式。每個event processor負責處理事件，發(fā)布新的事件。

在新浪微博的早期架構(gòu)中，微博發(fā)布使用同步推模式，用戶發(fā)表微博后系統(tǒng)會立即將這條微博插入到數(shù)據(jù)庫所有粉絲的訂閱列表中，當用戶量比較大時，特別是明星用戶發(fā)布微博時，會引起大量的數(shù)據(jù)庫寫操作，超出數(shù)據(jù)庫負載，系統(tǒng)性能急劇下降，用戶響應延遲加劇。

后來新浪微博改用異步推拉結(jié)合的模式，用戶發(fā)表微博后系統(tǒng)將微博寫入消息隊列后立即返回，用戶響應迅速，消息隊列消費者任務將微博推送給所有當前在線粉絲的訂閱列表中，非在線用戶登錄后再根據(jù)關注列表拉取微博訂閱列表。

因其分布式和異步的性質(zhì)，事件驅(qū)動架構(gòu)的實現(xiàn)相對復雜，主要是由于它的異步和分布式特性。我們需要面對很多問題，比如網(wǎng)絡分區(qū)、調(diào)停者失敗、重新連接邏輯等。由于這是一個分布式且異步的模式，如果你需要事務，那就麻煩了，你得需要一個事務協(xié)調(diào)器。分布式系統(tǒng)中的事務非常難以管理，很難找到標準的工作單位模式。

一個考慮是這種模式對于單一的邏輯缺乏原子事務。所以你需要將原子事務交給一個事件處理器執(zhí)行，跨事件處理器的原子事務是很困難的。

最困難的設計之一是事件處理器的創(chuàng)建，維護和管理。事件通常有特殊的約定（數(shù)據(jù)值和格式）。

微內(nèi)核架構(gòu)（Microkernel architecture）模式也被稱為插件架構(gòu)（plugin architecture）模式。可以用來實現(xiàn)基于產(chǎn)品的應用, 比如Eclipse，在微內(nèi)核的基礎上添加一些插件，就可以提供不同的產(chǎn)品，如C++, Java等。

微內(nèi)核包含兩個組件： core system 和 plug-in modules。應用邏輯被分隔成核心系統(tǒng)和插件模塊，可以提供可擴展的，靈活的，特性隔離的功能。

這種模式非常適合桌面應用程序，但是也可以在Web應用程序中使用。事實上，許多不同的架構(gòu)模式可以作為整個系統(tǒng)的一個插件。對于產(chǎn)品型應用程序來說，如果我們想將新特性和功能及時加入系統(tǒng)，微內(nèi)核架構(gòu)是一種不錯的選擇。

微內(nèi)核的架構(gòu)模式可以嵌入到其它的架構(gòu)模式之中。微內(nèi)核架構(gòu)通過插件還可以提供逐步演化的功能和增量開發(fā)。所以如果你要開發(fā)基于產(chǎn)品的應用，微內(nèi)核是不二選擇。

盡管微服務的概念還相當新，但它確實已經(jīng)快速地吸引了大量的眼球，以替代整體應用和面向服務架構(gòu)（SOA）。其中的一個核心概念是具備高可伸縮性、易于部署和交付的獨立部署單元（Separately Deployable Units）。最重要的概念是包含業(yè)務邏輯和處理流程的服務組件（Service Component）

不管你使用何種實現(xiàn)風格和拓撲，有幾個通用的核心概念應用在這種架構(gòu)模式上。首先是分隔發(fā)布單元（separately deployed units）。

如圖所示，每一個微內(nèi)核的組件都被分隔成一個獨立的單元。微服務包含服務組件（service component）。不要考慮微內(nèi)核的單個服務，而是最好考慮服務組件，從粒度上講它可以是單一的模塊或者一個一個大的應用程序，代表單一功能（提供天氣預報或者圖片存儲）。

正確設計服務組件的粒度是一個很大的挑戰(zhàn)。

另一個關鍵概念是微內(nèi)核是分布式的。這意味著服務組件可能是遠程方法（通過JMS, AMQP, REST, SOAP, RMI......等等）。分布式意味著這種模式可以建立大規(guī)模的應用。

另一個值得興奮的特性是它可以從其它有問題的架構(gòu)模式中演化出來，而不是直接創(chuàng)建出來等待問題發(fā)生。當你遇到一些無法解決的問題，特別是互聯(lián)網(wǎng)企業(yè)的規(guī)模擴大時，是很好的引入微服務架構(gòu)的時機。

一般會從兩個模式中演化:

一種就是一開始就是整體的應用，所有的模塊都是緊耦合的。

另外一種是面向服務的架構(gòu)模式(SOA，service-oriented architecture pattern)。

SOA不是不好，但是太昂貴了，不好理解和實現(xiàn)。

這張圖從三個維度概括了一個系統(tǒng)的擴展過程：

x軸，水平復制，即在負載均衡服務器后增加多個web服務器；

z軸擴展，是對數(shù)據(jù)庫的擴展，即分庫分表（分庫是將關系緊密的表放在一臺數(shù)據(jù)庫服務器上，分表是因為一張表的數(shù)據(jù)太多，需要將一張表的數(shù)據(jù)通過hash放在不同的數(shù)據(jù)庫服務器上）；

y軸擴展，是功能分解，將不同職能的模塊分成不同的服務。

從y軸這個方向擴展，才能將巨型應用分解為一組不同的服務，例如訂單管理中心、客戶信息管理中心、商品管理中心等等。

有很多實現(xiàn)微服務的方式。最通用最流行的三個方式是:

API REST-based

applicaiton REST-based

中心化的消息

API REST-based 適合網(wǎng)站提供小規(guī)模的，自包含的服務。很多互聯(lián)網(wǎng)網(wǎng)站都提供這樣的服務，比如OAuth2服務。

application REST-based不同于上面的架構(gòu)，客戶端看到的是web界面或者富客戶端程序，而不是調(diào)用API。UI層獨立發(fā)布，可以訪問服務組件。

中心消息模式，它類似前面的模式，但是使用一個輕量級的消息broker取代RESTful的服務調(diào)用。這個輕量級的broker不會執(zhí)行服務的編排，傳輸和路由，這和SOA不同，不要把它看作SOA的簡化版

內(nèi)部服務之間的通信方式有兩種：基于HTTP協(xié)議的同步機制（REST、RPC）；基于消息隊列的異步消息處理機制（AMQP-based message broker）。

Dubbo是阿里巴巴開源的分布式服務框架，屬于同步調(diào)用，當一個系統(tǒng)的服務太多時，需要一個注冊中心來處理服務發(fā)現(xiàn)問題，例如使用ZooKeeper這類配置服務器進行服務的地址管理：服務的發(fā)布者要向ZooKeeper發(fā)送請求，將自己的服務地址和函數(shù)名稱等信息記錄在案；服務的調(diào)用者要知道服務的相關信息，具體的機器地址在ZooKeeper查詢得到。這種同步的調(diào)用機制足夠直觀簡單，只是沒有“訂閱——推送”機制。

AMQP-based的代表系統(tǒng)是Kafka、RabbitMQ等。這類分布式消息處理系統(tǒng)將訂閱者和消費者解耦合，消息的生產(chǎn)者不需要消費者一直在線；消息的生產(chǎn)者只需要把消息發(fā)送給消息代理，因此也不需要服務發(fā)現(xiàn)機制。

兩種通信機制都有各自的優(yōu)點和缺點，實際中的系統(tǒng)經(jīng)常包含兩種通信機制。例如，在分布式數(shù)據(jù)管理中，就需要同時用到同步HTTP機制和異步消息處理機制。

微服務架構(gòu)解決了無架構(gòu)的整體編碼的應用的問題以及SOA的問題。同時它還可以提供實時的產(chǎn)品發(fā)布。它是一個分布式架構(gòu)，也會有上面分布式的問題。

基于空間的架構(gòu)有時候也被成為基于云的架構(gòu)。

大部分的基于web的應用的業(yè)務流都是一樣的。 客戶端的請求發(fā)送給web服務器，然后是應用服務器，最后是數(shù)據(jù)庫服務器。對于用戶很小時不會有問題，但是負載增大時就會遇到瓶頸（想想搶火車票）。首先是web服務器撐不住，web服務器能撐住應用服務器又不行，然后是數(shù)據(jù)庫服務器。通常解決方案是增加web服務器，便宜，簡單，但很多情況下負載會傳遞給應用服務器，然后傳遞給數(shù)據(jù)庫服務器。有時候增加數(shù)據(jù)庫服務器也沒有辦法，因為數(shù)據(jù)庫也有鎖，有事務的限制。

基于空間的架構(gòu)用來解決規(guī)模和并發(fā)的問題。

基于空間的架構(gòu)最小化限制應用規(guī)模的影響。這個模式來自于tuple space， 分布式共享內(nèi)存想法。要想大規(guī)模，就要移除中心數(shù)據(jù)庫的限制，使用可復制的內(nèi)存網(wǎng)格。應用數(shù)據(jù)保存在所有活動的處理單元的內(nèi)存中，處理單元根據(jù)應用規(guī)模可以加入和移除。因為沒有中心數(shù)據(jù)庫，所以數(shù)據(jù)庫的瓶頸可以解決。

這種模式有兩個組件：處理單元processing unit 和 虛擬化中間件virtualized middleware。

處理單元包含應用程序。小的應用程序可以使用一個處理單元，大的應用程序可以被分隔成幾個處理單元。處理單元還包括數(shù)據(jù)網(wǎng)格。
虛擬化中間件負責管理和通信。處理數(shù)據(jù)的同步和請求。

基于空間的架構(gòu)是一個復雜而昂貴的模式。對于小型的負載可變的web應用很適合，但是對于大型的關系型數(shù)據(jù)庫應用不是太適合。

Software Architecture Patterns

軟件架構(gòu)模式

針對架構(gòu)設計的幾個痛點，我總結(jié)出的架構(gòu)原則和模式

基于微服務的軟件架構(gòu)模式