??

事件驅(qū)動架構(gòu)

事件驅(qū)動架構(gòu)（Event Driven Architecture）是一個(gè)流行的分布式異步架構(gòu)模式，可以用來設(shè)計(jì)規(guī)模很大的應(yīng)用程序。基于這種架構(gòu)模式應(yīng)用可大可小。它由高度解耦的，單一目的的事件處理組件組成，可以異步地接收和處理事件。

一個(gè)事件驅(qū)動系統(tǒng)典型地由事件消費(fèi)者和事件產(chǎn)生者組成，事件消費(fèi)者向事件管理器訂閱事件，事件產(chǎn)生者向事件管理器發(fā)布事件。當(dāng)事件管理器從事件產(chǎn)生者那接收到一個(gè)事件時(shí)，事件管理把這個(gè)事件轉(zhuǎn)送給相應(yīng)的事件消費(fèi)者。如果這個(gè)事件消費(fèi)者是不可用的，事件管理者將保留這個(gè)事件，一段間隔之后再次轉(zhuǎn)送該事件消費(fèi)者。

關(guān)鍵概念解釋

事件：系統(tǒng)或組件的狀態(tài)發(fā)生變化時(shí)，系統(tǒng)層發(fā)出的通知。

解耦方式：每個(gè)對象都通過與中間件（Mediator or Broker）實(shí)現(xiàn)與外界的溝通，而不是相互依賴（迪米特法則）。

通訊方式：以消息為載體、通過中間件傳遞通訊。

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

它包括兩個(gè)主要的拓?fù)浣Y(jié)構(gòu)：mediator 和 broker。

• 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)

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

采用Mediator模式的架構(gòu)中，事件一般是復(fù)雜的（包含多個(gè)執(zhí)行單元的合集），而Mediator的責(zé)任就是將該復(fù)合事件拆解為獨(dú)立的子事件，然后發(fā)送到不同類型的子事件處理系統(tǒng)中，由子系統(tǒng)完成獨(dú)立子事件的分發(fā)和處理。

在結(jié)構(gòu)上，Mediator的EDA架構(gòu)包括4個(gè)組件：

• event queues

用于原始事件（分類）存儲，并轉(zhuǎn)發(fā)給Event Mediator，一般是以MQ的形式存在。

• event mediator

用于原始事件的拆解（成為多個(gè)獨(dú)立子事件），并轉(zhuǎn)發(fā)給相關(guān)的Channel；

• event channels

通道（可以理解為細(xì)分的Event Queue），按照事件的類型不同作以劃分。它可以是一個(gè)消息隊(duì)列，提供給特定的Processor查詢，或是消息Topic，發(fā)送特定的廣播。

• event processors

事件處理器，監(jiān)聽特定的Channel，并在捕獲事件后進(jìn)行處理

Mediator的處理過程如下圖所示：

• 客戶端發(fā)送一個(gè)事件到事件隊(duì)列(event queues)中，它用來將事件傳送給event mediator；

• Event mediator收到初始的事件后，會發(fā)送額外的一些異步事件給event channels來執(zhí)行處理的每個(gè)步驟；

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

• Event processors監(jiān)聽event channels,接收事件并處理一些業(yè)務(wù)邏輯。

值得注意的是：

1、在事件驅(qū)動架構(gòu)中有十幾個(gè)甚至幾百個(gè)事件隊(duì)列都很正常。

2、模式本身沒有限定事件隊(duì)列的實(shí)現(xiàn)方式，它可能是一個(gè)消息隊(duì)列，一個(gè)web service或者其它；

3、消息處理器包含實(shí)際的業(yè)務(wù)邏輯。每個(gè)消息處理器都是自包含的，獨(dú)立的，高度解耦的，執(zhí)行單一的任務(wù)。

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

Broker是一種更簡潔的事件驅(qū)動架構(gòu)，不同于上面的結(jié)構(gòu)，它沒有中心的Mediator。

在結(jié)構(gòu)上，Broker的EDA架構(gòu)包括3個(gè)組件：

• Event

  事件消息；

• Event Channel

  消息隊(duì)列或者是Topic，根據(jù)訂閱推送（或是轉(zhuǎn)發(fā)）消息；消息可能被轉(zhuǎn)發(fā)到Event Processor，或是其他的Event Channel中。

• Event Processor

  獲得消息后執(zhí)行處理。它可能是一個(gè)消息的處理終結(jié)點(diǎn)，也可能在處理過程中繼續(xù)下發(fā)消息，或生成新的事件，并被再次提交到Event Channel中，繼續(xù)下一輪的轉(zhuǎn)發(fā)和處理。

如圖所示，它包含兩個(gè)組件broker和 event processor。

• broker中的event channel可以是消息隊(duì)列，消息topic或者它們的復(fù)合形式。

• 每個(gè)event processor負(fù)責(zé)處理事件，發(fā)布新的事件。

架構(gòu)考量

事件驅(qū)動架構(gòu)模式實(shí)現(xiàn)起來相對復(fù)雜，主要是由于它的異步和分布式特性。這可能會帶來一些分布式的問題，比如遠(yuǎn)程處理的可用性，缺乏響應(yīng)，broker重連等問題。

1、分布式的異步架構(gòu)

事件處理器之間高度解耦，軟件的擴(kuò)展性好，事件處理器可以獨(dú)立地加載和卸載，容易部署，同時(shí)性能較好，因?yàn)槭录漠惒奖举|(zhì)，軟件不易產(chǎn)生堵塞。

2、對于單一的邏輯缺乏原子事務(wù)

此模式需要將原子事務(wù)交給一個(gè)事件處理器執(zhí)行，跨事件處理器的原子事務(wù)是很困難的，很難進(jìn)行回滾操作。同時(shí)對于事件處理器的創(chuàng)建，維護(hù)和管理比較困難，事件通常有特殊的約定（數(shù)據(jù)值和格式）。

模式分析

結(jié)合上文分析，事件驅(qū)動架構(gòu)設(shè)計(jì)模式整體分析如下：

• 總體靈活性： 高

• 發(fā)布易用性： 高

• 可測試性： 低

• 性能： 高

• 規(guī)模擴(kuò)展性： 高

• 開發(fā)容易度： 低

- END -

---

「技術(shù)架構(gòu)精進(jìn)」專注架構(gòu)研究，技術(shù)分享

Thanks for reading!

總結(jié)

以上是生活随笔為你收集整理的软件架构模式之事件驱动架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。