作者 | Chris Tacey-Green

譯者 | 明知山

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

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

有了這些基礎(chǔ)，理解事件驅(qū)動架構(gòu)是什么、適用于哪些場景、帶來了哪些權(quán)衡取舍以及為何即便存在監(jiān)管約束，它依然是銀行系統(tǒng)的合適選擇，都會變得容易得多。

什么是事件？

事件是系統(tǒng)內(nèi)部發(fā)生的某種狀態(tài)變更。這種變更可由用戶操作、異步后臺進(jìn)程或外部系統(tǒng)與平臺交互觸發(fā)。事件既可以攜帶描述變更情況的數(shù)據(jù)，也可以作為輕量級通知，僅表明某件事已經(jīng)發(fā)生。

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

命令與事件并不相同

事件驅(qū)動系統(tǒng)中最重要的區(qū)別之一就是命令與事件之間的差異，這也是最容易被誤解的概念之一。如果團(tuán)隊模糊了這一界限，最終往往會得到看似事件驅(qū)動、卻無法實現(xiàn)預(yù)期收益的架構(gòu)。

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

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

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

事件驅(qū)動架構(gòu)的真正含義

有了這些定義，描述事件驅(qū)動架構(gòu)就變得更加容易。它是一種系統(tǒng)通過發(fā)布和響應(yīng)事件來實現(xiàn)通信的架構(gòu)風(fēng)格。生產(chǎn)者將事件發(fā)送至事件平臺，消費者訂閱自己關(guān)心的事件。生產(chǎn)者無需知曉哪些系統(tǒng)在消費事件，甚至無需關(guān)心是否有系統(tǒng)在消費。

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

事件溯源或許很強(qiáng)大，但也相當(dāng)復(fù)雜，且難以實現(xiàn)到位。更重要的是，它并非事件驅(qū)動架構(gòu)的前提條件。兩者經(jīng)常被放在一起討論，這是因為事件溯源系統(tǒng)會產(chǎn)生事件，但采用事件驅(qū)動通信并不意味著必須使用事件溯源。

云原生實戰(zhàn)

云原生并非只是將工作負(fù)載運行在云端。云平臺幾乎可以支持任何運維模式，而云原生系統(tǒng)更強(qiáng)調(diào)采用現(xiàn)代工程實踐，在設(shè)計上具備可擴(kuò)展性、支持頻繁部署，并依靠自動化而非人工操作來完成運維。

這些系統(tǒng)通常采用微服務(wù)構(gòu)建，但模塊化單體也同樣適用。架構(gòu)結(jié)構(gòu)并非關(guān)鍵，重要的是采用現(xiàn)代化的 DevOps 實踐，例如持續(xù)集成、持續(xù)部署以及基礎(chǔ)設(shè)施即代碼。在這一背景下，事件驅(qū)動架構(gòu)是順理成章的選擇。它支持異步通信、松耦合與獨立部署，與云原生系統(tǒng)的構(gòu)建和運維方式高度契合。

銀行業(yè)環(huán)境下的約束考量

銀行業(yè)的特性給架構(gòu)設(shè)計帶來了額外的約束。銀行是規(guī)模龐大、監(jiān)管嚴(yán)格的機(jī)構(gòu)，承擔(dān)著保護(hù)客戶資金的核心責(zé)任。監(jiān)管不僅影響技術(shù)決策，還塑造著組織文化、風(fēng)險容忍度與變革節(jié)奏。因此，這類機(jī)構(gòu)對新型架構(gòu)模式往往持謹(jǐn)慎態(tài)度，也就不足為奇了。

與此同時，現(xiàn)代工程實踐已不再是可選項。金融系統(tǒng)的規(guī)模與復(fù)雜度持續(xù)提升，客戶期望也在不斷提高。在天達(dá)銀行（Investec，一家英南非合資的國際銀行及財富管理集團(tuán)），我們在滿足嚴(yán)格監(jiān)管要求的同時也在積極采用云原生與事件驅(qū)動架構(gòu)。

為什么事件驅(qū)動架構(gòu)很重要

弄清楚了基礎(chǔ)概念，事件驅(qū)動架構(gòu)的價值便不難理解。這些優(yōu)勢并非停留在理論層面，而是直接體現(xiàn)在銀行業(yè)的實際生產(chǎn)場景中。

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

圖 1：銀行系統(tǒng)中的解耦

事件驅(qū)動系統(tǒng)還會生成不可變的活動日志。在復(fù)雜的支付流程中，事件不僅是輔助性的審計追蹤記錄，更是業(yè)務(wù)實際發(fā)生情況的真實憑證?；顒尤罩咀寛F(tuán)隊能夠清晰地掌握支付全生命周期，提升了故障排查效率，同時也有助于滿足監(jiān)管機(jī)構(gòu)對可追溯性的要求。

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

圖 2：銀行系統(tǒng)中的扇出

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

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

痛點與解決方案

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

人為層面的挑戰(zhàn)

事件驅(qū)動架構(gòu)面臨的最大挑戰(zhàn)并非技術(shù)層面，而是思維模式的轉(zhuǎn)變。工程師需要建立異步通信、最終一致性與獨立故障處理的思維，而非默認(rèn)采用熟悉的同步請求與響應(yīng)模式。

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

工具和賦能

應(yīng)對人為層面的挑戰(zhàn)僅靠良好意愿遠(yuǎn)遠(yuǎn)不夠，還需要嚴(yán)謹(jǐn)?shù)墓ぞ咧闻c能力賦能。在前期投入構(gòu)建完善的開發(fā)者平臺，搭配設(shè)計精良的模板與共享模塊，能帶來切實有效的提升。已標(biāo)準(zhǔn)化的落地路徑可以幫助新團(tuán)隊快速落地事件驅(qū)動微服務(wù)，避免重復(fù)造輪子。

擁有強(qiáng)大的平臺還遠(yuǎn)遠(yuǎn)不夠，培訓(xùn)同樣至關(guān)重要。為團(tuán)隊配備強(qiáng)大的工具，但他們卻不知道這些系統(tǒng)在生產(chǎn)環(huán)境中的運行特性，尤其是故障往往發(fā)生在凌晨時分，這存在極大的風(fēng)險。對此，我們讓賦能團(tuán)隊與交付團(tuán)隊結(jié)對協(xié)作，共同設(shè)計并構(gòu)建出小型實用的事件驅(qū)動系統(tǒng)，隨后投入生產(chǎn)。這種方式遠(yuǎn)比單純依賴文檔更為有效，也能讓團(tuán)隊具備獨立構(gòu)建系統(tǒng)的信心。

早期在標(biāo)準(zhǔn)上達(dá)成共識同樣重要。預(yù)先統(tǒng)一事件契約、權(quán)限體系與核心技術(shù)方案能夠避免技術(shù)碎片化，讓整個組織更便捷地消費事件。

防止事件丟失或重復(fù)

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

我們依靠發(fā)件箱與收件箱模式來降低此類風(fēng)險。發(fā)件箱模式確保狀態(tài)變更與事件發(fā)布在同一事務(wù)邊界內(nèi)完成，從而避免事件丟失，再由調(diào)度程序?qū)⑦@些事件可靠地發(fā)布至事件平臺。

圖 3：發(fā)件箱和收件箱模式

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

事件契約是永久性的

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

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

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

需要注意事件順序

事件順序是一個微妙卻至關(guān)重要的問題。大多數(shù)云原生事件平臺會優(yōu)先考慮可擴(kuò)展性，而非嚴(yán)格的順序保證。重試、退避策略與并行處理都可能導(dǎo)致事件亂序到達(dá)。這在某些領(lǐng)域中并無大礙，但在另一些場景下則會引發(fā)嚴(yán)重問題。

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

第二種是隱式排序，讓領(lǐng)域自己強(qiáng)制執(zhí)行有效的狀態(tài)轉(zhuǎn)換。例如，只有當(dāng)相關(guān)受益人存在，支付才能被處理。隱式排序無需顯式控制順序即可保證業(yè)務(wù)正確性，通常具備更好的伸縮性。這兩種方法均有效，關(guān)鍵在于要將排序作為一項主動的設(shè)計決策，而不是等到部署到生產(chǎn)環(huán)境后才發(fā)現(xiàn)其重要性遠(yuǎn)超預(yù)期。

整合在一起

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

圖 4：完整的架構(gòu)

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

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

將這些模式融入共享開發(fā)者平臺能夠?qū)崿F(xiàn)更統(tǒng)一的落地。服務(wù)模板、共享模塊以及內(nèi)置的可靠性機(jī)制讓團(tuán)隊可以專注于業(yè)務(wù)邏輯，而非重復(fù)解決基礎(chǔ)設(shè)施問題。同時，培訓(xùn)也能確保工程師理解這些系統(tǒng)在生產(chǎn)環(huán)境中的實際運行表現(xiàn)，而不只是知道如何搭建它們。

結(jié) 論

事件驅(qū)動架構(gòu)既非捷徑，也無法帶來一勞永逸的效果。它引入了新的復(fù)雜形態(tài)、新的故障模式，以及對系統(tǒng)設(shè)計截然不同的思考方式。但只要謹(jǐn)慎應(yīng)用，配合清晰的事件契約、經(jīng)過驗證的可靠性模式，以及對工程團(tuán)隊的有力支持，它就能成為構(gòu)建現(xiàn)代銀行平臺的堅實基礎(chǔ)。

根據(jù)我們的實踐經(jīng)驗，這種方案讓我們在滿足嚴(yán)格監(jiān)管要求的同時依然能夠擁抱云原生架構(gòu)的敏捷性，支撐起高彈性、可擴(kuò)展且透明的系統(tǒng)。運用得當(dāng)?shù)脑?，事件?qū)動架構(gòu)不只是一項技術(shù)決策，更是一種運維與組織層面的承諾，深刻影響著團(tuán)隊構(gòu)建、運行和迭代核心系統(tǒng)的方式。

查看英文原文：

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

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。