事件導向架構是一種軟體設計模式，微服務會對狀態變化 (稱為「事件」) 做出反應。事件可以攜帶狀態 (例如商品價格或寄送地址)，也可以是 ID (例如收到或出貨通知)。事件會觸發微服務，這些微服務會共同達成共同目標，但除了事件格式外，不必瞭解彼此。雖然微服務會一起運作，但每項微服務都可以套用不同的商業邏輯，並發出自己的輸出事件。
事件具有下列特徵：
- 這是指已發生的事件記錄。
- 這項資訊是不可變更或刪除的事實。
- 無論服務在取用時是否套用任何邏輯，都會發生這種情況。
- 可無限期保留大量資料，並視需要多次使用。
在事件驅動系統中，事件是由事件產生者產生，並由事件路由器 (或代理程式) 擷取及篩選，然後分散到適當的事件取用者 (或接收器)。系統會根據一或多個相符的註冊 (使用 Eventarc Advanced 時) 或一或多個相符的觸發條件 (使用 Eventarc Standard 時) 所定義的訂閱項目，將事件轉送給消費者。這三個元件 (事件產生者、事件路由器、事件取用者) 會分離，且可獨立部署、更新及擴充：
事件路由器會連結不同服務，也是傳送及接收訊息的媒介。它會執行對事件產生器所產生原始事件的回應，並將此回應向下游傳送至適當的消費者。事件會以非同步方式處理，服務對事件做出反應或受到事件影響時，就會決定事件結果，如下圖所示，這是非常簡化的事件流程：
事件導向架構的使用時機
設計系統時，請考量下列用途。
- 監控並接收快訊，瞭解儲存空間值區、資料庫表、虛擬機器或其他資源的任何異常或變更。
- 將單一事件散布給多個取用端。事件路由器會將事件推送至所有適當的消費者，您不必編寫自訂程式碼。每項服務都能以平行方式處理事件，但處理方式不同。
- 在不同技術堆疊之間提供互通性，同時維持各堆疊的獨立性。
- 協調系統和團隊，在不同區域和帳戶中運作及部署。您可以重新整理微服務的擁有權。跨團隊的依附元件較少，且您能更快因應變更，否則資料存取權障礙會阻礙變更。
事件導向架構的優點
建構事件導向架構的優點如下：
鬆散耦合和提升開發人員的靈活度
事件產生者在邏輯上與事件消費者分開。事件的產生和取用作業彼此分離，代表服務可互通，但能獨立調度資源、更新及部署。
鬆散耦合可減少依附元件，讓您以不同語言和架構實作服務。您可以新增或移除事件產生器和接收器，不必變更任何服務中的邏輯。您不必撰寫自訂程式碼來輪詢、篩選及轉送事件。
非同步事件和韌性
在事件導向系統中，事件會以非同步方式產生，且可在發生時發布，不必等待回應。鬆散耦合的元件表示如果某項服務失敗，其他服務不會受到影響。如有需要，您可以記錄事件，讓接收服務從失敗點繼續作業，或重播過去的事件。
推播型訊息傳遞、即時事件串流和降低成本
事件導向系統可進行推播式傳訊，用戶端也能接收更新，不必持續輪詢遠端服務的狀態變更。這些推送訊息可用於即時資料處理和轉換，以及即時分析。此外，減少輪詢次數可降低網路 I/O，進而減少費用。
簡化稽核和事件來源
事件路由器集中管理，可簡化稽核作業，並控管哪些人可以與路由器互動，以及哪些使用者和資源可以存取資料。您也可以加密傳輸中的資料和靜態資料。
此外，您也可以使用事件來源 (一種架構模式，會以原始套用順序記錄應用程式狀態的所有變更)，事件來源提供不可變更的事件記錄，可保留用於稽核、重建歷來狀態，或做為說明業務決策的標準敘述。
架構考量
事件導向架構可能需要您以新方式設計應用程式。雖然這項功能非常適合使用微服務或解除耦合元件的應用程式，但您也應考量下列事項：
如果需要處理每個事件，事件來源是否能保證傳送？
這項來源應能長期提供可靠的事件。
您的應用程式是否可以處理多個非同步要求？
系統效能不應依賴全域範圍或缺乏彈性的資料庫。
您想如何追蹤事件流程？
事件導向架構支援使用監控服務進行動態追蹤，但不支援使用程式碼分析進行靜態追蹤。
要使用事件來源中的資料重建狀態嗎？
您應考慮如何確保資料已去重複且排序正確。
後續步驟
- 如要瞭解 Eventarc Advanced 如何處理事件，請參閱 Eventarc Advanced 總覽。
- 如要瞭解 Eventarc Standard 如何處理事件，請參閱 Eventarc Standard 總覽。