在 CQRS“架構”中使用 EventStore 是否不需要使用消息總線？

Question

我對范式和相關架構（例如 CQRS）非常陌生。 我開始了一個我認為適合這種技術的項目。 我發現在項目中使用 EventStore 很有趣，但我在文檔中讀了一些，我看到使用 EventStore 使得沒有必要擁有消息總線，因為 EventStore 本身允許訂閱事件 - 這是正確的嗎？ 在 EventStore 的頂部實現總線會有一些優勢嗎？

Answer 1

消息總線和事件存儲是兩種不同的東西，用於兩個不同的目的。

EventStore (GES) 允許通過使用訂閱（客戶端跟蹤或服務器跟蹤（競爭消費者））以及對 ATOM 提要的長輪詢來訂閱事件。 事件組織成流，每個流都有自己的名字，包含這個流的事件。 由於 CQRS 和 EventSourcing 通常應用於 DDD 項目，因此流通常表示聚合，讀取單個流允許重新創建聚合狀態，從流類別（聚合類型）讀取事件用於投影（構建讀取模型）。 每個訂閱者控制自己讀取事件的過程，並且由於事件被存儲，您可以根據需要多次讀取它們。

消息總線與保存事件無關。 它的目標是在端點之間可靠地傳遞消息。 消息總線通常支持代理或聯合拓撲以及不同的模式，如直接發送、發布-訂閱和請求-響應。 一旦消息消費者確認了該消息，它就會從隊列中移除並且無法再次讀取。 如果您沒有訂閱已發布消息的訂閱者，您將永遠失去它們。

意思是，兩者都是有用的模式，但事件存儲更多地用於持久性和消息總線/代理用於持久隊列和可靠交付。

Answer 2

我傾向於這樣認為，這就是我們設置它的方式：

消息總線：處理命令和事件代理。 這用於在各種服務之間進行通信並廣播事件。 在這種情況下，“事件”是暫時的。 它只是讓訂閱者觸發。

EventStore：這是用於存儲針對域實體采取的操作。 在這種情況下，“事件”是持久的。 它的存在是為了重放並獲得對象的“狀態”。

您無法重播臨時消息，因為它們只會觸發一次然后被消耗。 EventStore 中的事件是持久的/可重播的，可以重播以獲得對象狀態或構建投影。 一個是經紀人，另一個是來源。

在物理上和概念上在兩者之間划一條粗線。

Answer 3

我看到使用 EventStore 使得沒有必要使用消息總線 <snip> ......這是正確的嗎？

是的，使用事件存儲可以使消息總線變得不必要。 事件存儲是一個持久隊列，您可以在其中直接讀取事件，並且在 GES 的情況下，您還可以在事件發生時訂閱它們。 除了 GES，在其他事件存儲中，您可以求助於數據庫輪詢以從數據庫中獲取新消息。 （定期發送“自 X 以來的所有消息”的請求。）

消息總線和事件存儲之間的主要區別之一是訂閱將是“拉”而不是“推”。 消息總線會“推送”到它決定您已經看到什么以及您仍然需要什么的地方。 我見過的事件存儲使用“拉”模型（用於進程外），您可以在其中跟蹤自己的檢查點。 對此有一些較小的說明（定期保存您的檢查點），但正如您將在下面看到的那樣，還有很多功能。

注意：GES 確實有推送模型，但它適用於生產者/消費者場景，而不是將相同的消息傳遞到多個端點。

另一個區別是您通常不能告訴事件總線向您發送所有以 X 開頭的消息。即使它具有該功能，根據 X 的時間長短，它也可能不再具有這些消息。 因此，如果您發現代碼中的錯誤，您可能不得不從一個系統到另一個系統求助於ETL來修復它。 錯誤總是會發生，因此您最終會有兩種不同的數據傳播流程，一種基於快樂路徑的事件，另一種基於 ETL 進行數據修復。

但是對於事件存儲，您可以使用相同的過程進行快樂路徑和數據修復。 所有事件仍然存在（默認情況下，除非另有配置）並且使用拉模型，您可以控制要查看的消息。 因此，對於相同的錯誤，您可以修復代碼，然后清空受影響的讀取模型，將其檢查點設置為零，然后在重新啟動時從頭開始重建。 無需還開發 ETL 過程。 （運營問題：如果您的事件存儲很大，重建可能需要一些時間，但您可以與舊模型並排創建初始重建，然后在維護窗口中將其交換。）

一些好的信息/經驗可以在這里找到。

總線在其他情況下仍然有意義……例如，當只有最新消息很重要時。 或者當有太多消息無法存儲時。

實現在頂部使用總線到 EventStore 會有一些好處嗎？

我不會這么認為。 對於這種情況可能有意義的拓撲是讓一些代碼訂閱事件存儲並將新消息發布到總線以更新許多偵聽器（例如，用於擴展讀取）。 但是，使用 GES 特定的功能可以更好地解決這種情況。 即，使用 AtomPub 和緩存代理的 HTTP API。 由於事件是不可變的，在它們被看到一次之后，它們可以在每個級別無限期地緩存。 除了第一次發布消息外，這應該避免需要訪問事件存儲。 這仍然允許客戶端保留對自己訂閱的控制。