Software Architecture Patterns翻譯

最近再看阮一峰的一篇博客提到了一本書《Software Architecture Patterns》（PDF）
,寫的不錯,雖然英語很屎,過年找點事干,試著翻(gu)譯(ge)一下.以下為翻譯的內(nèi)容奥溺，祝我能夠翻譯完，并借此機(jī)會能夠加深對架構(gòu)的認(rèn)識励七。

Software Architecture Patterns 封面

ps:建議看英文原著接箫。
ps:[ ]中的話是我說的矩距。
ps:好吧,我找到已經(jīng)有一個翻譯版本了(https://github.com/hehonghui/android-tech-frontier/tree/master/software-architecture-patterns)
早看到就不翻譯了......

參考:
阮一峰的博客
 鳥窩的博客

介紹

開發(fā)人員在沒有合適架構(gòu)的情況下開始編寫程序是非常普遍的情況. 在這種情況下,大多數(shù)開發(fā)人員和架構(gòu)師會采用傳統(tǒng)分層架構(gòu)模式（也稱為n層架構(gòu)),通過將源碼模塊分成各種包來表示抽象層。不幸的是，這種做法經(jīng)常導(dǎo)致的是一個混亂的源碼結(jié)構(gòu)蒸走，它們?nèi)狈γ鞔_的角色，職責(zé)和彼此之間的關(guān)系貌嫡。這通常被稱為反模式的大泥球比驻。

沒有通過架構(gòu)設(shè)計的應(yīng)用程序通常緊密耦合，脆弱岛抄，難以改變别惦，沒有清晰結(jié)構(gòu)。如果沒有完全理解系統(tǒng)中的每個組件和模塊的內(nèi)部工作原理的情況下夫椭，確定程序的架構(gòu)特性會是非常困難的事情掸掸。關(guān)于程序部署和維護(hù)的基本問題也會很難回答：架構(gòu)是否具有可擴(kuò)展性？應(yīng)用程序的性能如何蹭秋？程序是否能夠應(yīng)對變化扰付？程序如何部署？架構(gòu)的響應(yīng)能力如何感凤？

架構(gòu)模式有助于定義應(yīng)用程序的基本特征和行為悯周。例如，一些架構(gòu)模式非常適合需要高可擴(kuò)展性的應(yīng)用程序陪竿，一些架構(gòu)模式則適用于非常靈活的應(yīng)用程序禽翼。只有了解各種架構(gòu)模式的優(yōu)勢和弱點屠橄，才能夠選擇出滿足自己業(yè)務(wù)特點和目標(biāo)的架構(gòu)模式。

作為一個架構(gòu)師闰挡，你必須證明你的架構(gòu)決策锐墙，特別是當(dāng)涉及到選擇一個特定的架構(gòu)模式或方法。這篇文正的目的是為您提供足夠的信息长酗，以證明你的選擇是OK的溪北。

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

分層架構(gòu)是最常見的架構(gòu)，也是javaee應(yīng)用程序的標(biāo)準(zhǔn)模式夺脾，并被多數(shù)開發(fā)人員了解之拨。這種架構(gòu)適合于傳統(tǒng)IT通信和組織結(jié)構(gòu)，成為大多數(shù)業(yè)務(wù)應(yīng)用程序開發(fā)工作的自然選擇咧叭。

模式描述(Pattern Description)

該架構(gòu)中每一層都包含多個組件并且擁有具體的職責(zé)(例如顯示邏輯蚀乔、業(yè)務(wù)邏輯)。該架構(gòu)并不嚴(yán)格規(guī)定層的類型和層數(shù)菲茬，多數(shù)分層架構(gòu)包含視圖層吉挣、業(yè)務(wù)層、持久化層和數(shù)據(jù)庫層(圖1-1)婉弹。有時睬魂，業(yè)務(wù)層和持久層被合并為單個業(yè)務(wù)層，特別是當(dāng)持久性邏輯（例如镀赌，生成SQL或HSQL）嵌入到業(yè)務(wù)層組件中氯哮。因此，較小的應(yīng)用可以僅具有三個層佩脊，而大的應(yīng)用可以包含五個或更多個層[對于多數(shù)應(yīng)用四層足以]蛙粘。

圖1-1 分層架構(gòu)

分層架構(gòu)模式的每一層在應(yīng)用程序中都有特定的角色和職責(zé)。例如威彰，表示層將負(fù)責(zé)處理所有的用戶界面邏輯出牧，而業(yè)務(wù)層負(fù)責(zé)響應(yīng)表示層的請求并執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。架構(gòu)中的每一層都圍繞需要完成的工作形成抽象歇盼，以滿足特定的業(yè)務(wù)請求舔痕。例如，表示層不需要知道或擔(dān)心如何獲得客戶數(shù)據(jù);它只需要在特定格式的屏幕上顯示該信息豹缀。類似地伯复，業(yè)務(wù)層不需要關(guān)心如何格式化客戶數(shù)據(jù)以在屏幕上顯示或者甚至在客戶數(shù)據(jù)來自哪里;它只需要從持久層獲得數(shù)據(jù)，對數(shù)據(jù)執(zhí)行業(yè)務(wù)邏輯（例如邢笙，計算值或聚合數(shù)據(jù)）啸如，并將該信息傳遞到表示層。

分層架構(gòu)模式的一個強(qiáng)大的功能是組件之間的關(guān)注點分離(separation of concerns)氮惯。特定層中的組件僅處理與該層相關(guān)的邏輯叮雳。例如想暗，表示層中的組件只處理表示邏輯，而業(yè)務(wù)層的組件只處理業(yè)務(wù)邏輯帘不。這種組件分類方式使您可以輕松地在您的架構(gòu)中構(gòu)建有用的模型说莫，并且由于定義明確的組件接口和有限的組件范圍，還可以輕松地使用此架構(gòu)模式開發(fā)寞焙，測試储狭，管理和維護(hù)應(yīng)用程序。

關(guān)鍵概念(Key Concepts)

在圖1-2中捣郊，架構(gòu)中的每個層都標(biāo)記為封閉辽狈。這是分層架構(gòu)模式中非常重要的概念。關(guān)閉意味著當(dāng)請求從一個層移動到另一個層時呛牲，它必須經(jīng)過它的下層稻艰，才能到達(dá)目的層。例如侈净，一個請求從表示層要到數(shù)據(jù)庫層就必須經(jīng)過業(yè)務(wù)層和持久層。

圖1-2 關(guān)閉層和請求訪問

那么為什么不允許表示層直接訪問持久層或數(shù)據(jù)庫層僧凤？畢竟畜侦，從表示層的直接數(shù)據(jù)庫訪問比通過一堆不必要的層來檢索或保存數(shù)據(jù)庫信息要快得多。這個問題的答案在于一個被稱為隔離層(layers of isolation)的關(guān)鍵概念躯保。

隔離層意味著在一個層的變化通常不會影響到其它層的組件旋膳。如果你允許表示層直接訪問持久層，那么持久層的變化將會同時影響業(yè)務(wù)層和表示層途事，從而產(chǎn)生了非常緊密耦合和組件之間的依賴性验懊。當(dāng)需求發(fā)生變化時，這種架構(gòu)將會付出較大的代價尸变。

隔離概念的層還意味著每個層獨(dú)立于其他層义图，并且不需要知道其它層是如何工作的。為了理解這個概念的重要性召烂，考慮一個大規(guī)模的重構(gòu)碱工，將展示框架從JSP（Java服務(wù)器頁面）修改為JSF（Java服務(wù)器面。假設(shè)在表示層和業(yè)務(wù)層之間使用的契約(contracts)（例如奏夫，模型）保持相同怕篷，則業(yè)務(wù)層不受重構(gòu)的影響并且完全和表示層保持獨(dú)立。

雖然封閉的層有助于層次之間的隔離酗昼，從而提高了架構(gòu)的低耦合設(shè)計廊谓，但有時候某些層被打開是有意義的。例如麻削，假設(shè)您要增加一個共享服務(wù)層向業(yè)務(wù)層的組件提供服務(wù)（例如蒸痹，數(shù)據(jù)和字符串實用程序類或?qū)徲嫼腿罩居涗涱悾?在這種情況下創(chuàng)建服務(wù)層通常是一個好主意春弥，因為在體系結(jié)構(gòu)上，它將對共享服務(wù)的訪問限制為業(yè)務(wù)層（而不是表示層）电抚。沒有單獨(dú)的層惕稻，在架構(gòu)上沒有限制表示層訪問這些公共服務(wù)，使得難以管理該訪問限制[這句話沒看懂蝙叛，回頭再看]俺祠。

在該示例中，新服務(wù)層可能駐留在業(yè)務(wù)層之下借帘，同時表明該服務(wù)層中的組件不能被表示層訪問蜘渣。然而，這衍生出一個新的問題肺然，業(yè)務(wù)層需要經(jīng)過服務(wù)層以到達(dá)持久層蔫缸，但這根本沒有意義。這是分層架構(gòu)的一個古老的問題际起，需要通過在架構(gòu)內(nèi)創(chuàng)建開放層來解決拾碌。

如圖1-3所示，在這種情況下街望，服務(wù)層被標(biāo)記為打開校翔，意味著改層可以被繞過。在以下示例中灾前，由于服務(wù)層是打開的防症，因此業(yè)務(wù)層現(xiàn)在允許繞過它，并直接轉(zhuǎn)到持久層哎甲，這是完全合理的蔫敲。

圖1-3 打開層和請求流

利用開放層和封閉層的概念有助于定義層次和請求流之間的關(guān)系，并且向設(shè)計者和開發(fā)者提供理解架構(gòu)內(nèi)的各種層訪問限制的必要信息炭玫。如果不能確定架構(gòu)中的哪些層是開放和封閉的（以及為什么）通常會導(dǎo)致架構(gòu)難以測試奈嘿，維護(hù)和部署的緊密耦合和脆弱。

架構(gòu)例子(Pattern Example)

為了說明分層架構(gòu)的工作原理吞加，考慮一個來自用戶檢索客戶信息的請求指么，如圖1-4所示。黑色箭頭顯示請求流向數(shù)據(jù)庫以檢索客戶數(shù)據(jù)榴鼎，紅色箭頭顯示響應(yīng)返回到屏幕以顯示數(shù)據(jù)伯诬。在該示例中，客戶信息包括客戶數(shù)據(jù)和訂單數(shù)據(jù)（由客戶下達(dá)的訂單)巫财。

圖1-4 分層架構(gòu)例子

如圖所示盗似，customer screen模塊負(fù)責(zé)接受用戶請求并顯示客戶信息，它不知道數(shù)據(jù)在哪里平项，如何檢索赫舒，也不了解數(shù)據(jù)庫悍及，該模塊收到查詢客戶信息的請求后，將該請求轉(zhuǎn)發(fā)到customer delegate模塊接癌，該模塊負(fù)責(zé)了解業(yè)務(wù)層中哪些模塊可以處理該請求心赶，以及如何獲取該模塊需要的數(shù)據(jù)（例如合同數(shù)據(jù)）。業(yè)務(wù)層中的custom object負(fù)責(zé)收集(aggregating)業(yè)務(wù)請求所需的所有信息（該例子中是指客戶信息）缺猛。該模塊調(diào)用customer dao(數(shù)據(jù)訪問對象)模塊在持久層中獲取客戶數(shù)據(jù)缨叫，并且還通過order dao模塊獲取訂單信息。這些模塊又執(zhí)行SQL語句來檢索相應(yīng)的數(shù)據(jù)荔燎，并將其傳回給業(yè)務(wù)層中的customer object模塊耻姥。一旦customer object接收到數(shù)據(jù)，它整合數(shù)據(jù)并將該信息傳遞回customer delegate有咨，然后將該數(shù)據(jù)傳遞到customer screen以呈現(xiàn)給用戶琐簇。

從技術(shù)的角度來看，這些模塊可以有很多實現(xiàn)方式座享。例如婉商，在Java平臺中，customer screen模塊可以是(JSF) Java Server Faces screen渣叛，它和customer delegage可以作為被管理的bean組件据某。業(yè)務(wù)層中的customer object可以是本地Spring bean對象或遠(yuǎn)程EJB3 bean對象。之前示例中的客戶和訂單數(shù)據(jù)可以由POJO诗箍，MyBatis XML Mapper，甚至可以是JDBC調(diào)用或Hibernate查詢返回的數(shù)據(jù)封裝挽唉。在Microsoft平臺中滤祖，customer screen可以是基于.net技術(shù)體系A(chǔ)SP（活動服務(wù)器頁面）模塊，客戶和訂單數(shù)據(jù)可以由為ADO（ActiveX數(shù)據(jù)對象）實現(xiàn)瓶籽。

注意事項(Considerations)

分層架構(gòu)是比較實用并且通用的模式匠童，對于多數(shù)程序是一個良好起點，尤其是當(dāng)您不確定哪種架構(gòu)模式最適合您的應(yīng)用程序時塑顺。當(dāng)選擇這種模式時汤求，你需要從架構(gòu)的角度來考慮一下幾點。

要注意的第一件事是所謂的污水池反模式(architecture
sinkhole anti-pattern)[誰能解釋一下這是啥意思]严拒。這個反模式是這樣的扬绪，請求流簡單的穿過幾個層，每層里面基本沒有做任何業(yè)務(wù)邏輯裤唠，或者做了很少的業(yè)務(wù)邏輯挤牛。例如，假設(shè)表示層響應(yīng)來自用戶的檢索客戶數(shù)據(jù)的請求种蘸。表示層將請求傳遞給業(yè)務(wù)層墓赴，業(yè)務(wù)層簡單地將請求傳遞給持久層竞膳，然后對數(shù)據(jù)庫層進(jìn)行簡單的SQL調(diào)用以檢索客戶數(shù)據(jù)。然后诫硕，數(shù)據(jù)一路返回坦辟，沒有用于聚集(aggregate)，計算或變換數(shù)據(jù)的額外處理或邏輯章办。

每個分層架構(gòu)將具有至少一些落入反模式(architecture
sinkhole anti-pattern)的情況锉走。這里面的關(guān)鍵是分析出屬于此類別的請求的百分比。 80-20規(guī)則通常是一個良好的做法纲菌，以確定是否正在經(jīng)歷這種情況挠日。通常將大約20％的請求作為簡單傳遞處理，80％的請求具有與請求相關(guān)聯(lián)的某些業(yè)務(wù)邏輯翰舌。但是嚣潜，如果您發(fā)現(xiàn)此比例相反，并且大多數(shù)請求是簡單的直通處理椅贱，您可能需要考慮使一些架構(gòu)層打開懂算，需要注意的是這樣會讓層次的耦合度提高，使軟件變得不易改變庇麦。

分層體系結(jié)構(gòu)模式需要注意的另一個問題是计技，它會使得應(yīng)用程序變得monolithic[這個詞不知道怎么翻譯合適]，即使你將表示層和業(yè)務(wù)層分成單獨(dú)的可部署單元山橄。雖然某些應(yīng)用程序不在乎這些問題[規(guī)模小的程序]垮媒，但它的確會帶來部署，通用魯棒性和可靠性航棱，性能和可擴(kuò)展性等方面的一些潛在問題睡雇。

模式分析(Pattern Analysis)

以下內(nèi)容包含分層架構(gòu)模式的常見架構(gòu)特性的評級和分析。每個特性的評級基于適用于該模式的普通場景饮醇。對于此模式與本報告中其他模式如何相關(guān)的并行比較它抱，請參見本報告末尾的附錄A.

靈活性(Overall agility)

級別:低
分析:靈活性是針對不斷變化的環(huán)境做出快速反應(yīng)的能力。雖然可以通過該模式的層次隔離特點來應(yīng)對變化朴艰，但是由于monolithic性質(zhì)和這種模式帶來的組件間緊耦合的特性观蓄，在該體系結(jié)構(gòu)模式中進(jìn)行改變?nèi)匀皇欠爆嵑秃臅r的。

可部署性(Ease of deployment)

級別:低
分析:對于由該模式實現(xiàn)的大型應(yīng)用程序來講祠墅，部署可能會是一個問題侮穿。對組件的一個小改變可能需要重新部署整個應(yīng)用程序（或應(yīng)用程序的大部分），導(dǎo)致需要加班進(jìn)行規(guī)劃毁嗦，調(diào)度和執(zhí)行的部署撮珠。因此，此模式不適合進(jìn)行可持續(xù)部署，進(jìn)一步降低了部署的總體評級芯急。

可測試性(Testability)

級別:高
分析:因為組件都隸屬于某層勺届，而且其他層可以被插樁或者模擬，所以該模式相對容易測試娶耍。開發(fā)人員可以通過模擬展示層中的組件中進(jìn)行業(yè)務(wù)層中組件的測試免姿，或者模擬業(yè)務(wù)層以測試某些展示層組件的功能。

性能(Performance)

級別:低
分析:雖然一些分層架構(gòu)可以很好地執(zhí)行榕酒，但是由于必須經(jīng)歷架構(gòu)的多個層以滿足業(yè)務(wù)請求胚膊，效率較低，所以該模式不適用于高性能應(yīng)用想鹰。

可擴(kuò)展性(Scalability)

級別:低
分析:由于這種模式的緊密耦合和monolithic特點紊婉，使用此架構(gòu)模式的應(yīng)用程序構(gòu)建通常難以擴(kuò)展。您可以通過將層拆分為單獨(dú)的物理部署或?qū)⒄麄€應(yīng)用程序復(fù)制到多個節(jié)點來擴(kuò)展分層體系結(jié)構(gòu)辑舷，但總體來說喻犁，粒度太分散，這使其擴(kuò)展成本昂貴何缓。

開發(fā)容易度(Ease of development)

級別:高
分析:易于開發(fā)獲得相對高的分?jǐn)?shù)肢础，主要是因為這種模式是如此眾所周知的，并且實現(xiàn)起來不太復(fù)雜碌廓。因為大多數(shù)公司通過分層（界面传轰，業(yè)務(wù)，數(shù)據(jù)庫）分離技能集來開發(fā)應(yīng)用程序谷婆，所以這種模式成為大多數(shù)業(yè)務(wù)應(yīng)用程序開發(fā)的自然選擇慨蛙。公司的溝通和組織結(jié)構(gòu)之間的聯(lián)系以及開發(fā)軟件的方式被概述了所謂的 Conway’s law。

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

事件驅(qū)動架構(gòu)模式是一個構(gòu)建高擴(kuò)展性程序的分布式異步架構(gòu)模式纪挎。它還具有高度適應(yīng)性期贫，可用于小型應(yīng)用和大型大型應(yīng)用或者是復(fù)雜的應(yīng)用。事件驅(qū)動架構(gòu)由異步接收廷区、處理事件的組件構(gòu)成，這些組件是高度解耦和職責(zé)單一的贾铝。

事件驅(qū)動的架構(gòu)模式由兩種拓?fù)?topology)方式隙轻，即mediator和broker。當(dāng)你想要在事件內(nèi)編排一些步驟時需要mediator拓?fù)鋄wtf這句話]垢揩，而當(dāng)您想要將事件鏈接在一起而不使用中央mediator時玖绿，你需要broker拓?fù)洹Ｒ驗檫@兩種拓?fù)浣Y(jié)構(gòu)的架構(gòu)特性和實現(xiàn)策略不同叁巨，所以了解每一種拓?fù)浣Y(jié)構(gòu)最適合您的特定情況是非常重要的斑匪。

Mediator拓?fù)?Mediator Topology)

Mediator拓?fù)溥m用于事件需要經(jīng)過多個步驟處理的情況。例如锋勺，進(jìn)行股票交易的一個事件可能需要您首先驗證交易蚀瘸，然后檢查該股票交易是否符合各種合規(guī)規(guī)則狡蝶，將交易分配給經(jīng)紀(jì)人，計算傭金贮勃，最后完成交易贪惹。所有這些步驟需要進(jìn)行精心的安排,從而可以順序的執(zhí)行.

在Mediator拓?fù)溆炙牟糠纸M成:事件隊列,事件mediator,事件通道和事件處理器.事件流從客戶端向事件隊列發(fā)送事件開始，事件隊列用于將事件傳輸?shù)绞录ediator.事件mediator接收事件后,通過向事件通道發(fā)送異步事件來執(zhí)行該事件的每個處理步驟.事件處理器監(jiān)聽事件通,并執(zhí)行特定的業(yè)務(wù)邏輯來處理事件寂嘉。圖2-1說明了事件驅(qū)動架構(gòu)模式的Mediator拓?fù)?

圖2-1 中介拓?fù)?/div>

在事件驅(qū)動架構(gòu)中奏瞬，通常有十幾到幾百個事件隊列。該模式不指定事件隊列組件的實現(xiàn); 它可以是消息隊列泉孩，web服務(wù)端點或者其他什么東西硼端。

該模式中有兩種類型的事件：初始事件和處理事件.初始事件是由調(diào)解器接收的原始事件设联，而處理事件是由調(diào)解器生成并且由事件處理組件接收的事件顽冶。

事件mediator 組件負(fù)責(zé)協(xié)調(diào)初始事件中包含的步驟。對于初始事件中的每一步破喻，事件mediator將特定的處理事件發(fā)送到事件通道订咸，然后由事件處理器接收并處理曼尊。重要的是注意事件mediator實際上不執(zhí)行處理初始事件所必需的業(yè)務(wù)邏輯; 它只知道處理初始事件所需的步驟。

事件通道被事件mediator異步地將初始事傳遞給事件處理模塊. 事件通道可以是消息隊列或消息topics脏嚷，盡管消息topics和mediator拓?fù)渫ǔ７旁谝黄鹗褂玫母嘁恍┞嫫玻沟锰幚硎录梢杂啥鄠€事件處理器（每個事件處理器基于接收到的處理事件執(zhí)行不同的任務(wù)）來處理[我感覺這里消息隊列和消息topics是兩個并列的概念,消息topics是指的是每個事件都能被處理模塊得到,有點像pub/sub,而消息隊列指的是每個事件只能又一個處理模塊得到,有點像pipeline]。

事件處理器組件包含處理處理事件所需的業(yè)務(wù)邏輯代碼父叙。事件處理器是在應(yīng)用或系統(tǒng)中執(zhí)行特定任務(wù)的自包含的(self-contained)神郊，獨(dú)立的，低耦合的架構(gòu)組件[就是指業(yè)務(wù)模塊]趾唱。盡管事件處理器組件的粒度可以從細(xì)粒度（例如涌乳，計算訂單上的銷售稅）到粗粒度（例如，處理保險索賠）,重要的是每個事件處理器組件應(yīng)該執(zhí)行單個業(yè)務(wù)任務(wù)甜癞，而不依賴于其他事件處理器完成其特定任務(wù)[業(yè)務(wù)模塊之間不應(yīng)該產(chǎn)生相互依賴]夕晓。

事件mediator可以以多種方式實現(xiàn). 作為架構(gòu)師，您應(yīng)該了解每個細(xì)節(jié)悠咱，以確保該模式的解決方案符合您的需求蒸辆。

事件mediator的最簡單和最常見的實現(xiàn)是通過開源框架，例如Spring Integration析既，Apache Camel或Mule ESB.這些開源集成中心中的事件流通常通過Java代碼或DSL（領(lǐng)域?qū)Ｓ谜Z言）實現(xiàn)躬贡。對于更復(fù)雜的中介和編排，您可以使用BPEL（domain-specific language）以及BPEL引擎（如開放源代碼Apache ODE）眼坏。 BPEL是一種標(biāo)準(zhǔn)的類似XML的語言拂玻，它描述了處理初始事件所需的數(shù)據(jù)和步驟。對于需要更復(fù)雜的編排（包括涉及人員交互的步驟）的非常大的應(yīng)用程序，您可以使用業(yè)務(wù)流程管理器（BPM）（如jBPM）實現(xiàn)事件仲裁器檐蚜。

理解您的需求并選擇合適的事件mediator實現(xiàn)魄懂，對使用此拓?fù)涞娜魏问录?qū)動成功至關(guān)重要。使用開源集成中心來執(zhí)行非常復(fù)雜的業(yè)務(wù)流程管理編排是不正確的熬甚，就像實施一個BPM解決方案來執(zhí)行簡單的路由邏輯一樣[宰牛不能用殺雞刀,殺雞不能用宰牛刀]逢渔。

為了說明mediator拓?fù)涫侨绾喂ぷ鞯模僭O(shè)你通過保險公司投保乡括，并決定修改肃廓。在這種情況下，初始事件可能被稱為重定位事件(relocation
event)诲泌。處理重定位事件涉及的步驟包含在事件mediator中盲赊，如圖2-2所示。對于每個初始事件步驟敷扫，事件中介器創(chuàng)建處理事件（例如哀蘑，改變地址，重新計算報價等）葵第，將該處理事件發(fā)送到事件信道绘迁，并等待由相應(yīng)的事件處理器處理的處理事件（例如，客戶過程卒密，報價過程等）缀台。該過程繼續(xù)，直到初始事件中的所有步驟都已被處理哮奇。在Event Mediator中,Recalc Quate和Update Claims上面的箭頭代表這兩個步驟可同時進(jìn)行膛腐。

圖2-2 中介模式例子

Broker拓?fù)浼軜?gòu)[broker就是代理的意思]

Broker拓?fù)洳煌趍ediator拓?fù)洌驗闆]有中心事件mediator,消息通過輕量級消息代理（例如鼎俘，ActiveMQ哲身，HornetQ等)[Rabbitmq,zeromq]發(fā)布給業(yè)務(wù)組件。當(dāng)您具有相對簡單的事件處理流贸伐，并且您不需要中心mediator去安排更上層的業(yè)務(wù)流程勘天，此拓?fù)浞浅Ｓ杏肹適合多數(shù)業(yè)務(wù)不太復(fù)雜的系統(tǒng)]。

該拓?fù)渲杏袃煞N主要類型的架構(gòu)組件：代理組件和事件處理器組件捉邢。代理組件可以是一個或者好幾個(centralized or federated)脯丝，并且包含了所有的事件通道,這些通道涵蓋在事件流內(nèi)。代理組件中包含的事件通道可以是消息隊列歌逢，消息主題發(fā)布或兩者的組合巾钉。

此拓?fù)淙鐖D2-3所示翘狱。從圖中可以看出秘案，沒有event-mediator組件來控制和編排初始事件; 相反，每個事件處理器組件負(fù)責(zé)處理事件并發(fā)布事件處理結(jié)果。例如阱高，平衡股票投資組合的事件處理器可以接收稱為股票分割的初始事件赚导。基于該初始事件，事件處理器可以進(jìn)行一些組合重新平衡赤惊，然后向代理發(fā)布稱為重新平衡組合的新事件吼旧，其然后將由不同的事件處理器拾取。注意未舟，可能存在事件由事件處理器發(fā)布但是沒有別的處理器接受的情況出現(xiàn)圈暗。這是常見的,尤其是當(dāng)您正在開發(fā)應(yīng)用程序或提供未來的功能和擴(kuò)展。

圖2-3 代理拓?fù)?/div>

為了說明代理拓?fù)淙绾喂ぷ髟０颍覀儗⑹褂门cmediator拓?fù)渲邢嗤氖纠贝Ｓ捎跊]有中央事件mediator來接收代理拓?fù)渲械某跏际录蛻暨^程組件直接接收事件昼扛，改變客戶地址寸齐，并且發(fā)出該地址改變事件。在此示例中,有兩個對更改地址事件感興趣的事件處理器：報價過程和聲明過程抄谐。報價處理器組件根據(jù)地址更改重新計算新的自動保險率渺鹦，并向系統(tǒng)的其余部分發(fā)布事件指示它做的事情（例如，重新計算報價事件）蛹含。另一方面毅厚，聲明處理組件接收相同的改變地址事件，但是在這種情況下挣惰，它更新未完成的保險聲明并且向系統(tǒng)發(fā)布事件作為更新聲明事件卧斟。這些新事件隨后被其他事件處理器組件拾取，并且事件鏈繼續(xù)通過系統(tǒng)憎茂，直到不再有針對該特定啟動事件發(fā)布的事件.[這不就是pr系統(tǒng)的設(shè)計嘛]

圖2-4 代理拓?fù)淅?/div>

從圖2-4中可以看出珍语，代理拓?fù)浣Y(jié)構(gòu)都是關(guān)于執(zhí)行業(yè)務(wù)功能的事件總線。理解代理拓?fù)涞淖詈梅椒ㄊ菍⑵湟暈橹欣^競賽竖幔。在接力賽中板乙，跑步者持有接力棒并運(yùn)行一定距離，然后將指揮棒交給下一個跑步者拳氢，依此類推直到最后一個運(yùn)動員穿過終點線募逞。在接力賽中，一旦運(yùn)動員交出指揮棒馋评，她就完成了比賽放接。這對于代理拓?fù)湟彩侨绱耍阂坏┦录幚砥髑袚Q事件，它不再參與該特定事件的處理留特。

注意事項(Considerations)

事件驅(qū)動的架構(gòu)模式是一個相對復(fù)雜的模式實現(xiàn)纠脾，主要是由于它的異步的特點玛瘸。當(dāng)實現(xiàn)這種模式時，您必須解決各種分布式架構(gòu)問題苟蹈，如遠(yuǎn)程進(jìn)程可用性糊渊，缺乏響應(yīng)性和代理重新連接邏輯事件代理或mediator失敗。

這種架構(gòu)模式適用于缺少原子性事務(wù)的業(yè)務(wù)流程慧脱。因為事件處理器組件是高度去耦合和分布式的渺绒，所以很難跨越多個業(yè)務(wù)組件的同時去維護(hù)業(yè)務(wù)的事務(wù)特點[ACID]。因此菱鸥，在使用此模式設(shè)計應(yīng)用程序時宗兼，必須不斷考慮哪些事件可以獨(dú)立運(yùn)行或者不單獨(dú)運(yùn)行，并相應(yīng)地計劃事件處理器的粒度氮采。如果您發(fā)現(xiàn)由多個事件處理器構(gòu)成一個工作單元针炉，換句話說,如果您使用分散的處理器來處理不可分割的事務(wù)，在這種情況下,該模式可能不適合您的應(yīng)用程序扳抽。

事件驅(qū)動的架構(gòu)模式的最困難的方面之一可能是事件處理器組件之間契約(contracts)的創(chuàng)建篡帕，維護(hù)和管理。每個事件通常具有與它相關(guān)聯(lián)的契約形式（例如贸呢，數(shù)據(jù)值和數(shù)據(jù)格式).使用此模式來建立標(biāo)準(zhǔn)數(shù)據(jù)格式（例如镰烧，XML，JSON楞陷，Java對象等）并從一開始就建立契約的版本控制策略至關(guān)重要[業(yè)務(wù)模塊之間的接口很重要,也非常容易發(fā)生變化!!!]怔鳖。