軟件架構(gòu)模式

本文是我在閱讀O'Reilly免費(fèi)的電子書(shū)?Software Architecture Patterns過(guò)程中做的筆記。
首先這本書(shū)非常新，2015年3月30號(hào)訂正后發(fā)布。其次將目前流行的幾種架構(gòu)詳細(xì)進(jìn)行了剖析和比較，除了傳統(tǒng)的N層架構(gòu)外，其它架構(gòu)相當(dāng)?shù)那把亍２⑶?，這篇小書(shū)連帶封面才55頁(yè)，短小精悍，值得一讀。這本書(shū)的作者是 Mark Richards，有30多年行業(yè)經(jīng)驗(yàn)，19年軟件集成，企業(yè)級(jí)架構(gòu)的經(jīng)驗(yàn)，大部分是Java平臺(tái)，也出版了多本書(shū)和論文。

如果你沒(méi)有時(shí)間去閱讀這本書(shū)，那么不妨看一下本篇文章。 我在筆記中將書(shū)中的主要知識(shí)點(diǎn)都記錄下來(lái)。

不先進(jìn)行正式的架構(gòu)設(shè)計(jì)就直接開(kāi)發(fā)對(duì)于程序員來(lái)說(shuō)再普通不過(guò)了。沒(méi)有清晰和很好的架構(gòu)設(shè)計(jì)，大部分程序員和架構(gòu)師實(shí)際上會(huì)采用傳統(tǒng)的分層的架構(gòu)模式， 自然地將代碼模塊分隔成幾個(gè)包(package)。不幸地是，這種做法經(jīng)常導(dǎo)致未能好好組織代碼模塊，這些模塊缺乏清晰的角色，責(zé)任以及相互關(guān)系。這經(jīng)常被成為大泥球反模式。

沒(méi)有進(jìn)行架構(gòu)設(shè)計(jì)的應(yīng)用程序通常是緊耦合的，玻璃心，難以改變，沒(méi)有頭緒。如果不理解應(yīng)用的各個(gè)組件的內(nèi)部工作方式的話(huà)很難看清它的架構(gòu)特征。關(guān)于部署和維護(hù)的問(wèn)題都很難回答：架構(gòu)的規(guī)模如何？程序的性能如何？程序容易修改嗎？程序的部署模型是怎么樣？程序的響應(yīng)如何？

架構(gòu)模式可以幫助你定義程序的基本特征和行為。例如一些架構(gòu)模式很自然讓程序成為大規(guī)模(scalable)的程序。有些模式讓程序變得靈巧敏捷(agile)。知道這些架構(gòu)的特征，優(yōu)點(diǎn)和缺點(diǎn)，你就可以根據(jù)你特定的業(yè)務(wù)需求和目標(biāo)從容的選擇一種架構(gòu)模式。

作為一位架構(gòu)師，你總會(huì)為自己架構(gòu)選擇做解釋?zhuān)绕淠氵x擇一個(gè)特別的架構(gòu)模式的時(shí)候。O'Reilly的這本書(shū)提供了充足的信息來(lái)為你的架構(gòu)選擇提供證明。

分層架構(gòu) (Layered Architecture)

它是最通用的架構(gòu)，也被叫做N層架構(gòu)模式(n-tier architecture pattern)。這也是Java EE應(yīng)用經(jīng)常采用的標(biāo)準(zhǔn)模式?；旧鲜莻€(gè)程序員都知道它。這種架構(gòu)模式非常適合傳統(tǒng)的IT通信和組織結(jié)構(gòu)，很自然地成為大部分應(yīng)用的第一架構(gòu)選擇。

模式描述

在分層架構(gòu)中的組件被劃分成幾個(gè)層，每個(gè)層代表應(yīng)用的一個(gè)功能。分層架構(gòu)本身沒(méi)有規(guī)定要分成多少層，大部分的應(yīng)用會(huì)分成表現(xiàn)層，業(yè)務(wù)層，持久層和數(shù)據(jù)庫(kù)層。小的應(yīng)用有時(shí)候會(huì)將業(yè)務(wù)層和持久層合在一起，更大規(guī)模的應(yīng)用可能會(huì)劃分更多的層，比如調(diào)用外部服務(wù)的層。

每一層都有特定的角色和職能。

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

關(guān)鍵概念

注意每一層都是封閉的。這意味著Request必須經(jīng)過(guò)每一層才能到達(dá)最底下一層。

為什么不允許展示層直接訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)層呢，這樣不是更快嗎？這就是分層架構(gòu)的另一個(gè)特征：層隔離(layers of isolation)。
層隔離的概念意味著你對(duì)任何一層的改變都不會(huì)影響其它層。這很好理解。
層隔離也意味著一個(gè)層的組件并不會(huì)了解其它層的實(shí)現(xiàn)，或者知道很少。 比如業(yè)務(wù)層不需知道你持久層是由hibernate還是mybatis實(shí)現(xiàn)的。
分層架構(gòu)也很容易增加新的層。 比如你想將一些通用的服務(wù)重構(gòu)成一個(gè)服務(wù)層，比如通用圖片處理，遠(yuǎn)程賬戶(hù)審計(jì)等，可以在業(yè)務(wù)層下增加一個(gè)服務(wù)層。它不會(huì)對(duì)展示層造成影響，也不會(huì)改變持久層的代碼。
上面的這個(gè)例子帶來(lái)一個(gè)問(wèn)題，因?yàn)槊恳粚觼G失封閉的，業(yè)務(wù)層不得不通過(guò)服務(wù)層訪(fǎng)問(wèn)持久層，這沒(méi)有天理啊。 所以有時(shí)候你會(huì)創(chuàng)建一個(gè)開(kāi)放的層。這意味著上一層可以繞過(guò)這一層直接訪(fǎng)問(wèn)下一層。

架構(gòu)例子

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

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

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

架構(gòu)考量

分層架構(gòu)是一個(gè)可靠的通用的架構(gòu)，對(duì)很多應(yīng)用來(lái)說(shuō)，如果你不確定哪種架構(gòu)適合你的應(yīng)用，可以用它作為一個(gè)初始架構(gòu)。
第一個(gè)要注意的是污水池反模式(architecture sinkhole anti-pattern).這個(gè)反模式是這樣的，請(qǐng)求流簡(jiǎn)單的穿過(guò)幾個(gè)層，每層里面基本沒(méi)有做任何業(yè)務(wù)邏輯，或者做了很少的業(yè)務(wù)邏輯。比如一些JavaEE例子，業(yè)務(wù)邏輯層只是簡(jiǎn)單的調(diào)用了持久層的接口，本身沒(méi)有什么業(yè)務(wù)邏輯。
每一層或多或少都有可能遇到這樣的場(chǎng)景。關(guān)鍵是分析這樣的請(qǐng)求的百分比是多少。80-20原則可以幫助你決定是否正在遇到污水池反模式。如果你的請(qǐng)求超過(guò)20%，你應(yīng)該考慮讓一些層變成開(kāi)放的。
另一個(gè)需要考慮的是分層架構(gòu)可能會(huì)讓你的應(yīng)用變得龐大，即使你的展示層和業(yè)務(wù)層可以獨(dú)立發(fā)布（比如展示層使用單頁(yè)技術(shù)框架AngularJS, EmberJS）。
它的確會(huì)帶來(lái)一些潛在的問(wèn)題，比如分布模式復(fù)雜，健壯性下降，可靠性，性能和規(guī)模等。

模式分析

總體靈活性： 低
發(fā)布易用性： 低
可測(cè)試性： 高
性能： 低
規(guī)模擴(kuò)展性： 低
開(kāi)發(fā)容易度： 高

事件驅(qū)動(dòng)架構(gòu) (Event-Driven Architecture)

事件驅(qū)動(dòng)架構(gòu)是一個(gè)流行的分布式異步架構(gòu)模式，可以用來(lái)設(shè)計(jì)規(guī)模很大的應(yīng)用程序?；谶@種架構(gòu)模式應(yīng)用可大可小。它由高度解耦的，單一目的的事件處理組件組成，可以異步地接收和處理事件。
它包括兩個(gè)主要的拓?fù)浣Y(jié)構(gòu)：mediator 和 broker。Mediator拓?fù)浣Y(jié)構(gòu)需要你在一個(gè)事件通過(guò)mediator時(shí)精心安排好幾個(gè)步驟，而broker拓?fù)浣Y(jié)構(gòu)無(wú)需mediator，而是由你串聯(lián)起幾個(gè)事件。這兩種拓?fù)浼軜?gòu)的特征和實(shí)現(xiàn)有很大的不同，所以你需要知道哪一個(gè)適合你。

Mediator拓?fù)浣Y(jié)構(gòu)

Mediator拓?fù)浣Y(jié)構(gòu)適合有多個(gè)步驟的事件，需要安排處理層次。
例如購(gòu)買(mǎi)一只股票，首先會(huì)校驗(yàn)這個(gè)交易，校驗(yàn)股票交易是否符合各種規(guī)定，將它交給一個(gè)經(jīng)紀(jì)人，計(jì)算傭金，最后確認(rèn)交易。所有這些都安排好各個(gè)步驟的順序，決定它們是否串行還是并行。
它包括四個(gè)組件：event queues, an event mediator, event channels 和 event processors。

事件流是這樣開(kāi)始的： 客戶(hù)端發(fā)送一個(gè)事件到事件隊(duì)列(event queues)中，它用來(lái)將事件傳送給event mediator。Event mediator收到初始的事件后，會(huì)發(fā)送額外的一些異步事件給event channels來(lái)執(zhí)行處理的每個(gè)步驟。Event processors監(jiān)聽(tīng)event channels,接收事件并處理一些業(yè)務(wù)邏輯。
在事件驅(qū)動(dòng)架構(gòu)中有十幾個(gè)甚至幾百個(gè)事件隊(duì)列都很正常。模式本身沒(méi)有限定事件隊(duì)列的實(shí)現(xiàn)方式。它可能是一個(gè)消息隊(duì)列，一個(gè)web service或者其它。
這里有兩種事件：初始事件和處理事件。Mediator會(huì)將初始事件編排成處理事件。它沒(méi)有具體的業(yè)務(wù)邏輯，只是一個(gè)協(xié)調(diào)者，負(fù)責(zé)將初始事件轉(zhuǎn)化成一個(gè)或者多個(gè)處理事件。
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é)，確保這種解決方案適合你的需求。
有一些開(kāi)源的框架實(shí)現(xiàn)了這種架構(gòu)，如Spring Integration, Apache Camel, 或者 Mule ESB。

Broker拓?fù)浼軜?gòu)

Broker不同于上面的結(jié)構(gòu)，它沒(méi)有中心的Mediator。所有的事件串聯(lián)起來(lái)通過(guò)一個(gè)輕量級(jí)的消息broker如RabbitMQ，ActiveMQ，HornetQ等。如果你的消息比較簡(jiǎn)單，不需要重新編排，就可以使用這種結(jié)構(gòu)。

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

架構(gòu)例子

在新浪微博的早期架構(gòu)中，微博發(fā)布使用同步推模式，用戶(hù)發(fā)表微博后系統(tǒng)會(huì)立即將這條微博插入到數(shù)據(jù)庫(kù)所有粉絲的訂閱列表中，當(dāng)用戶(hù)量比較大時(shí)，特別是明星用戶(hù)發(fā)布微博時(shí)，會(huì)引起大量的數(shù)據(jù)庫(kù)寫(xiě)操作，超出數(shù)據(jù)庫(kù)負(fù)載，系統(tǒng)性能急劇下降，用戶(hù)響應(yīng)延遲加劇。后來(lái)新浪微博改用異步推拉結(jié)合的模式，用戶(hù)發(fā)表微博后系統(tǒng)將微博寫(xiě)入消息隊(duì)列后立即返回，用戶(hù)響應(yīng)迅速，消息隊(duì)列消費(fèi)者任務(wù)將微博推送給所有當(dāng)前在線(xiàn)粉絲的訂閱列表中，非在線(xiàn)用戶(hù)登錄后再根據(jù)關(guān)注列表拉取微博訂閱列表。

架構(gòu)考量

事件驅(qū)動(dòng)架構(gòu)模式實(shí)現(xiàn)起來(lái)相對(duì)復(fù)雜，主要是由于它的異步和分布式特性。這可能會(huì)帶來(lái)一些分布式的問(wèn)題，比如遠(yuǎn)程處理的可用性，缺乏響應(yīng)，broker重連等問(wèn)題。
一個(gè)考慮是這種模式對(duì)于單一的邏輯缺乏原子事務(wù)。所以你需要將原子事務(wù)交給一個(gè)事件處理器執(zhí)行，跨事件處理器的原子事務(wù)是很困難的。
最困難的設(shè)計(jì)之一是事件處理器的創(chuàng)建，維護(hù)和管理。事件通常有特殊的約定（數(shù)據(jù)值和格式）。

模式分析

總體靈活性： 高
發(fā)布易用性： 高
可測(cè)試性： 低
性能： 高
規(guī)模擴(kuò)展性： 高
開(kāi)發(fā)容易度： 低

微內(nèi)核架構(gòu) (Microkernel Architecture)

微內(nèi)核架構(gòu)模式通常又被成為插件架構(gòu)模式，可以用來(lái)實(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ò)展的，靈活的，特性隔離的功能。

模式例子

Eclipse IDE是當(dāng)之無(wú)愧的微內(nèi)核的絕佳例子之一。

架構(gòu)考量

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

模式分析

總體靈活性： 高
發(fā)布易用性： 高
可測(cè)試性： 高
性能： 高
規(guī)模擴(kuò)展性： 低
開(kāi)發(fā)容易度： 低

微服務(wù)架構(gòu)

作為單一整體的程序和面向服務(wù)架構(gòu)的替代者， 微服務(wù)架構(gòu)模式在工業(yè)界很快贏得了地位。這種模式還在進(jìn)化之中，在業(yè)界對(duì)于它的特性和實(shí)現(xiàn)還有些困惑。Oreilly的小書(shū)提供了這種模式關(guān)鍵的概念和基礎(chǔ)知識(shí)，用來(lái)判斷這種架構(gòu)是否適合你的應(yīng)用。

模式描述

不管你使用何種實(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)程方法（通過(guò)JMS, AMQP, REST, SOAP, RMI......等等）。分布式意味著這種模式可以建立大規(guī)模的應(yīng)用。
另一個(gè)值得興奮的特性是它可以從其它有問(wèn)題的架構(gòu)模式中演化出來(lái)，而不是直接創(chuàng)建出來(lái)等待問(wèn)題發(fā)生。當(dāng)你遇到一些無(wú)法解決的問(wèn)題，特別是互聯(lián)網(wǎng)企業(yè)的規(guī)模擴(kuò)大時(shí)，是很好的引入微服務(wù)架構(gòu)的時(shí)機(jī)。
一般會(huì)從兩個(gè)模式中演化。
一種就是一開(kāi)始就是整體的應(yīng)用，所有的模塊都是緊耦合的。另外一種是面向服務(wù)的架構(gòu)模式(SOA，service-oriented architecture pattern)。SOA不是不好，但是太昂貴了，不好理解和實(shí)現(xiàn)。

模式拓?fù)?p style="border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;line-height:2em;">有很多實(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)，客戶(hù)端看到的是web界面或者富客戶(hù)端程序，而不是調(diào)用API。UI層獨(dú)立發(fā)布，可以訪(fǎng)問(wèn)服務(wù)組件。

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

架構(gòu)考量

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

模式分析

總體靈活性： 高
發(fā)布易用性： 高
可測(cè)試性： 高
性能： 低
規(guī)模擴(kuò)展性： 高
開(kāi)發(fā)容易度： 高

基于空間的架構(gòu) (Space-Based Architecture)

基于空間的架構(gòu)有時(shí)候也被成為基于云的架構(gòu)。
大部分的基于web的應(yīng)用的業(yè)務(wù)流都是一樣的。 客戶(hù)端的請(qǐng)求發(fā)送給web服務(wù)器，然后是應(yīng)用服務(wù)器，最后是數(shù)據(jù)庫(kù)服務(wù)器。對(duì)于用戶(hù)很小時(shí)不會(huì)有問(wèn)題，但是負(fù)載增大時(shí)就會(huì)遇到瓶頸（想想搶火車(chē)票）。首先是web服務(wù)器撐不住，web服務(wù)器能撐住應(yīng)用服務(wù)器又不行，然后是數(shù)據(jù)庫(kù)服務(wù)器。通常解決方案是增加web服務(wù)器，便宜，簡(jiǎn)單，但很多情況下負(fù)載會(huì)傳遞給應(yīng)用服務(wù)器，然后傳遞給數(shù)據(jù)庫(kù)服務(wù)器。有時(shí)候增加數(shù)據(jù)庫(kù)服務(wù)器也沒(méi)有辦法，因?yàn)閿?shù)據(jù)庫(kù)也有鎖，有事務(wù)的限制。
基于空間的架構(gòu)用來(lái)解決規(guī)模和并發(fā)的問(wèn)題。

模式描述

基于空間的架構(gòu)最小化限制應(yīng)用規(guī)模的影響。這個(gè)模式來(lái)自于tuple space， 分布式共享內(nèi)存想法。要想大規(guī)模，就要移除中心數(shù)據(jù)庫(kù)的限制，使用可復(fù)制的內(nèi)存網(wǎng)格。應(yīng)用數(shù)據(jù)保存在所有活動(dòng)的處理單元的內(nèi)存中，處理單元根據(jù)應(yīng)用規(guī)模可以加入和移除。因?yàn)闆](méi)有中心數(shù)據(jù)庫(kù)，所以數(shù)據(jù)庫(kù)的瓶頸可以解決。
這種模式有兩個(gè)組件：處理單元processing unit 和 虛擬化中間件virtualized middleware。

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

模式考量

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

模式分析

總體靈活性： 高
發(fā)布易用性： 高
可測(cè)試性： 低
性能： 高
規(guī)模擴(kuò)展性： 高
開(kāi)發(fā)容易度： 低

附錄A

模式分析比較

原文鏈接：http://colobu.com/2015/04/08/software-architecture-patterns/