架構模式的深刻研究——事件總線模式

通過對多個有關事件總線模式的文檔介紹的閱讀，對事件總線模式有了必定的瞭解，並做出以下總結：

1、 事件總線模式主要是處理事件，包括4個主要組件：事件源、事件監聽器、通道和事件總線。消息源將消息發佈到事件總線上的特定通道上。偵聽器訂閱特定的通道。偵聽器會被通知消息，這些消息被髮布到它們以前訂閱的一個通道上。

使用場景：安卓開發、通知服務

優勢：新的發佈者、訂閱者和鏈接能夠很容易地添加。對高度分佈式的應用程序有效。

缺點：可伸縮性多是一個問題，由於全部消息都是經過同一事件總線進行的。

2、基於事件驅動的分佈式異步架構模式多用於構建高可伸縮的反應式應用程序，適用於各類從簡單到複雜的應用場景。它的核心思想是去耦合，將消息的發送和接收分開，實現異步處理消息事件。

事件總線是實現基於事件驅動模式的方式之一，或者能夠將其稱爲「Broker Topology」。事件發送者將事件消息發送到一箇中心 broker 上，事件訂閱者向中心 broker 訂閱和接收事件，而後再處理接收到的事件。固然，訂閱者不只能夠接收和消費事件，它們自己也能夠建立事件，並將它們發送到事件總線上。下面列出了 4 種事件總線的實現方式，並對它們的優缺點進行了總結。

 

1. 向全部的訂閱者發送事件

事件總線直接將輸入事件（紅色箭頭）發送給訂閱者（藍色方塊）

參與者

事件總線、訂閱者（事件處理器）、事件建立者

實現

事件建立者向事件總線發送事件，事件總線將收到的事件發送給全部的訂閱者。訂閱者既能夠處理接收到的事件，也能夠建立新事件，而後把它們發送給事件總線。事件總線不關心訂閱者是否成功接收到消息。

功能需求

通知、訂閱、退訂。

優點

實現起來很簡單。

不足

事件總線須要將每個事件消息複製一份給訂閱者，也就是說，若是有1000個訂閱者，每個事件都會有1000份拷貝，這樣會佔用大量的內存。

事件總線不保證消息傳遞的可靠性，它會嘗試給訂閱者發送消息，並且只會嘗試一次，若是出現錯誤，好比網絡鏈接錯誤，訂閱者可能就會收不到消息。 
另外，事件總線不負責過濾消息，因此訂閱者須要本身實現過濾邏輯。

 

2. 向全部訂閱者發送事件影子

事件總線和事件存儲及事件觀察者

參與者

事件總線、事件建立者、訂閱者、事件存儲（Event Store）、事件觀察者（Event Watcher）

實現

事件總線在收到事件建立者發送過來的事件後，把事件保存到事件存儲裏，而後將事件影子（Event Shadow，也就是對原始事件的引用）發送給全部的訂閱者。訂閱者根據事件影子從事件存儲裏獲取事件數據，再對數據進行處理。

事件總線爲每個事件建立一個事件觀察者，觀察者持有訂閱者列表，當全部的訂閱者都接收到消息後，觀察者負責把事件從事件存儲裏刪除。

事件總線仍然不保證訂閱者必定會收到全部事件影子。若是有訂閱者接收消息失敗，相應的觀察者就會被標記爲「skipped」。

功能需求

通知、訂閱、退訂、保存/刪除/獲取、標記完成/跳過

優點

由於事件消息被保存在事件存儲裏，發送給訂閱者的只是事件引用，因此佔用內存會小不少。

不足

訂閱者須要調用額外的方法，好比在收到事件影子以後要調用方法去獲取事件數據，在處理完事件後還要調用方法通知事件總線已完成處理，或者通知事件總線跳過某個事件。另外，在事件總線端還要實現事件存儲和事件觀察者。這個對事件存儲的實現要求比較高，若是訂閱者數量不少，事件存儲的讀負載會很重，並且在寫入事件時是阻塞式的。

這種實現方式仍然不會爲訂閱者過濾事件，因此訂閱者仍是須要本身實現事件過濾。

3. 向通過過濾的訂閱者發送事件影子

第三種實現方式與第二種是同樣的，只不過不是將事件影子發送給全部訂閱者，而是發送給通過過濾的訂閱者，也就是說只發送給其中的一部分訂閱者。事件總線須要記錄訂閱者感興趣的主題，在這裏可使用正則過濾器爲訂閱者過濾主題。

這種方式的優點與不足和第二種也是同樣的，只是多了事件過濾功能。

4. 按順序傳遞

爲了保證順序傳遞，能夠對事件進行分區。關於如何經過分區來保證順序傳遞，能夠參考Kafka的論文，基本原理是讓消費者消費屬於本身的分區。

不足

動態增長分區或減小分區會變得很困難，並且須要本身實現分區器，消費者的實現也很複雜。