微服務架構下，服務之間的協調與協調至關重要。事件驅動架構提供了一種有效的方法，透過事件觸發和協調微服務互動，實作業務流程的自動化。服務編舞模式下，各微服務自主回應事件，共同完成業務流程，而服務協調則依賴中央控制器來管理工作流程。兩種模式各有優劣，需根據實際場景選擇。事件驅動架構的實施需要注意事件結構變更的影響、敏感資料的保護、事件負載的限制以及重複事件的處理。
門衛事件匯流排模式的注意事項
雖然門衛事件匯流排模式實作簡單，但仍有一些重要點需要注意：
- 事件結構變更：引入破壞性的事件結構變更將對事件驅動架構產生嚴重的後果。版本化您的事件是避免影響下游系統的關鍵。
- 敏感資料和個人身份資訊（PII）處理：當事件離開您的有界上下文時，您將失去對下游事件流和其到達的目的地的控制和可見性。您需要有適當的措施來識別和保護PII和敏感資料。
- 事件負載限制：Amazon EventBridge的最大接受事件負載大小為256 KB。若下游消費者有更低的資料負載限制，或者微服務以使其超過此大小的方式轉換或豐富接收到的事件，您需要找到一種方法來處理這種情況。
- 重複事件處理：許多業務域對重複事件敏感，例如金融賬戶更新、線上支付等。門衛服務可以在傳送事件給消費者之前執行第一階段檢查。
微服務編舞
編舞是創造運動序列的過程。在微服務編舞中，各個微服務透過接收事件和知道如何反應和做什麼來共同完成業務流程。沒有控制器來指示服務執行任務；相反，服務接收事件並知道如何反應。
微服務編舞的注意事項
微服務編舞是一種常見且廣泛採用的事件驅動模式。但在實施過程中，需要考慮以下幾點：
- 事件丟失：在任何網路系統中，都存在中斷和資料丟失的可能性。因此，需要採取措施來最小化其影響。EventBridge具有內建功能，可以在24小時內重試向目標傳送事件的交付。你可以附加一個死信佇列（DLQ）來捕捉在交付嘗試用完後的事件。
事件驅動微服務架構中的服務協調
在事件驅動微服務架構中，服務協調是一種常見的模式，用於實作業務流程。與微服務編舞（Choreography）不同，服務協調需要一個中央控制器來協調各個微服務之間的溝通和工作流程。
什麼是服務協調？
服務協調是一種軟體設計模式，透過定義一個工作流程來協調多個微服務之間的溝通和工作流程。這種模式需要一個中央控制器來管理工作流程，確保各個微服務之間的溝通和工作流程正確執行。
服務協調的優點
服務協調具有以下優點：
- 提高工作流程的效率：服務協調可以自動化工作流程，減少人工干預，提高工作流程的效率。
- 改善工作流程的可視性：服務協調可以提供工作流程的可視性，讓開發人員和業務人員可以清楚地看到工作流程的執行情況。
- 增強工作流程的可擴充套件性：服務協調可以讓工作流程更容易擴充套件，新增或刪除微服務都可以輕鬆實作。
服務協調的型別
服務協調可以分為三種型別：
- 內部協調：內部協調是指在單個微服務內部實作的協調。這種協調方式簡單易實作，但不適合複雜的業務流程。
- 跨服務協調：跨服務協調是指在多個微服務之間實作的協調。這種協調方式需要一個中央控制器來協調各個微服務之間的溝通和工作流程。
- 分散式協調：分散式協調是指在多個微服務之間實作的協調，各個微服務之間透過事件或訊息進行溝通和協調。
服務協調的實作
服務協調可以透過以下步驟實作：
- 定義工作流程：定義業務流程中需要執行的工作流程。
- 設計中央控制器：設計一個中央控制器來協調各個微服務之間的溝通和工作流程。
- 實作微服務：實作各個微服務，讓它們可以與中央控制器進行溝通和協調。
- 測試和佈署：測試和佈署服務協調系統，確保它可以正確執行業務流程。
分散式服務協調：事件驅動的微服務架構
在設計微服務架構時，服務協調是一個關鍵的方面。服務協調是指如何管理和協調多個微服務之間的互動，以實作業務邏輯。有一種常見的服務協調方式是事件驅動的架構，即使用事件來觸發和協調微服務之間的互動。
事件驅動架構
事件驅動架構是一種設計模式，使用事件來觸發和協調微服務之間的互動。事件可以是任何事情，例如使用者的操作、資料變化或系統的狀態變化。當事件發生時，會觸發相應的微服務進行處理。
在事件驅動架構中，微服務之間的互動是透過事件通道進行的。事件通道是一個中央的事件匯流排，負責接收和分發事件給相應的微服務。每個微服務都可以訂閱特定的事件，並在接收到事件時進行處理。
任務令牌
任務令牌是一種特殊的事件，代表了一個需要被處理的任務。任務令牌可以被用來協調微服務之間的互動，例如當一個微服務需要另一個微服務進行某些處理時，可以傳送一個任務令牌給對方。
任務令牌通常包含一些基本資訊，例如任務的識別碼、任務的描述、任務的狀態等。當一個微服務接收到任務令牌時，會根據任務令牌的內容進行相應的處理。
分散式服務協調
分散式服務協調是一種使用事件驅動架構和任務令牌來協調微服務之間的互動的方式。在分散式服務協調中，每個微服務都是獨立的，並且可以自行決定如何處理接收到的事件或任務令牌。
分散式服務協調的一個主要優點是可以提高系統的可擴充套件性和容錯性。因為每個微服務都是獨立的，所以如果一個微服務出現問題，不會影響到其他微服務的執行。此外，分散式服務協調也可以提高系統的靈活性和可維護性，因為每個微服務可以獨立地進行修改和更新。
實踐案例
下面是一個實踐案例，展示瞭如何使用事件驅動架構和任務令牌來協調微服務之間的互動。
假設我們有一個電子商務系統，包含多個微服務，例如使用者管理、訂單管理、庫存管理等。當使用者下單時，需要觸發訂單管理微服務進行處理。但是，訂單管理微服務需要庫存管理微服務進行庫存檢查。
在這種情況下，可以使用事件驅動架構和任務令牌來協調微服務之間的互動。當使用者下單時，可以傳送一個任務令牌給訂單管理微服務，訂單管理微服務接收到任務令牌後，可以傳送一個事件給庫存管理微服務，要求進行庫存檢查。庫存管理微服務接收到事件後，可以進行庫存檢查，並傳回結果給訂單管理微服務。
sequenceDiagram
participant 使用者管理
participant 訂單管理
participant 庫存管理
Note over 使用者管理,訂單管理: 使用者下單
使用者管理->>訂單管理: 傳送任務令牌
訂單管理->>庫存管理: 傳送事件（庫存檢查）
庫存管理->>訂單管理: 傳回結果
Note over 訂單管理,庫存管理: 完成庫存檢查
從技術架構視角來看，事件驅動架構在微服務協調中扮演著至關重要的角色，本文探討了從簡單的門衛事件匯流排模式到複雜的服務協調等多種實作方式。分析不同協調方式的優缺點及注意事項，例如門衛模式的事件結構變更風險、事件負載限制以及敏感資料處理等；編舞模式的事件丟失風險；以及協調模式中中央控制器的設計與實作。儘管服務協調提供了更好的流程可視性和控制力，但也引入了單點故障的風險。分散式服務協調結合了事件驅動和任務令牌機制，在提升系統彈性與可擴充套件性的同時，也增加了設計和管理的複雜度。玄貓認為，技術團隊應根據業務需求和系統規模，審慎評估不同協調方式的適用性，並著重解決核心挑戰，例如確保事件的可靠傳遞、處理重複事件以及維持資料一致性，才能有效釋放事件驅動架構的潛力。未來，隨著Serverless技術的普及和事件流處理平臺的成熟，預計事件驅動架構將在更廣泛的場景中得到應用，並推動更精細化的微服務協調策略的發展。
