首先我們看看一個案例，一家娛樂公司價值10億美元項目需要涉及創建一個新的系統以及集成現有系統，主要問題是如何從一個系統狀態變化傳播到其他系統的生態系統？例如,如果一個客人購買一張票，我們怎么知道這種票是否存在？屬于哪個特定的客人？這樣我們可以顯示他的資料嗎?

我們采用的方式是將這些系統使用事件驅動架構。從高一層來看，這意味著當有趣的事情發生在系統的記錄(SOR)中，我們要求系統能夠發出事件來標識當前資源已經被改變。在上述的背景下具體售票的例子中：當一個客戶購買一張票，我們需要票務系統發出"創造"事件，標識這張新票，然后,通知其他系統創建了新票。這是圖1所示。

使用EDA應用程序有不同的實現，最常見的是利用企業服務總線(ESB)。ESB提供了標準的機制系統用來發布消息給ESB，系統也可以從ESB訂閱消息。消息有兩種形式：

隊列Queue: 隊列方便點到點消息傳遞,這意味著消息生產者可以發送消息到一個消息消費者

主題Topic: 主題使用發布-訂閱消息傳遞，這意味著消息生成方可以將消息發布到零個或多個訂閱者

隊列和主題有自己的特定的業務場景。例如,如果你想要一個消息只處理一次，那么就使用一個隊列。如果你想發送一個消息到一個特定的目的地，也是使用一個隊列。如果你想要一個消息被任意數量的其他系統處理，那么使用一個主題。

因此,在EDA我們傾向于主題,因為我們想啟用新系統能夠訂閱改變現有系統，而無需改變現有的系統。因為消息生產者不需要知道對其訂閱用戶，那么我們說這兩個系統之間的關系是松散耦合的。換句話說，如果我們添加一個新的系統，比如說一個分析系統，用來跟蹤不同的客人的信息，我們就不需要更新票務系統來支持分析系統，分析系統只要訂閱由票務系統的主題事件即可。圖2顯示了這個圖形。

圖2顯示了當票務系統引發一個事件，客戶檔案服務以及分析引擎將接收這個事件。新系統可以訂閱票務系統的主題和集成它，這些都不需要改變票務系統。

隊列必須保證能交付，這意味著當一個消息發布到隊列中，ESB將Hold住消息在隊列中直到有人從隊列中刪除它。另一方面主題是發布消息給所有用戶，然后消息即消失。這將導致另一個問題：如果你的主題偵聽器死機了呢？你會錯過了事件嗎？在正常情況下,答案是"是的"，你將錯過，這就是一個問題！幸運的是，大多數消息代理(ESB的一部分，用來管理消息)有持久訂戶的概念。如果一個用戶注冊成為持久訂戶，那么ESB將Hold住這一信息，直到你的主題偵聽器能夠接收消息。從操作的角度來看，您需要確保所有關心主題的監聽器能夠接收所有事件，那么就要以持久durable方式訂閱主題。

輕量和重量事件

事件本身有兩種形式：

輕量Light-weight

重量Heavy-weight

輕量級事件包含改變資源的標識符,然后需要監聽器回去調用SOR獲得資源的詳細信息。如圖3所示：

重量事件包含事件細節，這樣回調SOR記錄就不需要：

所以你應該使用輕量級還是重量級事件?這,有一個權衡。事件是不能保證同一時間到達-事件是異步的。所以如果票務系統發布以下事件:

創建票

更新票記錄

將額外特性加入票

但是你接受的事件是如下順序：

創建票

將額外特性加入票

更新票記錄

如果事件擔負的機票信息(重量級事件)，那，您將創建機票，將特性添加到票，然后覆蓋機票已經更新的狀態，這樣機票最后狀態就不包括新添加的特性。結果是，你不會再有票的當前狀態。怎么解決這個問題？方法之一是要求事件的時間戳，然后做一些本地處理，以確保你有最新的事件和丟棄任何過早的事件。

這里存在一個大量的細節工作且容易出錯，所以更理想的解決方案是使用一個輕量級的事件和回調。在這個例子中，票務系統是票的"真理之源"，所以，當你進行回調，你將會得到保證總會得到票的正確狀態。但這是有代價的，即你的票務系統需要能夠支持因為回調產生額外的負載。

在當前這個項目中，我們有兩個場景：新系統可以支持輕量級事件產生的額外負載，遺留系統,不支持重量級事件生成的額外的負載。作為DevOps工程師，你是在最好讓您的開發人員知道這個建議，因為你了解系統是否可以支持額外的負載。但同時，如果系統可以支持額外的負載和選擇輕量級事件，你需要計劃基礎設施可以支持負載。它并不是小事：在我們的項目中,生成的票務系統每天超過500 k的事件,這是一個大量的額外負載!

工作流程和手工監聽

大多數esb提供工作流的概念，一個工作流當接受到一個事件然后執行可配置的動作。如圖4所示：

結合面向服務的體系結構與ESB工作流將會很強大，工作流可以處理事件，執行轉換并調用服務。它使事件處理可配置而不是編碼。

使用ESB工作流的好處是：ESB在其內部進行事件處理，因此它通常執行性能的比自己編寫監聽器要好。這需要權衡，如果你使用ESB這種方式，你會失去可移植性；因為應用程序業務邏輯被包含在ESB中，所以如果你需要將應用程序移動到另一個環境中，需要將ESB一起移動。如果另一個網站是使用不同的ESB，或者他們不想采用ESB，那么所有的業務邏輯需要重寫。

另一種選擇是在代碼中手工編寫監聽器。這些偵聽器訂閱適當的主題和獨立于ESB執行業務邏輯。在這種情況下，您可能不需要一個完整的ESB，只要message broker即可，通常更便宜。但這種可移植性會以犧牲性能為代價。

作為DevOps工程師，您需要知道開發人員是選擇自己手工編寫函數，如果他們使用工作流，那么你要為ESB需要添加額外的處理能力。如果他們要手工編寫監聽器，那么你需要考慮esb和聽眾之間的額外網絡帶寬，你需要添加足夠的處理能力來實現偵聽器。

分割

這取決于你有多少系統集成，您的ESB可能會從分割中受益性能提高。分割基本上意味著你分配資源單獨給特定應用程序組件，這樣一個系統的負載不影響另一個系統的性能。在我們的大型項目中我們開始沒有分割，但負載非常高，我們最終創建了8段不同系統，并且分離不同系統之間的事件。設定應用程序擁有自己的消息資源這樣有助于負載隔離。

ESB替換

雖然esb是實現EDA主要機制，但它們不是城里唯一的游戲。正如您可能想到的,：esb有復雜的配置和管理，每天傳遞數十萬甚至數百萬消息。還有一種方法，我們使用一個Atom Feed。Atom Syndication Format,下一代的RSS(Really Simple Syndication),是一個標準的格式發布web提要和遵循一個非常HTTP-centric的方法。SOR通過Atom Feed發布事件，消費者訂閱接收事件。這種模型非常簡單，會不再需要ESB，但就像所有技術一樣都有一個權衡：延遲。EDA應用程序會有一個隱式的延遲。也就是在SOR記錄改變和其他系統變化之間有延遲，但延遲會很小，當使用拉取Polling機制時，延遲取決于拉取的間隙時間。

還有其他系統支持處理事件，如Akka和Apache Storm。