事件驅動的架構定義及其重要性

事件驅動的架構是一種軟體設計方法，可讓組織立即回應任何有意義的狀態變更。試想一下，如果企業能即時回應重要事件，例如客戶進行線上購買、感應器偵測到即將發生故障、股價下降或安全警示火災。這些變化（稱為事件）會隨時發生在每個產業和每個組織中。成功便取決於企業如何快速回應事件。

這正是事件驅動的架構（EDA）能提供協助之處。事件驅動的架構可讓應用程式透過鬆散耦合的元件進行非同步通訊，而非等待排程更新或仰賴僵硬且緊密的連線系統。這意味著，系統的每一個環節都可以獨立行動—且不須知道其他人的內部工作—使其更容易擴展、調整和創新。

因此，使用事件驅動架構的現代系統可讓企業提供更快、更個人化的體驗、自動化作業，並在需求和資料量成長時仍保持靈活度。透過採用事件驅動的架構，組織從被動式轉向主動，取得所需的速度、靈活度和彈性，以便在動態的數位世界中蓬勃發展。

什麼是事件？

事件是影響企業的任何動作或狀態變更，例如當客戶刷卡、乘客報到航班、使用者重設密碼，或倉庫更新庫存時。可以這樣想：事件是一個簡短的訊息，表示「剛剛發生了某事」，讓系統其他部分能立即反應。

當公司能隨時在事件發生時擷取並回應事件，就會成為事件驅動公司。某些常見事件範例包含：

• 付款失敗或成功
• 使用者登入或登出
• 存貨下降至門檻值以下
• 出貨離開倉庫或到達其目的地
• 安全漏洞觸發警示
• 忠誠度方案更新點數餘額
• 支援團隊建立工單
• 客戶更新運送地址
• 新使用者建立帳戶
• 購物者提交產品評論
• 訂閱者續訂或取消訂閱

事件驅動架構的核心元件

為使結構保持一致，事件綱要會定義事件結構和格式，其中包含事件具有的欄位、資料類型和解釋規則。

在事件驅動的架構中，應用程式會做為事件產生者（生產或擷取事件）或事件取用者（處理並對事件採取行動）運作。製作者透過事件代理程式（訊息導向的中介軟體），即時將事件傳輸給取用者。接著，使用者可處理事件並驅動其他動作、工作流程或自己的事件。此設計可在資料串流時提供即時回應和更睿智的決策。

事件代理程式管理將生產者與取用者連線的事件通路、確保可靠的交付，且通常提供篩選、持續性和重播等功能。透過分離生產者和取用者，事件代理程式可讓系統更具彈性和可擴展性。

在非常簡單的架構中，當有單一產生者和單一取用者彼此直接通訊時，事件代理程式可以是選用。然而，在多數企業中，有多個來源向多個取用者傳送事件，因此需要代理程式，甚至是代理程式的網路（亦稱為「事件網格」）。當使用代理程式或事件網格時，這會建立「鬆散結合式」的應用程式。

同步與非同步通訊

透過事件驅動架構的同步通訊，事件產生者會等待接收者處理並回應，然後再繼續。例如，當 Web 用戶端傳送 HTTP 請求並等待伺服器回應時。同步通訊通常緊密結合，在繁重的負載下速度較慢，並且會「封鎖」生產者執行下一個工作細項，直到收到取用者的回應。

透過事件驅動架構中的非同步通訊，生產者不須等待立即回應，而是可繼續處理，讓事件取用者稍後再處理訊息。例如，當系統將事件發佈給事件代理程式時，取用者可獨立處理事件。非同步通訊為非封鎖性、鬆散結合且可擴充，使即時和分散式系統更臻完善。

事件驅動架構中請求驅動與事件驅動的模型

在 請求驅動的模型 中，互動會以事件取用者對伺服器的請求開始，隨後伺服器會回應。此模型是以拉式為基礎，意即取用者在需要時主動向伺服器請求資料或服務，而非接收自動更新，且可為同步或非同步。傳統網路應用程式和 API 中常見的請求驅動模型。

在 事件驅動模型 中，互動從事件（狀態變更或觸發處理的動作）開始，而元件會在事件發生時自動反應，例如發行/訂閱。此模型的特性以推送為基礎，表示系統會在發生事件時自動傳送（「推送」）事件或更新給取用者，而無須等待取用者請求。事件驅動的模型為非同步、獨立且適合即時回應。

思考模型之間的關鍵差異：在請求驅動模型中，使用者會在需要時請求資料；事件驅動模型則會在發生事件時自動反應。

常見事件驅動的架構模式

事件驅動的架構 模式 是常見的設計方法，用於定義事件驅動系統擷取、處理和使用事件的方式。模式會以可擴充且獨立的方式，提供處理通訊和狀態更改的可重複使用策略。組織在系統設計和建置期間套用事件驅動的架構模式，以解決常見挑戰。這些包含事件分配、資料一致性，以及非同步、鬆散結合環境的延展性。

事件驅動架構中有四種傳輸事件的主要模式：

• 發佈/訂閱（也稱為「pub/sub」）：使用 pub/sub，事件取用者訂閱由活動產生者發佈的訊息和通路。活動發佈後，將透過事件代理程式直接傳送給所有訂閱者。為避免重複，事件會由代理程式刪除，因此無法在取用後重新播放或存取。
• 事件串流：透過活動串流，產生者向代理程式發佈整個事件流。取用者訂閱事件流並從任何部份讀取，僅取用與其相關的事件。透過事件串流，即使已取用事件，代理程式仍會保留事件。
• 命令查詢責任劃分（CQRS）：透過 CQRS 模式，應用程式設計和架構層會將讀取和寫入作業分隔為不同模型。當查詢讀取狀態時，命令會更新狀態。在事件驅動架構中，CQRS 模式通常與事件搭配使用，並非同步傳播變更，以改善複雜系統的延展性和效能。
• 事件詢比議：透過事件詢比議，系統會將每個狀態變更記錄為僅附加日誌中的事件，而非僅儲存實體的目前狀態。重播這些事件可以重建目前的狀態。這會提供完整的稽核軌跡，並支援出差時間和復原情境。

事件處理樣式

事件處理樣式說明系統偵測、解譯和執行事件的方式。這些樣式定義系統理解事件之間的 邏輯、時間 和關係的複雜性。事件到達取用者時，有三種不同的處理方式：簡易事件處理、複雜事件處理以及事件流處理。

1. 簡易事件處理：取用者會在收到事件時處理各事件。範例：

• 客戶下訂單，提示系統傳送確認電子郵件並更新存貨。
• 密碼重設請求會立即驅動含安全連結的電子郵件。
• 成功付款會產生收據並傳送給客戶。
• 系統會立即記錄使用者登入以進行安全性追蹤。

2.複雜事件處理：取用者處理一系列事件，以偵測模式並根據結果執行動作。範例：

• 連續數筆高價值快速交易引發詐騙警示。
• 溫度上升且振動增加，表示設備故障即將發生。
• 數分鐘內來自不同國家的登入嘗試觸發安全警告。
• 相同使用者放棄重複購物車，提示個人化折扣優惠。

3.事件串流處理：取用者使用資料串流平台，即時處理和應對持續的資料流（即時資料）。範例：

• 股價波動根據預先定義的規則，驅動即時交易執行。
• 社群媒體的提及激增會即時更新情緒儀表板。
• 來自連線車輛的遙測動態調整交通信號。
• 電子商務網站的點擊流資料強化即時產品推薦。

企業可根據個別需求和使用案例，選擇即時事件處理的樣式。

事件驅動的架構如何運作

事件驅動的架構是一種整合模型，旨在即時發佈、擷取、回應分散式系統中的事件。當一個應用程式發生事件時，系統會自動傳送訊息給所有其他需要了解的應用程式，以便對方輪流採取動作。

下列說明事件驅動架構如何逐步運作：

1. 事件發生：發生有意義的狀態更改，例如客戶下訂單、感應器偵測到溫度飆升，或付款失敗。
2. 事件產生者發佈事件：事件發生的應用程式會作為產生者，並將事件發佈給事件代理程式。
3. 事件代理程式傳送事件：事件代理程式可作為中介機構來管理事件通路，並將事件傳遞給所有感興趣的事件取用者，以協助確保可靠、可擴展且獨立的通訊。
4. 事件取用者對事件做出反應：訂閱事件通路的應用程式或服務會處理事件並採取適當動作，例如更新存貨、傳送確認電子郵件或觸發警示。

以事件為基礎的架構為非同步且獨立，這表示應用程式不需要相互注意便可即時共用資訊和完成工作細項。事件資訊或訊息可在應用程式之間自由且自動地流動。因此，事件驅動的架構模型比傳統請求驅動和回應驅動的模型更快速、更具彈性，這些傳統模型中一個應用程式必須向另一個應用程式請求所需的特定資訊，等待回應後再繼續進行下一個工作。另外，由於事件驅動架構的分離式性質，因此被廣泛認為是微服務通訊的最佳實務。

使用案例和實際案例

事件驅動架構可強化從銀行、零售到製造和物流等產業的現代化數位體驗。透過啟用 AI 驅動的自動化、事件智慧和即時回應能力，事件驅動架構可協助組織現代化 IT、分離舊系統，並在多個雲端環境中無縫作業。

下列範例說明事件驅動架構如何運作。

餐飲業

1. 大學生透過食物外送應用程式訂購披薩。應用程式會擷取其基本資訊（姓名、地址、付款資訊和訂單）並發佈「披薩訂單」事件。
2. 披薩餐廳訂閱事件、履行訂單，並將自己的「訂單就緒」事件發佈回食物外送服務。
3. 接著，此服務會分配給送貨司機、排程送達時間，並通知客戶披薩正在送達途中。

電子商務

1. 線上購物者在電子商務網站上輸入信用卡詳細資訊，該網站會發佈「已提交付款」事件。
2. 付款系統訂閱事件、處理付款並發佈自己的「已處理付款」事件，表示成功或失敗，並將其傳送至網站 UI
3. 使用者介面會向客戶顯示付款狀態，並提示後續步驟。

其他事件驅動的架構範例如下：

IoT 遙測

• 智慧工廠會串流感應器資料，偵測溫度飆升並防止設備故障。
• 互聯車輛發送遙測，動態優化交通流量。
• 智慧家庭裝置發佈能源使用事件以驅動節省成本的建議。

分析和事件智慧

• 零售商即時分析點擊流資料，以將產品推薦個人化。
• 銀行監控交易模式，以便在詐騙發生前進行偵測。
• 物流公司使用串流資料，預測交貨延遲和重新安排出貨路線。

自動化

• HR 系統自動為新員工佈建軟體存取權，包含指派授權和權限。
• 當病患體檢結果超出臨界門檻時，醫療保健系統會驅動自動警示。
• 雲端平台根據工作負荷事件動態擴展資源。

財務交易

• 付款閘道會發佈「已提交付款」事件，在核准前驅動詐騙檢查。
• 當股價波動時，交易平台會立即執行買進/銷售訂單。
• 銀行即時過帳存款並更新科目餘額。

供應鏈

• 倉庫會更新存貨量並自動驅動補貨訂單。
• 交付服務根據交通和天氣事件實時重新安排駕駛員。
• 製造商根據即時需求訊號來調整生產排程。

IT 現代化與舊式分離

• 公司透過將業務事件發佈至主要功能的現代雲端服務，將工作從主機轉移。
• 組織在舊版 ERP 周圍公開即時的事件介面，讓新的應用程式能夠立即反應，而無須觸動後端。
• 企業會鏡射從舊 CRM 到現代 SaaS 平台的事件，以便在逐漸移轉的過程中保持兩個系統同步。

通知

• 公用事業供應商會在客戶區域中偵測到電力中斷時通知客戶，並更新修復組員的進度。
• 差旅應用程式會在乘客登機門指派變更時傳送即時警示，確保乘客可立即調整計劃。
• 串流服務會在使用者完成展示後傳送個人化建議。
• 當偵測到可疑登入作業時，安全系統會推送警示。

一般事件驅動的架構使用案例包括：

• 線上購物者按一下產品時，系統會根據相似項目產生產品推薦來回應。
• 零售商為了防止詐欺而篩選全球交易，並將可疑採購加註旗標以提醒信用卡公司。
• 即時客戶互動會使用串流使用者行為資料，在購物工作階段期間觸發個人化優惠或動態定價。
• 醫療保健監控會發佈來自連接裝置的病患生命徵兆，在達到門檻時立即警示臨床醫師。
• 智慧城市運營根據實時交通和天氣事件，管理交通信號燈和公共交通時刻表。
• 網路安全威脅偵測會即時識別並回應可疑網路活動或未經授權的存取嘗試。
• 發生工作負荷尖峰時，雲端資源優化會自動擴展多雲端環境的計算資源。

事件驅動架構的效益

組織可以將事件驅動架構的優勢應用於現代系統。事件驅動的首要架構效益包括：

1. 即時回應和智慧工作流程：事件驅動的架構可讓系統在事件發生時立即回應事件，進而即時驅動自動化工作流程和決策。這在尖峰需求的時段尤其重要，例如在主要銷售事件或假日期間。公司可將此回應能力運用至日常營運，改善從供應鏈自動化、詐欺偵測到個人化客戶互動等所有功能。
2. 使用非同步通訊的速度和效率：事件驅動架構中的應用程式使用非同步通訊，意即生產者發佈事件訊息但不需等待使用者接收。此非封鎖性方法可改善效能、降低延遲，並允許系統處理大量事件，避免處理瓶頸。
3. 透過分離和鬆散結合達成彈性和延展性：事件驅動架構中的元件皆為分離或鬆散結合，因此不需依賴彼此的可用性或內部邏輯，即可獨立運作。如此便可在不中斷整個系統的情況下輕鬆更新、測試和部署服務。分離也可讓您視需要輕鬆新增額外的生產者和取用者，並隨著業務需求成長而實現無縫的規模擴充。
4. 彈性和錯誤隔離：透過分離服務，單一元件中的故障不會串連至整個系統。每個服務都可獨立失敗，使架構比傳統的緊密結合模型更耐用、更容錯。
5. 備戰未來整合：鬆散結合和非同步設計，讓事件驅動架構完美適合 IT 現代化、舊系統分離和多雲端作業。組織可以靈活地整合新技術，例如 AI 驅動的自動化和事件智慧，而無須重寫核心系統。

挑戰、限制和最佳實務

事件驅動的架構提供強大的優勢，但也帶來企業必須規劃因應的新設計和營運挑戰。建置事件驅動架構時，請考量下列事件驅動的架構挑戰、限制和最佳實務，以確保可擴充、具彈性且管理完善的事件驅動系統。

挑戰

• 分散式系統的複雜度：在多個環境中管理事件代理程式的網格時，會造成架構的複雜性。設計事件流程、確保綱要一致性，以及處理非同步通訊需要進階規劃和專業知識。如果沒有適當的設計控制，組織便可能在事件量、生產者和取用者增加時發生事件混亂。
• 管理和法規遵循：隨著事件流程經過混合式和多雲端環境，實施管理政策（如資料隱私、安全性和法規遵循）變得充滿挑戰。組織需要強大的管理架構，以避免資料洩漏和未經授權的存取，並維持對快速擴展事件架構的控制。
• 偵錯和可觀察性：在非同步鬆散結合系統疑難排解問題比傳統架構更複雜。識別故障或延遲的根本原因需要進階監控、追蹤和事件重播功能。尤其當團隊對複雜事件鏈造成的問題進行疑難排解，或解決事件混亂的症狀時，更是如此。

事件網格為何適用

事件網格是一種架構功能，可連結不同大型平台供應商，以及私人、混合和多雲端環境中的多個事件代理程式。事件網格提供進階事件服務的完整用途集，包含事件串流、事件管理、監控、動態訊息傳送和精細篩選。透過將事件代理程式連接至分散式網格，組織可以：

• 透過集中式事件傳送和管理降低複雜性。
• 透過事件目錄、綱要執行和監控支援管理。
• 透過事件追蹤、重播和進階分析改善可觀察性。
• 在混合環境與多雲端環境中實現可擴展性和彈性。

作為現代系統的骨幹，事件網格是可擴充、即時事件驅動架構的基礎層面。其有助於確保即時回應能力，同時簡化整合、減少事件混亂，並強化分散式環境的疑難排解功能。

事件驅動的架構限制

• 營運成本：事件驅動系統需要用於事件管理、綱要驗證和監控的特定工具，因此會增加營運複雜性。
• 技能要求：在分散式系統、事件代理程式和整合平台中建置和維護事件網格和事件驅動的架構，需要專業知識。
• 延遲風險：事件驅動架構專為即時回應而設計，但設定不佳的事件傳送或超載的代理程式可能會造成延遲。

事件驅動的架構最佳實務

• 標準化綱要和事件契約：使用綱要註冊並強制驗證，以維持生產者和取用者的一致性。
• 實施有力治理：明確事件所有權、安全性和法規遵循政策。運用稽核和存取控制的工具。
• 增強可觀察性：部署監控並追蹤解決方案，以追蹤事件流程、偵測異常並簡化除錯。
• 設計可擴展性和彈性：使用事件網格功能，例如動態路線和精細篩選，以優化效能和容錯。
• 運用 AI 和事件智慧自動化：導入 AI 驅動的分析和自動化，即時預測問題、優化流程並改善決策制定。

事件驅動架構的特性

事件驅動的架構在核心仰賴數個定義特性，使其適合分散式、混合式和多雲端架構。

• 非同步通訊：事件驅動架構的基礎特性。應用程式會發佈事件，並繼續運作而不延遲，而非像傳統請求一樣等待直接回應。此非封鎖性樣式可實現分散式系統間的即時互動，即使在高度負載下，也能改善回應能力。
• 鬆散結合：應用程式不需要知道相互間的可用性、API 結構或內部邏輯；應用程式只需透過事件代理程式或事件網格傳送的事件進行通訊。透過確保事件的生產者和取用者獨立運作，團隊可在不中斷更廣泛系統的情況下，新增、更新或取代服務，增加靈活度和容錯。
• 獨立擴充：由於元件已分離，個別服務可根據需求向上或向下擴展，而不需要變更上游或下游應用程式。SAP 強調這是事件驅動整合的核心效益，特別是在混合式和多雲端環境中，必須有效率地管理尖峰負載和分散式工作負載。

這些特性讓事件驅動的架構成為建立系統，真正有時間、彈性、可調整且準備成長的強大方法，無論您是在支援微服務、整合雲端架構，或啟用事件驅動的企業流程應用程式。

常見問題