事件來源模式

事件來源模式通常搭配使用，以將讀CQRS 模式 取與寫入工作負載分離，並針對效能、可擴充性和安全性進行最佳化。資料會儲存為一系列事件，而不是直接更新資料存放區。微服務會從事件存放區重新顯示事件，以計算其本身資料存放區的適當狀態。該模式提供了應用程序的當前狀態以及應用程序如何達到該狀態的其他上下文的可見性。事件來源模式可以有效地與 CQRS 模式搭配使用，因為即使指令和查詢資料倉庫具有不同的結構描述，也可以針對特定事件複製資料。

通過選擇此模式，您可以識別和重建應用程序的任何時間點的狀態。這會產生持續性的稽核追蹤，並使偵錯變得更容易。但是，數據最終變得一致，這可能不適合某些用例。

您可以使用 Amazon Kinesis 資料串流或亞馬遜來實作此模式。 EventBridge

Amazon Kinesis Data Streams 實作

在下圖中，Kinesis Data Streams 是集中式事件存放區的主要元件。活動存放區會將應用程式變更擷取為事件，並將其保留在 Amazon Simple Storage Service (Amazon S3) 上。

工作流程由以下步驟組成：

1. 當「/撤回」或「/credit」微服務遇到事件狀態變更時，他們會透過將訊息寫入 Kinesis Data Streams 來發佈事件。

2. 其他微型服務 (例如「/balance」或「/Credit Limit」) 會讀取訊息的副本，針對相關性進行篩選，然後轉寄以供進一步處理。

Amazon EventBridge 實施

下圖中的架構使用 EventBridge。 EventBridge 是一種使用事件連接應用程式元件的無伺服器服務，可讓您更輕鬆地建置可擴充的事件驅動型應用程式。事件驅動架構是一種構建鬆散耦合的軟件系統的風格，該軟件系統通過發出和響應事件來協同工作。 EventBridge 為AWS服務所發佈的事件提供預設事件匯流排，您也可以為網域特定匯流排建立自訂事件匯流排。

工作流程由以下步驟組成：

1. 「OrderPlaced」事件由「訂單」微服務發佈至自訂事件匯流排。

2. 下訂單後需要採取行動的微服務，例如「/route」微服務，都是由規則和目標啟動的。

3. 這些微服務會產生運送訂單給客戶的路由，並發出 "RouteCreated" 事件。

4. 需要採取進一步處理行動的微服務也會由 "RouteCreated" 事件啟動。

5. 事件會傳送至事件封存 (例如 EventBridge 歸檔)，以便視需要重新顯示事件以進行重新處理。

6. 歷史訂單事件會傳送至新的 Amazon SQS 佇列 (重新顯示佇列) 以進行重新處理 (如有需要)。

7. 如果未啟動目標，受影響的事件會放置在無效字母佇列 (DLQ) 中，以供進一步分析和重新處理。

你應該考慮使用這種模式，如果：

• 事件用於完全重建應用程序的狀態。

• 您需要在系統中重新顯示事件，並且可以在任何時間點確定應用程式的狀態。

• 您希望能夠反轉特定的事件，而不必以空白的應用程式狀態開始。

• 您的系統需要可以輕鬆序列化的事件串流，以建立自動化記錄。

• 您的系統需要大量的讀取操作，但寫入操作很輕; 大量的讀取操作可以導向到內存內存數據庫，該數據庫隨著事件流保持更新。

重要

如果您使用事件來源模式，則必須部署Saga模式以維護跨微服務的資料一致性。