什麼是事件導向架構？
事件導向架構（EDA）是一種整合模型，可偵測業務中的重要「事件」，例如交易或捨棄購物車，並即時採取行動。
探索事件導向架構概觀
幾乎每個業務事件都有時效性。當客戶進行線上購買時，感測器會標記即將發生的故障、股價下跌或偵測到安全漏洞，需要立即採取動作。這是事件導向架構（EDA）的作用所在。EDA 可在事件發生時建立、偵測和回應，協助企業改善從客戶體驗到營運效率和靈活度的各個方面。
什麼是事件？
首先是一些基本概念。事件是對業務重要的任何動作或狀態變更。例如，當有人刷信用卡、辦理登機手續、重設密碼，或在倉庫中更新庫存時。事件隨時都在每個組織、每個產業發生。當能在事件發生時擷取並回應事件時，公司化身為「敏於行」的企業。
什麼是事件導向架構？
事件導向架構（EDA）是整合模型，旨在即時發佈、擷取、回應分散式系統中的事件。當一個應用程式發生事件時，系統會自動傳送訊息給所有其他需要了解的應用程式，以便對方輪流採取動作。
事件導向架構是分離架構，這表示應用程式不需要相互通訊即可共用資訊和完成工作。事件資訊或訊息可在應用程式之間自由或自動流動。因此，EDA 模型的速度遠比傳統的請求/回應模型快，其中一個應用程式必須從另一個應用程式請求所需的特定資訊，並等待回應再繼續下一個工作。另外，由於 EDA 的分離式性質，因此被廣泛認為是微服務通訊的最佳實務。
EDA 如何運作？
在事件導向架構中，應用程式可作為事件產收者（產生或擷取事件的應用程式）或事件取用者（處理及應對事件的應用程式）。產生者會即時透過代理程式（也稱為訊息導向中介軟體）將事件傳送給取用者。取用者可接著處理事件，並驅動其自有的其他動作、工作流程或事件。
在非常簡單的架構中，當有單一產生者和單一取用者彼此直接通訊時，代理程式可以是選用。然而，在多數企業中，有多個來源向多個取用者傳送事件，因此需要代理程式，甚至是代理程式的網路（亦稱為「事件網格」）。當使用代理程式或事件網格時，這會建立「鬆散結合式」的應用程式。
事件導向架構模式
事件導向架構中有兩種主要事件傳輸模式：發佈/訂閱和事件串流。
發佈/訂閱（也稱為「pub/sub」）– 使用 pub/sub，事件取用者訂閱由活動產生者發佈的訊息和管道。活動發佈後，將透過代理程式直接傳送給所有訂閱者。為避免重複，事件無法在取用後重新播放或存取，並由代理程式刪除。
活動串流 – 透過活動串流，產生者向代理程式發佈整個事件流。取用者訂閱事件流並從任何部份讀取，僅取用與其相關的事件。使用此模式時，即使已取用事件，代理程式仍會保留事件。
事件處理的 3 種方法
事件傳送給取用者後，有三種不同的處理方式：簡易事件處理、複雜事件處理，以及事件流處理。
- 簡易事件處理：取用者會在收到事件時處理各事件。
- 複雜事件處理：取用者處理一系列事件，以偵測模式並根據結果執行動作。
- 事件流廚李：取用者使用資料串流平台，即時處理和應對持續的資料流（即時資料）。
企業會根據個別需求和使用案例，選擇事件處理的方法。
事件導向架構的使用案例和範例
從銀行業到零售業，在每個產業中，事件導向架構都有許多不同的使用案例。餐飲業的範例如下：
一名大學生透過食物外送應用程式（例如 Uber Eats）訂購披薩。應用程式會擷取其基本資訊（姓名、地址、付款資訊和訂單）並發佈「披薩訂單」事件。
披薩餐廳訂閱事件、履行訂單，並將自己的「訂單就緒」事件發佈回食物外送服務
接著，此服務會分配給送貨司機、排程送達時間，並通知客戶披薩正在送達途中。
電子商務的 EDA 範例：
線上購物者在電子商務網站上輸入信用卡詳細資訊，該網站會發佈「已提交付款」事件
付款系統訂閱事件、處理付款並發佈自己的「已處理付款」事件，表示成功或失敗，並將其傳送至網站 UI
使用者介面會向客戶顯示付款狀態，並提示後續步驟
EDA 的一些其他範例包括：
當線上購物者按一下產品時，系統會根據相似項目產生產品推薦
當客戶在銀行存入支票時，系統會自動將存款過帳至其帳戶
零售商針對詐欺而篩選全球交易，並將可疑採購加註旗標以提醒信用卡公司。
當製造商從設備監控串流 IoT 資料，並收到潛在維護問題或失敗的警示時
事件導向架構的效益
事件導向架構有許多效益。前 3 大效益如下：
- 即時工作流程和回應。EDA 可監控並快速回應發生事件，通常使用智慧流程自動化（RPA）來加速工作流程並即時驅動後續步驟。這在尖峰需求時特別重要，例如在主要銷售事件或假日期間。此回應能力也適用於（例如非高峰）工作流程，改善從供應鏈自動化到詐欺偵測的所有流程。
- 非同步傳訊。在 EDA 中，應用程式以非同步方式通訊，意即產生者會發佈事件訊息，而不等待取用者接收。這不僅讓應用程式不需等待即可繼續進行其他工作，因此簡化了整合。
- 分離式和鬆散結合式。在 EDA 中，應用程式是分離式或鬆散結合式，並不依賴於彼此的可用性。其可個別更新、測試和部署，也可以獨立失敗，因此架構比傳統模型更耐久且持久。分離式也會視需要輕易增加額外的發佈者和取用者，免去每次變更時重新編寫程式碼的需求。
