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

來自于O"Reilly免費(fèi)的電子書：Software Architecture Patterns

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

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

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

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

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

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

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

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

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

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

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

編譯時(shí)間過長；回歸測試周期過長；

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

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

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

這是一個(gè)標(biāo)準(zhǔn)的分層的架構(gòu)。每一層中又可以詳細(xì)的分成更細(xì)的層，比如服務(wù)層。

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

不同的階段，不同的業(yè)務(wù)場景，不同的業(yè)務(wù)復(fù)雜度，不同的團(tuán)隊(duì)，適合不同的分層。

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

分層將導(dǎo)致復(fù)雜度的上升。（博弈）

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

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

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

Mediator拓?fù)浣Y(jié)構(gòu)適合有多個(gè)步驟的事件，需要安排處理層次。

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

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

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

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

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

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

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

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

不像調(diào)停者拓?fù)?，代理者拓?fù)洳皇褂萌魏渭械木幣牛鼪]有中心的Mediator。而是在事件處理器之間使用簡單的隊(duì)列或者集線器，事件處理器知道處理事件的下一個(gè)事件處理器。所有的事件串聯(lián)起來通過一個(gè)輕量級(jí)的消息broker如RabbitMQ，ActiveMQ，HornetQ等。如果你的消息比較簡單，不需要重新編排，就可以使用這種結(jié)構(gòu)。

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

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

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

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

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

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

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

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

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

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

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

不管你使用何種實(shí)現(xiàn)風(fēng)格和拓?fù)洌袔讉€(gè)通用的核心概念應(yīng)用在這種架構(gòu)模式上。首先是分隔發(fā)布單元（separately deployed units）。

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

正確設(shè)計(jì)服務(wù)組件的粒度是一個(gè)很大的挑戰(zhàn)。

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

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

一般會(huì)從兩個(gè)模式中演化:

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

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

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

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

x軸，水平復(fù)制，即在負(fù)載均衡服務(wù)器后增加多個(gè)web服務(wù)器；

z軸擴(kuò)展，是對(duì)數(shù)據(jù)庫的擴(kuò)展，即分庫分表（分庫是將關(guān)系緊密的表放在一臺(tái)數(shù)據(jù)庫服務(wù)器上，分表是因?yàn)橐粡埍淼臄?shù)據(jù)太多，需要將一張表的數(shù)據(jù)通過hash放在不同的數(shù)據(jù)庫服務(wù)器上）；

y軸擴(kuò)展，是功能分解，將不同職能的模塊分成不同的服務(wù)。

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

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

API REST-based

applicaiton REST-based

中心化的消息

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Software Architecture Patterns

軟件架構(gòu)模式

針對(duì)架構(gòu)設(shè)計(jì)的幾個(gè)痛點(diǎn)，我總結(jié)出的架構(gòu)原則和模式

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