事件驅動架構如何運作？從電梯系統理解非同步處理機制

最近一直在想一個詞，Event-Driven Architecture，中文翻作「事件驅動架構」，簡稱 EDA。聽起來就很嚇人，一堆技術名詞馬上就冒出來，什麼 Kafka、RabbitMQ、Pub/Sub... 感覺就是要整個公司技術大換血才能搞的東西。

但老實說，我越想越覺得，這件事的本質可能比我們想的簡單很多。它更像是一種...嗯...思考方式的轉變，而不是純粹的技術升級。

重點一句話

導入 EDA 的核心不是換掉所有系統，而是徹底改變你公司內部「溝通資訊」和「觸發行動」的邏輯。

想像一下：你公司是一棟超高大樓

對，先別管程式碼。想像你公司是一棟超級忙碌的摩天大樓，每天成千上萬的人進進出出，每個部門都在不同的樓層。而串連這一切的，就是電梯。

傳統的工作流程，就像那種最老舊的電梯。你按了「上樓」按鈕，然後它就一層一層停，不管那層樓有沒有人要上下。一個部門完成工作（例如「訂單審核」），把文件丟給下一個部門（「倉儲部門」），倉儲部門再處理完，丟給下一個（「物流部門」）。這就是所謂的「批次處理」（Batch Processing），一站跑完才到下一站，很慢，而且中間任何一站卡住，後面就全塞車了。

但 EDA 呢？它就像是那種新型的智慧電梯系統。你在一樓大廳的面板上直接輸入你要去的樓層，比如 30 樓。系統會立刻計算，然後告訴你「請到 C 電梯」。你會發現，跟你一起進 C 電梯的人，可能都是要去 28、30、32 樓的。電梯會用最有效率的路徑，把你們這一群人送到目的地，中間幾乎不停。

看，這就是差別。一個「事件」（你輸入目的地）觸發了一個聰明的、即時的反應（系統幫你分組並調度電梯）。在公司裡，一個「新訂單成立」的事件，可以「同時」通知財務部、倉儲部、行銷部，讓他們各自開始自己的工作，而不是一個等一個。這就是 EDA 的靈魂：資訊流動從線性變成了放射狀。

EDA 就像智慧電梯，會將前往相似目的地的乘客（任務）分組，以最有效率的方式進行調度。

所以，怎麼做？重點真的不是技術

很多人第一個問題就是：「好，那我要用 Kafka 還是 Google Pub/Sub？」我覺得這問題問早了。這就像你連大樓的消防法規、建築藍圖都沒搞懂，就先去挑電梯的品牌一樣。

原文裡提到兩個詞，我覺得才是關鍵中的關鍵：治理（Governance）和標準化（Standardization）。

這什麼意思？

治理：誰可以「按電梯按鈕」（發布事件）？這個按鈕按下去之後，誰會收到通知（訂閱事件）？如果電梯壞了（事件處理失敗）要怎麼辦？這些權責跟流程要先定義清楚。不然 A 部門發一個事件，結果 C、D、E 部門的系統全都跟著動，最後搞得一團亂，沒人知道是誰觸發的。
標準化：每個「事件」的格式總要一樣吧？就像電梯按鈕，大家都知道「30」就是去 30 樓。如果 A 部門的「新訂單」事件格式跟 B 部門的完全不同，那下游的系統到底要聽誰的？所以你需要統一的命名規則、統一的資料結構（Schema）。

少了這兩樣東西，你的 EDA 馬上就會變成一個無法無天的西部荒野，各種格式混亂的事件滿天飛，系統之間彼此衝突，除錯會除到死。這真的比沒有 EDA 還慘。所以，與其先選工具，不如先開會把這些「交通規則」給訂下來。

傳統作法 vs. 事件驅動，差在哪？

我自己是覺得，用下面這個表來想，會清楚很多。這不是技術優劣，是思維模式的根本不同。

比較項目	傳統批次處理 (Legacy Batch)	事件驅動架構 (EDA)
核心比喻	郵差送信。每天固定時間來收信、送信，錯過就等明天。	即時通訊軟體。一有訊息就馬上跳通知，永遠在線。
系統耦合度	超高。A 要直接呼叫 B，B 要直接呼叫 C。A、B、C 誰掛了，整條線就斷了。	很低。A 只管發出「我做完事了」的信號，根本不在乎誰在聽。B 或 C 可以自己決定要不要聽。
反應速度	慢。通常是小時級或天級的。等所有資料湊齊了才一次處理。	極快。毫秒或秒級。一有變化就馬上反應。
最適合的場景	月底結帳、每日報表這種不要求即時性的任務。	電商下單、庫存更新、股價跳動、IoT 感測器回報... 任何需要「立即」反應的場景。
潛在風險	效率低下，無法應對快速變化的市場需求。一個環節卡住就癱瘓。	如果沒管好，會變事件風暴。而且要追蹤一個完整的流程會變複雜，因為它散在各處。

看看別人怎麼玩：從 Shopify 到台灣的金融業

講理論很空，我們看實際案例。

原文提了 Shopify 跟 Netflix，這兩個是絕佳的例子。你想想 Shopify，全球幾百萬個店家，每秒鐘有多少「訂單成立」、「庫存減少」、「商品上架」的事件發生？它不可能等一天才結算一次庫存吧？一定是客人前腳下單，後腳庫存系統就即時更新。這就是 EDA 在大規模電商的威力。

Netflix 也一樣。你按下「播放」，這是一個事件。系統收到後，開始串流影片給你。你看到一半按下「暫停」，又是一個事件，系統會記錄你停在哪裡。你看完給了個「評分」，這更是個超重要的事件，推薦系統會馬上把這個偏好納入計算，影響你下次看到的片單。這一切都是即時、非同步發生的。

在一個良好治理的 EDA 環境中，所有事件都必須通過一個「治理層」的檢查，確保其符合標準。

不過呢，說到這個，這套玩法在不同國家、不同產業，輕重緩急會很不一樣。原文的例子都是美國的網路巨頭，他們追求的是極致的速度、彈性和擴展性。

但在台灣，尤其是在金融業，情況就不同了。之前看過一些像是國泰金控這類公司的技術分享，他們在導入類似的即時資料架構時，首要考量絕對不是「快」，而是「合規」和「可追蹤」。每一筆資料的流動，都必須留下清楚的軌跡，方便未來稽核。所以他們的架構設計，可能會更強調資料的持久化（persistence）、錯誤處理和重試機制，甚至在某些環節刻意「放慢」，以確保資料的一致性與正確性，這跟 Shopify 那種「速度就是一切」的哲學，出發點就完全不同了。

所以你看，沒有最好的架構，只有最適合你業務情境的架構。

挑戰與誤區：這不是萬靈丹

好，EDA 聽起來很棒，但實際導入時，坑真的不少。我整理幾個最常見的：

陷入事件風暴（Event Storming...的濫用）：不是什麼雞毛蒜皮的小事都要變成一個事件。如果連「用戶滑鼠移動」這種事情都當成事件來廣播，你的系統很快就會被海量的無用資訊給淹沒。必須要定義清楚，到底什麼是「有商業意義的狀態改變」。
忽略 Schema 管理（Schema Evolution）：前面提到的，事件的格式。最可怕的是，這個格式不是一成不變的。業務會改、需求會加，你的「新訂單」事件今天有 5 個欄位，明天可能要加到 8 個。那舊的、還在處理 5 個欄位的系統怎麼辦？會不會直接崩潰？這就是所謂的 Schema 演進問題。你需要像 Avro、Protobuf 這類工具，搭配一個中央的 Schema Registry 來管理版本，確保系統可以向下相容。
忘記處理失敗：網路不是永遠可靠的。如果倉儲系統剛好在更新，沒收到「新訂單」的事件怎麼辦？訂單就漏掉了？所以一定要有完善的錯誤處理機制，例如「重試」（Retry）幾次，如果都不行，就把這個失敗的事件丟到一個叫「死信佇列」（Dead-Letter Queue）的地方，等著工程師手動來處理。千萬不能假裝失敗不會發生。
資料一致性的挑戰：在傳統單體式應用裡，你可以用一個資料庫交易（Transaction）來確保訂單跟庫存同時更新。但在 EDA 裡，這兩件事變成非同步的了。有可能訂單成立了，但扣庫存的服務卻失敗了。如何確保最終的資料是一致的？這就牽涉到更複雜的模式，比如 Saga pattern。簡單講，就是把一個大交易，拆成好幾個可以各自補償（compensate）的小步驟。這水就很深了。