我是架構精進之路，點擊上方「關注」，堅持天天爲你分享技術乾貨，私信我回復「01」，送你一份程序員成長進階大禮包。 程序員
事件驅動架構
事件驅動架構（Event Driven Architecture）是一個流行的分佈式異步架構模式，能夠用來設計規模很大的應用程序。基於這種架構模式應用可大可小。它由高度解耦的，單一目的的事件處理組件組成，能夠異步地接收和處理事件。web
一個事件驅動系統典型地由事件消費者和事件產生者組成，事件消費者向事件管理器訂閱事件，事件產生者向事件管理器發佈事件。當事件管理器從事件產生者那接收到一個事件時，事件管理把這個事件轉送給相應的事件消費者。若是這個事件消費者是不可用的，事件管理者將保留這個事件，一段間隔以後再次轉送該事件消費者。設計模式
關鍵概念解釋
事件：系統或組件的狀態發生變化時，系統層發出的通知。微信
解耦方式：每一個對象都經過與中間件（Mediator or Broker）實現與外界的溝通，而不是相互依賴（迪米特法則）。架構
通信方式：以消息爲載體、經過中間件傳遞通信。異步
拓撲結構分類
它包括兩個主要的拓撲結構：mediator 和 broker。分佈式
-
mediator拓撲結構性能
須要你在一個事件經過mediator時精心安排好幾個步驟；學習
-
broker拓撲結構測試
無需mediator，而是由你串聯起幾個事件。
這兩種拓撲架構的特徵和實現有很大的不一樣，因此你須要知道哪個適合你。
Mediator拓撲結構
Mediator拓撲結構適合有多個步驟的事件，須要安排處理層次。
採用Mediator模式的架構中，事件通常是複雜的（包含多個執行單元的合集），而Mediator的責任就是將該複合事件拆解爲獨立的子事件，而後發送到不一樣類型的子事件處理系統中，由子系統完成獨立子事件的分發和處理。
在結構上，Mediator的EDA架構包括4個組件：
-
event queues
用於原始事件（分類）存儲，並轉發給Event Mediator，通常是以MQ的形式存在。
-
event mediator
用於原始事件的拆解（成爲多個獨立子事件），並轉發給相關的Channel；
-
event channels
通道（能夠理解爲細分的Event Queue），按照事件的類型不一樣做以劃分。它能夠是一個消息隊列，提供給特定的Processor查詢，或是消息Topic，發送特定的廣播。
-
event processors
事件處理器，監聽特定的Channel，並在捕獲事件後進行處理
Mediator的處理過程以下圖所示：
-
客戶端發送一個事件到事件隊列(event queues)中，它用來將事件傳送給event mediator；
-
Event mediator收到初始的事件後，會發送額外的一些異步事件給event channels來執行處理的每一個步驟；
-
Event channels 既能夠是消息隊列，也能夠是消息topic，大部分是消息topic，這樣能夠由多個消息處理器(event processor)處理同一個消息。
-
Event processors監聽event channels,接收事件並處理一些業務邏輯。
值得注意的是：
一、在事件驅動架構中有十幾個甚至幾百個事件隊列都很正常。
二、模式自己沒有限定事件隊列的實現方式，它多是一個消息隊列，一個web service或者其它；
三、消息處理器包含實際的業務邏輯。每一個消息處理器都是自包含的，獨立的，高度解耦的，執行單一的任務。
Broker拓撲架構
Broker是一種更簡潔的事件驅動架構，不一樣於上面的結構，它沒有中心的Mediator。
在結構上，Broker的EDA架構包括3個組件：
-
Event
事件消息；
-
Event Channel
消息隊列或者是Topic，根據訂閱推送（或是轉發）消息；消息可能被轉發到Event Processor，或是其餘的Event Channel中。
-
Event Processor
得到消息後執行處理。它多是一個消息的處理終結點，也可能在處理過程當中繼續下發消息，或生成新的事件，並被再次提交到Event Channel中，繼續下一輪的轉發和處理。
如圖所示，它包含兩個組件broker和 event processor。
-
broker中的event channel能夠是消息隊列，消息topic或者它們的複合形式。
-
每一個event processor負責處理事件，發佈新的事件。
架構考量
事件驅動架構模式實現起來相對複雜，主要是因爲它的異步和分佈式特性。這可能會帶來一些分佈式的問題，好比遠程處理的可用性，缺少響應，broker重連等問題。
一、分佈式的異步架構
事件處理器之間高度解耦，軟件的擴展性好，事件處理器能夠獨立地加載和卸載，容易部署，同時性能較好，由於事件的異步本質，軟件不易產生堵塞。
二、對於單一的邏輯缺少原子事務
此模式須要將原子事務交給一個事件處理器執行，跨事件處理器的原子事務是很困難的，很難進行回滾操做。同時對於事件處理器的建立，維護和管理比較困難，事件一般有特殊的約定（數據值和格式）。
模式分析
結合上文分析，事件驅動架構設計模式總體分析以下：
-
整體靈活性： 高
-
發佈易用性： 高
-
可測試性： 低
-
性能： 高
-
規模擴展性： 高
-
開發容易度： 低
- END -
做者：架構精進之路，專一軟件架構研究，技術學習與我的成長，關注並私信我回復「01」，送你一份程序員成長進階大禮包。
往期熱文推薦：
「技術架構精進」專一架構研究，技術分享
Thanks for reading!
本文分享自微信公衆號 - 架構精進之路（jiagou_jingjin）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。