銀行業云原生事件驅動架構實踐：經驗與教訓

作者 | Chris Tacey-Green

譯者 | 明知山

在探討云平臺與強監管行業中的事件驅動架構時，先建立統一的認知基礎十分必要。這一話題吸引著背景各異的人群：既有親歷過分布式系統實際挑戰的工程師，也有初次接觸相關概念的初學者。統一認知之所以重要，是因為事件驅動架構所涉及的概念看似簡單，但若從一開始就理解不清，很容易在實踐中被誤用。

本文基于 我在 2025 年慕尼黑 InfoQ 開發者大會上的演講，總結了在銀行業構建與運維云原生事件驅動系統的經驗教訓。我將從基礎概念入手，探討這類架構風格在監管嚴格的環境中為何具備吸引力、能實際帶來哪些價值，以及會在哪些環節引入風險與復雜性。同時，我還會介紹能讓這類系統在生產環境中切實落地（而非僅停留在理論層面）的設計模式與實踐方法。

有了這些基礎，理解事件驅動架構是什么、適用于哪些場景、帶來了哪些權衡取舍以及為何即便存在監管約束，它依然是銀行系統的合適選擇，都會變得容易得多。

什么是事件？

事件是系統內部發生的某種狀態變更。這種變更可由用戶操作、異步后臺進程或外部系統與平臺交互觸發。事件既可以攜帶描述變更情況的數據，也可以作為輕量級通知，僅表明某件事已經發生。

業界對于事件應包含多少數據一直存在爭議。有人主張采用極簡負載，也有人更傾向于選擇包含更豐富內容的消息。我的觀點很簡單：事件只應包含與該狀態變更直接相關的數據，僅此而已。如果某條信息并非該狀態變更的固有內容，就不應該出現在事件中。保持事件精簡能讓系統更易于演進，并降低系統間不必要的耦合。

命令與事件并不相同

事件驅動系統中最重要的區別之一就是命令與事件之間的差異，這也是最容易被誤解的概念之一。如果團隊模糊了這一界限，最終往往會得到看似事件驅動、卻無法實現預期收益的架構。

命令是對執行某項操作的請求，帶有明確意圖和指向性：由一個系統告知另一個系統執行特定動作。即便采用異步處理，命令依然包含期望某項操作發生的語義。

事件則不同，它是一種事實陳述，表明某事已經發生。發布事件的系統既不要求后續操作，也不期望得到響應。事件可以有多個消費者、單個消費者，甚至完全沒有消費者，這些情況都是合理有效的。

這種區別十分重要。將事件當作命令使用會導致耦合更加緊密，并損害系統的長期靈活性。如果希望系統保持適配能力，就需要審慎區分命令與事件。

事件驅動架構的真正含義

有了這些定義，描述事件驅動架構就變得更加容易。它是一種系統通過發布和響應事件來實現通信的架構風格。生產者將事件發送至事件平臺，消費者訂閱自己關心的事件。生產者無需知曉哪些系統在消費事件，甚至無需關心是否有系統在消費。

事件驅動架構經常與事件溯源相混淆，但二者并非同一概念。事件溯源將應用狀態建模為不可變事件序列，而非直接存儲當前狀態。例如，采用事件溯源的系統不會直接記錄購物車中有四件商品，而是存儲四條獨立的“商品已添加”事件，并通過重放這些事件來推導出當前狀態。

事件溯源或許很強大，但也相當復雜，且難以實現到位。更重要的是，它并非事件驅動架構的前提條件。兩者經常被放在一起討論，這是因為事件溯源系統會產生事件，但采用事件驅動通信并不意味著必須使用事件溯源。

云原生實戰

云原生并非只是將工作負載運行在云端。云平臺幾乎可以支持任何運維模式，而云原生系統更強調采用現代工程實踐，在設計上具備可擴展性、支持頻繁部署，并依靠自動化而非人工操作來完成運維。

這些系統通常采用微服務構建，但模塊化單體也同樣適用。架構結構并非關鍵，重要的是采用現代化的 DevOps 實踐，例如持續集成、持續部署以及基礎設施即代碼。在這一背景下，事件驅動架構是順理成章的選擇。它支持異步通信、松耦合與獨立部署，與云原生系統的構建和運維方式高度契合。

銀行業環境下的約束考量

銀行業的特性給架構設計帶來了額外的約束。銀行是規模龐大、監管嚴格的機構，承擔著保護客戶資金的核心責任。監管不僅影響技術決策，還塑造著組織文化、風險容忍度與變革節奏。因此，這類機構對新型架構模式往往持謹慎態度，也就不足為奇了。

與此同時，現代工程實踐已不再是可選項。金融系統的規模與復雜度持續提升，客戶期望也在不斷提高。在天達銀行（Investec，一家英南非合資的國際銀行及財富管理集團），我們在滿足嚴格監管要求的同時也在積極采用云原生與事件驅動架構。

為什么事件驅動架構很重要

弄清楚了基礎概念，事件驅動架構的價值便不難理解。這些優勢并非停留在理論層面，而是直接體現在銀行業的實際生產場景中。

解耦是最典型的優勢之一，這一優勢在支付處理方面體現得尤為明顯。以交易監控為例，對賬戶活動進行實時監測、識別可疑行為，是必不可少的風控環節，但這一環節不應處于核心支付執行路徑上。支付需要極高的可靠性，而監控可以異步完成。通過發布支付事件讓監控系統可以獨立進行消費，這兩個關注點便能相互隔離。這意味著即便監控暫時不可用，支付流程仍可正常繼續，同時監控能力也能獨立演進，不會影響支付流程。

圖 1：銀行系統中的解耦

事件驅動系統還會生成不可變的活動日志。在復雜的支付流程中，事件不僅是輔助性的審計追蹤記錄，更是業務實際發生情況的真實憑證。活動日志讓團隊能夠清晰地掌握支付全生命周期，提升了故障排查效率，同時也有助于滿足監管機構對可追溯性的要求。

扇出是另一大顯著優勢。單個事件（如支付完成）可觸發多個獨立流程：更新支付限額、發送客戶通知或啟動下游對賬流程。每個消費者均可獨立管理自身的失敗與重試，從而讓核心支付流程保持簡潔。

圖 2：銀行系統中的扇出

容錯能力在受監管環境中尤為重要，尤其是在涉及第三方欺詐引擎等不可靠外部依賴時。事件驅動架構支持分層重試策略、受控退避以及無法自動恢復時的死信處理，既能防止有害事件影響整個系統，也能讓故障處理更加安全可靠。

最后，成熟的事件驅動平臺具備真正的即插即用能力。新增功能（如獎勵計劃）可通過訂閱現有事件流實現，無需修改核心系統。在事件設計合理且保持穩定的前提下，能夠快速擴展能力，避免與原始系統緊密耦合。

痛點與解決方案

事件驅動架構在理論上看似近乎完美，但現實問題很快會顯現。這類架構存在切實的痛點，在銀行等監管嚴格的行業中，忽視這些痛點可能引發嚴重后果。好消息是，業界對這些挑戰已有充分認知，并且有成熟可靠的解決方案。

人為層面的挑戰

事件驅動架構面臨的最大挑戰并非技術層面，而是思維模式的轉變。工程師需要建立異步通信、最終一致性與獨立故障處理的思維，而非默認采用熟悉的同步請求與響應模式。

我們在實踐中對此感受尤為明顯。在同時采用事件驅動架構與事件溯源的領域，新團隊成員通常需要約六個月時間才能達到資深同事的交付效率。初期，團隊經常會對非核心的問題進行過度設計，同時又低估了分布式系統中最關鍵的問題：一致性、重試機制與故障處理。這些挑戰帶來的組織層面影響十分顯著，不容忽視。

工具和賦能

應對人為層面的挑戰僅靠良好意愿遠遠不夠，還需要嚴謹的工具支撐與能力賦能。在前期投入構建完善的開發者平臺，搭配設計精良的模板與共享模塊，能帶來切實有效的提升。已標準化的落地路徑可以幫助新團隊快速落地事件驅動微服務，避免重復造輪子。

擁有強大的平臺還遠遠不夠，培訓同樣至關重要。為團隊配備強大的工具，但他們卻不知道這些系統在生產環境中的運行特性，尤其是故障往往發生在凌晨時分，這存在極大的風險。對此，我們讓賦能團隊與交付團隊結對協作，共同設計并構建出小型實用的事件驅動系統，隨后投入生產。這種方式遠比單純依賴文檔更為有效，也能讓團隊具備獨立構建系統的信心。

早期在標準上達成共識同樣重要。預先統一事件契約、權限體系與核心技術方案能夠避免技術碎片化，讓整個組織更便捷地消費事件。

防止事件丟失或重復

另一個重大挑戰是可靠性。在銀行業，事件丟失或重復是完全不可接受的。租金支付遺漏、存款重復支付這類問題并非微不足道的邊緣情況，這些風險必須在設計階段就加以解決。

我們依靠發件箱與收件箱模式來降低此類風險。發件箱模式確保狀態變更與事件發布在同一事務邊界內完成，從而避免事件丟失，再由調度程序將這些事件可靠地發布至事件平臺。

圖 3：發件箱和收件箱模式

僅靠發件箱模式無法解決重復發送問題，因為事件系統通常只保證至少一次投遞。消費者端的收件箱模式可以解決這一問題：每個事件會在業務邏輯執行前被記錄，重復事件則直接被忽略。兩種模式結合使用，既可避免事件丟失與重復，也無需讓每位工程師重復解決相同的可靠性問題。

事件契約是永久性的

事件有助于實現系統解耦，但同時也形成了持久的契約。一旦事件發布，它可能會永久存在，并支持從任意時間點重放。刪除或修改事件中的字段可能會導致消費者報錯，更糟糕的是，還可能在處理邏輯中引發不易察覺的隱性問題。重寫歷史事件以掩蓋錯誤會破壞整個架構，應當避免。

看待事件最穩妥的方式是將其視作公共 API。謹慎定義事件，并假定消費者會以你意料之外的方式使用它們。應盡可能避免破壞性變更，若此類變更無法避免，需對事件進行版本控制。在元數據中加入版本標識，可讓消費者安全處理多個版本的事件，并在無中斷的情況下重放事件流。

將領域事件與集成事件分離能夠增加一層保護。領域事件僅針對特定限界上下文，可以更靈活地演進；而集成事件可以跨上下文使用，需要保持穩定且定義清晰。這種分離可避免內部概念泄露到外部契約中，導致后續難以修改。

需要注意事件順序

事件順序是一個微妙卻至關重要的問題。大多數云原生事件平臺會優先考慮可擴展性，而非嚴格的順序保證。重試、退避策略與并行處理都可能導致事件亂序到達。這在某些領域中并無大礙，但在另一些場景下則會引發嚴重問題。

有兩種有效方法可以解決這一問題。第一種是顯式排序，讓事件攜帶與聚合關聯的版本號或序列號。消費者隨后通過收件箱邏輯強制保證順序，僅在已接收到較早事件后才處理當前事件。這種方法有效，但可能會降低系統的伸縮性。

第二種是隱式排序，讓領域自己強制執行有效的狀態轉換。例如，只有當相關受益人存在，支付才能被處理。隱式排序無需顯式控制順序即可保證業務正確性，通常具備更好的伸縮性。這兩種方法均有效，關鍵在于要將排序作為一項主動的設計決策，而不是等到部署到生產環境后才發現其重要性遠超預期。

整合在一起

本文所示的事件驅動架構將有界上下文內的領域事件與跨邊界的集成事件相結合，并配合收件箱與發件箱模式，構建出高彈性、可伸縮且可審計的系統。每一次有意義的狀態變更都會被記錄為事件，并在數據持久化的同時被可靠發布；消費者則通過收件箱處理事件，確保冪等性。這種設計能夠有效避免事件丟失與重復，這在監管嚴格的銀行業環境中尤為關鍵。

圖 4：完整的架構

將領域事件與集成事件分離尤為重要。領域事件在有界上下文內可自由演進，而集成事件則作為系統間穩定、帶版本的契約。我們通過在這些邊界對事件進行過濾、聚合與轉換，避免了內部領域概念的泄露，讓系統能夠獨立變更而不影響消費者。

解耦同樣能帶來切實的運維好處。即便下游服務不可用，支付流程仍可繼續；可通過訂閱現有事件流來實現新的功能，無需改動核心平臺。事件還形成了天然的審計追蹤記錄，為交易生命周期提供端到端的可見性，滿足故障排查與監管合規需求。

將這些模式融入共享開發者平臺能夠實現更統一的落地。服務模板、共享模塊以及內置的可靠性機制讓團隊可以專注于業務邏輯，而非重復解決基礎設施問題。同時，培訓也能確保工程師理解這些系統在生產環境中的實際運行表現，而不只是知道如何搭建它們。

結 論

事件驅動架構既非捷徑，也無法帶來一勞永逸的效果。它引入了新的復雜形態、新的故障模式，以及對系統設計截然不同的思考方式。但只要謹慎應用，配合清晰的事件契約、經過驗證的可靠性模式，以及對工程團隊的有力支持，它就能成為構建現代銀行平臺的堅實基礎。

根據我們的實踐經驗，這種方案讓我們在滿足嚴格監管要求的同時依然能夠擁抱云原生架構的敏捷性，支撐起高彈性、可擴展且透明的系統。運用得當的話，事件驅動架構不只是一項技術決策，更是一種運維與組織層面的承諾，深刻影響著團隊構建、運行和迭代核心系統的方式。

查看英文原文：

https://www.infoq.com/articles/event-driven-banking-architecture/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。