在當今的軟件領域中，做出正確的架構決策對于確保性能、可擴展性、可維護性和整體成功至關重要。在眾多模式中，事件驅動架構（EDA）和事件溯源（ES）作為復雜軟件系統最受歡迎的兩種選擇之一。雖然可以單獨使用EDA或ES，但它們的結合可能效果驚人。

事件驅動架構與傳統的請求驅動系統相對立，傳統系統中組件通過緊密耦合的方式顯式調用彼此的方法或直接使用同步的API調用。在事件驅動架構中，組件通過事件間接通信，松耦合，促進靈活性、可擴展性和模塊化。

事件溯源，另一個強大的設計模式也利用事件，強調維護事件的時間順序記錄，以實現更好的審計、分析和歷史跟蹤。事件溯源的主要理念是最終一致性。

讓我們來詳細了解它們，并看看如何將它們結合起來，構建一個適合我們使用案例的可擴展架構，有效服務數百萬客戶來自數千商家。

事件驅動架構解釋

事件驅動架構關注系統中事件的流動和處理。事件代表重要的事件或狀態變化，在不同組件之間通信的骨干。在事件驅動系統中，組件（如微服務或函數）通過生成、檢測和消費事件進行異步通信。這種方法促進了松耦合，允許靈活性、可擴展性，并對動態變化作出響應。EDA特別適用于分布式系統，在這些系統中，組件可以獨立操作，在無需直接同步交互的情況下實時對事件做出反應。

EDA的常見使用案例：

1.可擴展的異步處理，即工作器

通過消息代理實現可擴展的異步處理

在任務數量龐大且具有異步處理靈活性的場景中，此配置極具擴展性。在服務A中，組件X生成消息，并將其發布到消息代理（即事件代理）。隨后，這些消息根據需要被許多消費者（稱為工作器）訂閱和處理。事件的來源可能包括cron作業、用戶交互和類似來源。

在傳統系統中，任務通常按順序處理，或者在支持的堆棧中通過多線程支持。然而，即使有多線程支持，只有垂直擴展是可行的選項。

2.消息隊列

消息隊列

這是上述異步處理的一種變體，但是工作器現在位于另一個服務中。這使得服務B能夠在事件數量增加時無縫擴展。到達服務B的事件可能來自不同的服務。

這可用于由服務B負責同時處理大量小任務的體系結構，例如向移動設備提供大量推送通知或短信通知。

3.跨領域通信

這是EDA的更高級版本，系統的多個組件可能對同一消息感興趣，也可能不感興趣。因此，復雜性更多地在代理端，事件通過不同的綁定路由到不同的服務。

跨領域通信

上圖展示了一個示例設置，其中服務A的事件通過不同的隊列路由到服務B和C。請注意，我在這里使用了RabbitMQ的術語：聯邦、交換和虛擬主機。但是，這個設置也可以使用其他消息代理來完成。

事件溯源與CQRS

在傳統的以數據庫為中心的方法中，我們通常存儲實體的當前狀態。相比之下，事件溯源將焦點從存儲應用程序的當前狀態轉移到捕獲并存儲對該狀態的更改的一系列不可變事件。這些事件表示系統中特定的事件或事務，并存儲在事件日志或事件存儲中。

1.關鍵概念

• 事件： 表示系統中狀態更改的不可變記錄。事件捕獲發生了什么，而不是當前狀態。
• 事件存儲： 專門的數據存儲，維護事件的時間順序序列。這允許通過重新播放事件輕松重建系統在任何時間點的狀態。
• 聚合： 將相關事件分組的一致性單元。聚合負責執行業務規則和維護數據完整性。

很多情況下，事件溯源與CQRS結合使用。這將讀模型（查詢模型）和寫模型（命令模型）分開，以實現關注點的分離。在此結合時，還有兩個事件溯源的重要概念：

2.讀模型

專門用于查詢和呈現數據的模型。它對讀取操作進行了優化，并根據寫模型生成的事件構建。讀模型是去規范化的，并根據其服務的查詢需求定制。從相同的事件源，可以構建不同視圖的讀模型，為業務領域提供不同的視角。

3.映射

根據事件存儲中存儲的事件轉換和更新讀模型的過程。

事件溯源與CQRS

在此設置中，事件被填充以記錄由業務流程引起的聚合的每個狀態，并存儲在事件存儲中。隨后，投影從事件存儲中檢索這些事件，并開始將它們轉換為各種讀表。這些表可以以不同的視圖呈現，為業務用戶提供不同的可視化效果。需要強調的是，盡管拉取事件是一種選擇，但投影還可以通過使用消息代理利用發布/訂閱模式，訂閱新事件。

這種設置通過捕獲事件的時間順序序列增強了系統的韌性，為全面的審計跟蹤提供了全面的記錄。因此，該方法允許進行有效的時間查詢，使應用程序在任何給定時間點都可以重建狀態。此外，它通過將數據模型變更與歷史事件日志分開，為業務需求的變化提供了靈活性。

結合CQRS，該機制促進了命令和查詢職責之間的松耦合，提供了韌性和靈活性。

將事件驅動架構和事件溯源結合

如上所述，EDA和ES都為可擴展性和協作提供了非常強大的方式。EDA強調通過事件松耦合通信的組件，而ES捕獲并持久化狀態變更的歷史記錄。因此，如果我們使用ES生成的事件并將其用于EDA，那將是一個自然的組合。

生成的事件不僅可以包含變更的狀態，還可以包含變更的詳細信息。然后，這些事件可以通過消息代理傳輸到另一個服務/組件，并在EDA中被消費。

事件溯源和事件驅動設計的結合

上圖顯示了如何以一種非常直接的方式將ES和EDA結合起來。來自事件存儲的事件可以通過消息代理發布和被不同的服務和組件消費。

結合EDA和ES的優勢

將事件驅動架構（EDA）與事件溯源（ES）結合帶來了顯著的優勢。其中一個主要優勢是系統的響應能力提升。這種設置允許系統快速適應實時變化，在動態環境中效率極高。

另一個關鍵優勢是對狀態變更的全面歷史記錄，有助于詳細的歷史分析，并確保符合規范的強大審計跟蹤。此外，其不可變和可重播的特性使得實時分析、可擴展性和適應不斷變化的分析需求變得更加容易。事件還可以流式傳輸到數據分析流水線或復制到數據湖進行進一步處理。

此外，這種組合固有的靈活性和可擴展性也值得注意。系統可以輕松演變以滿足不斷增長的業務需求，確保長期的可持續性和適應性。

最后，系統的韌性也是一個值得關注的優點。這種設置提供了強大的機制來恢復中斷，確保即使在具有挑戰性的情況下也能保持連續性和可靠性。

應對挑戰

將事件溯源（Event Sourcing）和事件驅動架構（EDA）相結合引入了一系列挑戰，包括協調分布式系統、確保可擴展和高性能的事件存儲，以及管理模式演進。

• 首先，在分布式環境中協調多個微服務的交互引入了一些復雜性，維護正確的事件順序和系統一致性變得復雜。需要精心設計事件流和協調機制，以防止出現事件重復或跨服務的亂序處理等問題。
• 其次，事件存儲的可擴展性和性能是關鍵挑戰。事件溯源依賴于不可變事件，而事件驅動架構依賴于服務之間高效的事件通信。確保事件存儲基礎設施的耐久性和可靠性變得至關重要，特別是在事件在網絡中產生和消費的分布式環境中，這對于維持系統的響應能力尤為重要。
• 第三，解決模式演進和版本控制至關重要。隨著系統的演變，與事件相關的數據模式可能會發生變化。在保持歷史事件完整性的同時平衡向后和向前兼容性是一項挑戰。實施有效的版本控制策略對于避免事件消費者可能根據不同模式版本處理事件的問題至關重要。要克服這些挑戰，需要深思熟慮的設計和技術選擇，創建基于事件溯源和事件驅動架構的彈性和可擴展的架構。
• 最后，但同樣重要的是，操作這種架構并不容易。監控和管理結合了EDA和ES的系統需要新的運營實踐。確保在生產環境中系統的可用性、可靠性和性能可能具有挑戰性。操作消息代理也需要特定的專業知識。我們需要了解所使用的消息代理的優缺點和最佳實踐。

最終思考

盡管存在這些挑戰，將事件驅動架構和事件溯源相融合是一種強大的方法，當得到良好管理時，它提供了一種動態且強大的架構。在設計和實施階段解決這些挑戰對于充分發揮這種組合架構策略的潛力至關重要。