最近在維護(hù) daisy-framework 的時候我重新把 event、listener 這套事件監(jiān)聽機(jī)制從源碼到業(yè)務(wù)用整個過了一遍。說實話事件監(jiān)聽在任何一個服務(wù)端框架里都不算新東西但真正能把“事件怎么定義、監(jiān)聽器怎么注冊、發(fā)布之后是同步還是異步、異常怎么處理”講清楚的文章并不多。daisy-framework 把事件監(jiān)聽作為一個獨立模塊放進(jìn)核心包初衷很簡單把業(yè)務(wù)主流程里的橫切動作拆出去讓下單只操心下單庫存、通知、日志這些事由事件驅(qū)動去完成。這篇文章我會從設(shè)計思路開始依次講清楚事件對象的定義規(guī)范、監(jiān)聽器的三種注冊方式、事件發(fā)布全流程、異步監(jiān)聽和事務(wù)綁定的取舍最后附上我實際踩坑整理的問題排查表。適合正在用 daisy-framework 做業(yè)務(wù)開發(fā)的伙伴也適合任何想搞懂事件驅(qū)動設(shè)計的人。文章里的代碼都來自一個我稱之為“模擬項目X”的真實改造過程很直接不繞彎。1. 為什么 daisy-framework 要內(nèi)置一套事件監(jiān)聽機(jī)制1.1 事件監(jiān)聽解決的是哪個層面的問題業(yè)務(wù)代碼里最難纏的不是算法而是各種“順便處理”的業(yè)務(wù)。訂單支付成功要減庫存、發(fā)優(yōu)惠券、更新會員等級、寫審計日志、通知運營群——如果這些代碼全部寫在支付回調(diào)里一個方法幾百行是常態(tài)。更要命的是它們之間沒有先后邏輯但因為寫在同一個方法里被強(qiáng)制串行執(zhí)行哪天通知服務(wù)變慢了支付主流程也跟著慢。事件監(jiān)聽就是把這堆“順便處理”從主流程里剝離的手段。支付回調(diào)只做一件事發(fā)布一個訂單支付成功事件。至于誰關(guān)心這個事件由 daisy-framework 的事件調(diào)度器去分發(fā)。事件發(fā)布方和被通知方之間沒有直接依賴這正是事件驅(qū)動最核心的價值。我在實際項目里最直觀的感受是沒有事件監(jiān)聽時加一個新動作要改老代碼有了事件監(jiān)聽后加一個新動作只是新增一個監(jiān)聽器主流程代碼一行不動。這個差別在項目中期特別明顯功能越多優(yōu)勢越大。1.2 daisy 事件機(jī)制的幾個關(guān)鍵設(shè)計約束daisy-framework 的事件模塊在基礎(chǔ)包里實現(xiàn)API 不大但約束很明確。事件默認(rèn)在進(jìn)程內(nèi)分發(fā)不依賴外部存儲。發(fā)布事件是內(nèi)存操作性能好但同時也意味著事件不會持久化進(jìn)程重啟后未處理的事件就沒了。這決定了 daisy 的事件適合做業(yè)務(wù)編排和狀態(tài)通知不適合做需要保證不丟數(shù)據(jù)的消息傳遞。監(jiān)聽器默認(rèn)同步執(zhí)行。同步的好處是事務(wù)、日志上下文、用戶會話都能天然傳遞。需要異步時用顯式注解聲明異步是例外而不是默認(rèn)。這個設(shè)計我非常認(rèn)可它強(qiáng)迫你先思考“這個監(jiān)聽器真的需要異步嗎”而不是一股腦把問題丟給線程池。支持優(yōu)先級排序和條件過濾。同一個事件可以被多個監(jiān)聽器按優(yōu)先級從小到大依次處理條件過濾則通過注解的 condition 屬性實現(xiàn)避免在監(jiān)聽器方法內(nèi)部寫一堆 if 判斷。1.3 和消息隊列的區(qū)別先分清楚再動手很多初學(xué)者把框架事件監(jiān)聽和消息隊列混在一起我見過不止一次。daisy 的事件監(jiān)聽強(qiáng)調(diào)的是“進(jìn)程內(nèi)解耦”消息隊列強(qiáng)調(diào)的是“跨進(jìn)程可靠傳遞”。舉個例子訂單支付后給用戶發(fā)送 App 推送這件事可以走 daisy 監(jiān)聽器因為推送邏輯在同一個服務(wù)進(jìn)程內(nèi)失敗了大不了記錄日志稍后重試或者接受偶發(fā)失敗。但如果訂單數(shù)據(jù)要同步到大數(shù)據(jù)平臺那就不能只靠事件監(jiān)聽了應(yīng)該把訂單支付成功事件轉(zhuǎn)成消息投遞到消息中間件由下游服務(wù)消費。說白了事件監(jiān)聽解決的是代碼結(jié)構(gòu)問題消息隊列解決的是系統(tǒng)架構(gòu)問題。判斷用哪套機(jī)制有個很簡單的標(biāo)準(zhǔn)監(jiān)聽器和發(fā)布者會不會部署在兩個不同的進(jìn)程里如果會就不要用 daisy 自帶事件如果不會優(yōu)先用自帶事件。別一上來就上消息隊列成本和復(fù)雜度完全不同。2. 事件定義與監(jiān)聽器聲明動手前的關(guān)鍵設(shè)計2.1 先寫事件類好的事件對象長什么樣事件類看起來簡單其實設(shè)計不好很影響后續(xù)維護(hù)。先看我常用的寫法以訂單支付成功事件為例public class OrderPaidEvent implements DaisyEvent { private final String orderNo; private final Long userId; private final BigDecimal paidAmount; private final LocalDateTime paidAt; public OrderPaidEvent(String orderNo, Long userId, BigDecimal paidAmount, LocalDateTime paidAt) { this.orderNo orderNo; this.userId userId; this.paidAmount paidAmount; this.paidAt paidAt; } public String getOrderNo() { return orderNo; } public Long getUserId() { return userId; } public BigDecimal getPaidAmount() { return paidAmount; } public LocalDateTime getPaidAt() { return paidAt; } }這里有三條經(jīng)驗都是我在真實項目里付出過代價換來的。第一事件對象建議做成不可變字段全用 final只提供 getter。原因很簡單事件在發(fā)布后可能被多個監(jiān)聽器讀取如果有人中途改了某個字段后面的監(jiān)聽器拿到的數(shù)據(jù)就是不一致的這種 bug 極難定位。事件發(fā)布出去之后就把它當(dāng)成一個只讀快照誰都不該碰它的內(nèi)部狀態(tài)。第二事件里傳 ID 而不是傳整個實體。傳 Order 對象雖然方便但監(jiān)聽器處理時如果去讀 Order 的某個屬性而這個對象已經(jīng)脫離了數(shù)據(jù)庫狀態(tài)甚至已經(jīng)被后續(xù)流程修改它并不代表真實數(shù)據(jù)。傳 orderNo、userId 這類 ID監(jiān)聽器在需要完整數(shù)據(jù)時自己按 ID 去查詢能保證拿到的數(shù)據(jù)是最新的也能避免事件對象被無意改壞。第三事件命名用過去時。OrderPaidEvent、StockDeductedEvent 這類完成時態(tài)名字暗示“已經(jīng)發(fā)生”而 OrderPayEvent 這種命令式勉強(qiáng)能用但語義不清晰。命令式事件容易讓人把監(jiān)聽器寫成“替發(fā)布者執(zhí)行任務(wù)”這就和命令模式混淆了事件模型就變味了。2.2 用注解聲明監(jiān)聽器最常用的方式我在模擬項目X里90% 的監(jiān)聽器都用注解方式寫。代碼看起來是這樣的Component DaisyEventListener public class OrderPaidListener { DaisySubscribe(priority 10) public void deductStock(OrderPaidEvent event) { // 庫存扣減邏輯 } DaisySubscribe(priority 20) public void grantCoupon(OrderPaidEvent event) { // 發(fā)券邏輯 } }解釋一下 DaisySubscribe 的 priority。值越小越先執(zhí)行默認(rèn)值是 100。業(yè)務(wù)上如果“先扣庫存后發(fā)券”有嚴(yán)格順序就把優(yōu)先級拉開。但我一般不建議把太多順序依賴放到優(yōu)先級上。如果監(jiān)聽器之間存在強(qiáng)順序依賴更好的辦法是合并成一個監(jiān)聽器或者把這個順序用注釋寫清楚放在文檔里。DaisySubscribe 可以直接加在普通方法上框架通過反射拿到方法參數(shù)列表的第一個參數(shù)作為事件類型。方法可以額外接收事件上下文參數(shù)拿到發(fā)布源、時間戳等信息。這個細(xì)節(jié)很多文檔沒寫我替大家踩過了后面排查問題時會用到。還有一個值得提的點一個監(jiān)聽器類可以定義多個方法分別監(jiān)聽不同類型的事件。這在實際開發(fā)中很方便比如同一個類里處理訂單相關(guān)的所有通知動作不用拆得七零八落。2.3 接口方式注冊監(jiān)聽器的適用場景注解不是唯一的注冊方式daisy 也保留了接口式注冊例如Component public class StockChangeListener implements DaisyEventListenerStockChangedEvent { Override public void onEvent(StockChangedEvent event) { // 庫存變化后的處理 } }這種寫法的好處是事件類型通過泛型直接確定不需要反射解析參數(shù)排查起來更加直白。缺點是每個監(jiān)聽器類只能處理一種事件一個類要監(jiān)聽多個事件就得寫多個類。我看到有些團(tuán)隊把接口方式和注解方式混用這本身沒問題。但建議在項目規(guī)范里約定同一個模塊盡量統(tǒng)一用一種方式。我這里的基本約定是單個事件的復(fù)雜處理邏輯用接口方式一個監(jiān)聽器里承載多個相似事件、處理方法很短的用注解方式。兩種方式生成的監(jiān)聽器對象在注冊表里是共存的不會有沖突。2.4 監(jiān)聽器的掃描與注冊機(jī)制daisy 在應(yīng)用啟動時會做兩件事掃描加了 DaisyEventListener 的類以及掃描實現(xiàn) DaisyEventListener 接口的類。掃描到的監(jiān)聽器實例統(tǒng)一以單例保存在一個注冊表里key 是事件類型value 是該事件對應(yīng)的一組監(jiān)聽器方法包裝對象。每次 publish 一個事件調(diào)度器先從注冊表按事件類型找到候選監(jiān)聽器集合如果事件類型是某個父類的子類也會匹配到監(jiān)聽父類的監(jiān)聽器。這個“父子事件匹配”特性很有用比如所有業(yè)務(wù)事件都繼承同一個基類事件那只需要寫一個監(jiān)聽基類的監(jiān)聽器就能統(tǒng)一做埋點或?qū)徲嫛Ｗ⒁獗O(jiān)聽器注冊發(fā)生在應(yīng)用啟動階段。如果你在運行期手動 new 了一個監(jiān)聽器但沒注冊進(jìn)容器那它是永遠(yuǎn)不會被觸發(fā)的。這也是排查“監(jiān)聽器不生效”問題時要先確認(rèn)的一點。3. 從發(fā)布到觸發(fā)事件監(jiān)聽的完整執(zhí)行鏈路3.1 業(yè)務(wù)代碼里如何發(fā)布事件先給出最直觀的調(diào)用方式RestController public class OrderController { private final EventDispatcher dispatcher; public OrderController(EventDispatcher dispatcher) { this.dispatcher dispatcher; } PostMapping(/pay) public Result pay(RequestBody PayRequest request) { // 1. 支付相關(guān)業(yè)務(wù)處理 OrderPaidResult paidResult paymentService.pay(request); // 2. 發(fā)布事件 dispatcher.publish(new OrderPaidEvent( paidResult.getOrderNo(), request.getUserId(), paidResult.getPaidAmount(), LocalDateTime.now() )); return Result.success(); } }發(fā)布接口很簡單但有幾個執(zhí)行細(xì)節(jié)值得注意。EventDispatcher.publish 默認(rèn)是同步的它會在當(dāng)前線程里依次調(diào)用所有匹配的監(jiān)聽器方法全部執(zhí)行完 publish 方法才返回。如果你的監(jiān)聽器里有耗時操作發(fā)布這一行也會跟著變慢。我見過有人因此誤判“事件發(fā)布很慢”實際上慢的是監(jiān)聽器里的業(yè)務(wù)邏輯。另外發(fā)布事件時傳入的事件對象不要重復(fù)使用。publish 之后如果還在同一個方法里對它做改動監(jiān)聽器看到的可能是改到一半的狀態(tài)。最保險的做法是發(fā)布后立即丟棄引用或者堅持使用不可變對象。3.2 一個訂單支付事件實際執(zhí)行順序還原我在模擬項目X里做過一個完整測試當(dāng)時注冊了三類監(jiān)聽器第一個優(yōu)先級是 10負(fù)責(zé)扣減庫存第二個優(yōu)先級是 20負(fù)責(zé)發(fā)送 App 推送第三個優(yōu)先級是 30負(fù)責(zé)寫審計日志。它們的執(zhí)行順序是嚴(yán)格按 priority 從小到大在同一線程里逐個執(zhí)行。具體流程可以這樣理解入口是訂單支付接口支付成功后在當(dāng)前線程調(diào)用 dispatcher.publish(event)框架根據(jù) event 的實際類型找到候選監(jiān)聽器列表框架按 priority 排序依次執(zhí)行扣庫存、發(fā)推送、寫日志所有監(jiān)聽器返回后publish 方法返回控制器繼續(xù)執(zhí)行。這條鏈路里沒有創(chuàng)建新線程也沒有切換線程上下文。正因為都是在調(diào)用線程里跑監(jiān)聽器里的事務(wù)注解、traceId、當(dāng)前登錄用戶都能直接用。這也是同步監(jiān)聽的天然優(yōu)勢。如果你在監(jiān)聽器方法上加了異步注解情況就變了框架會把這個方法包裝成任務(wù)提交到線程池publish 方法不等它執(zhí)行完馬上返回真正的執(zhí)行發(fā)生在線程池的工作線程里。這里必須提醒異步監(jiān)聽器里不要再依賴主線程的事務(wù)和用戶上下文除非你做了顯式傳遞。3.3 監(jiān)聽器拋異常了后面怎么走這個點每種框架設(shè)計都不一樣daisy 的默認(rèn)策略是同步監(jiān)聽器執(zhí)行過程中如果拋出異常異常會沿調(diào)用棧向上拋給 publish 調(diào)用方后續(xù)監(jiān)聽器不再執(zhí)行。也就是說如果扣庫存的監(jiān)聽器掛了訂單支付接口會拿到異常發(fā)推送的監(jiān)聽器也不會執(zhí)行。這個設(shè)計在某些場景下合理在某些場景下就很不近人情。比如你只是寫個審計日志它失敗了卻把訂單支付接口給打掛了這顯然不合理。解決辦法有兩個。方案一在監(jiān)聽器方法內(nèi)部捕獲異常并自行處理適合對異常不敏感的邏輯方案二使用框架提供的忽略異常參數(shù)讓框架捕獲異常并記錄日志不中斷后續(xù)監(jiān)聽器。我的建議是核心業(yè)務(wù)監(jiān)聽器用默認(rèn)的異常上拋策略日志、通知類監(jiān)聽器顯式打開忽略異常別讓輔助邏輯拖垮主流程。4. 異步監(jiān)聽與事務(wù)綁定使用頻率最高也最容易出錯的兩塊4.1 異步監(jiān)聽器正確寫法與線程池配置先看代碼Component DaisyEventListener public class NotificationListener { DaisyAsync DaisySubscribe(priority 20) public void sendPush(OrderPaidEvent event) { // 發(fā)送 App 推送 } }異步注解放在 DaisySubscribe 方法上框架檢測到這個注解后會把監(jiān)聽器方法和異步任務(wù)綁定。對于異步監(jiān)聽我踩過三個坑逐個說。第一個坑是線程池默認(rèn)參數(shù)太小。daisy 默認(rèn)的異步線程池核心線程數(shù)是 CPU 核數(shù)隊列容量 1024。輕量場景沒問題但如果有大量異步監(jiān)聽任務(wù)一旦隊列滿了后續(xù)任務(wù)就會被拒絕。我通常會在配置里顯式調(diào)大daisy.event.async.core-pool-size8 daisy.event.async.max-pool-size32 daisy.event.async.queue-capacity2048 daisy.event.async.keep-alive-seconds60第二個坑是異步監(jiān)聽器里的異常不會被調(diào)用方感知。主流程早就返回了監(jiān)聽器執(zhí)行異常只能靠框架日志和監(jiān)控告警發(fā)現(xiàn)。所以異步監(jiān)聽器內(nèi)部一定要有完善的日志和異常捕獲否則出了問題就是黑盒等用戶來投訴你才知道。第三個坑是上下文丟失。異步線程里沒有主線程的 ThreadLocaltraceId、當(dāng)前用戶 ID 可能都是空的。我的解法是在發(fā)布前把上下文信息塞進(jìn)事件對象里比如在事件里加一個 operatorId 字段或者在異步線程池的任務(wù)包裝中顯式傳遞 ThreadLocal。我更推薦前者代碼里清清楚楚出了問題也好查。4.2 事務(wù)提交后再觸發(fā)事件的必要性這個點特別值得單獨說。假設(shè)你的監(jiān)聽器做的是“支付成功后給用戶發(fā)權(quán)益”如果監(jiān)聽器在事務(wù)提交前執(zhí)行會發(fā)生什么看一個真實場景主服務(wù)方法開啟了事務(wù)業(yè)務(wù)邏輯更新訂單狀態(tài)發(fā)布訂單支付成功事件隨后事務(wù)提交。發(fā)布時監(jiān)聽器同步執(zhí)行它去查詢訂單狀態(tài)發(fā)現(xiàn)訂單還是“待支付”因為事務(wù)還沒提交。這就是典型的“事件先于事務(wù)提交”問題。daisy 提供的解法是事務(wù)同步事件讓事件在事務(wù)提交之后才真正觸發(fā)Transactional public void payOrder(String orderNo, Long userId, BigDecimal amount) { // 更新訂單狀態(tài)、扣減余額 orderDao.updateStatus(orderNo, PAID); // 注冊一個事務(wù)同步事件真正觸發(fā)是在提交成功后 EventDispatcher.publishAfterTransactionCommit( new OrderPaidEvent(orderNo, userId, amount, LocalDateTime.now()) ); }publishAfterTransactionCommit 的底層是注冊一個事務(wù)同步回調(diào)事務(wù)提交成功后由框架回調(diào)觸發(fā)監(jiān)聽器如果事務(wù)回滾了這個事件根本不會發(fā)布。這對一致性非常有價值狀態(tài)變更真正落庫后才通知下游做后續(xù)動作。注意publishAfterTransactionCommit 依賴當(dāng)前線程存在活躍事務(wù)。如果方法沒有事務(wù)daisy 會拋出異常提示。這是框架刻意為之防止你誤以為事件一定在提交后觸發(fā)結(jié)果卻立刻被同步執(zhí)行了。4.3 事務(wù)與異步組合時的執(zhí)行時序有人會問事務(wù)提交后再觸發(fā)監(jiān)聽器方法上又加了異步注解這兩個能組合嗎當(dāng)然可以。組合后的語義是事務(wù)提交成功后再把監(jiān)聽器任務(wù)丟到異步線程池執(zhí)行。這個組合很適合一個場景事務(wù)提交后發(fā)通知但不想阻塞主線程。比如支付成功發(fā)推送既要保證訂單狀態(tài)落庫后才觸發(fā)又不想推送這種耗時操作拖住接口響應(yīng)。代碼大致長這樣DaisyAsync DaisySubscribe(priority 20) public void sendPush(OrderPaidEvent event) { // 事務(wù)提交后異步發(fā)送推送 }執(zhí)行順序要理清楚主事務(wù)提交 - 事務(wù)同步回調(diào)觸發(fā) - 框架把 sendPush 放入異步線程池 - 主線程繼續(xù)返回 - 線程池執(zhí)行 sendPush。這三個環(huán)節(jié)是串行疊加的不是又異步又同步理解這一點就不會搞混。不過我不建議一個項目里大量濫用這種組合。每一次異步都是一次追蹤成本異步加事務(wù)組合更是雙重成本。讓費用花在刀刃上就行大部分場景用默認(rèn)同步就夠了。5. 實戰(zhàn)問題排查監(jiān)聽器不觸發(fā)、重復(fù)觸發(fā)與性能瓶頸5.1 監(jiān)聽器不觸發(fā)的排查清單我在使用過程中收集了一些典型問題整理成速查表現(xiàn)象可能原因排查方向監(jiān)聽器完全沒執(zhí)行事件類型不匹配檢查發(fā)布的事件類型與監(jiān)聽器參數(shù)類型是否一致監(jiān)聽器完全沒執(zhí)行監(jiān)聽器未注冊確認(rèn)類上有注解且被組件掃描監(jiān)聽器完全沒執(zhí)行監(jiān)聽器實例是手動 new 的確認(rèn)監(jiān)聽器由框架容器管理監(jiān)聽器執(zhí)行順序不對優(yōu)先級沒調(diào)檢查注解的 priority 屬性事件沒觸發(fā)發(fā)布代碼在子線程確認(rèn) publish 調(diào)用線程與事務(wù)線程一致事務(wù)事件沒觸發(fā)事務(wù)回滾查看數(shù)據(jù)庫是否真的提交成功異步監(jiān)聽沒執(zhí)行線程池被拒絕查看異步線程池拒絕策略與日志第一條“事件類型不匹配”是最高頻問題。很多人發(fā)布一個子類事件監(jiān)聽器卻寫成監(jiān)聽父類事件如果父子匹配邏輯沒有正確開啟那自然觸發(fā)不了。daisy 默認(rèn)支持子類事件匹配但前提是發(fā)布時傳入的事件對象實際類型是子類不能把子類對象強(qiáng)轉(zhuǎn)成父類后再發(fā)布?！氨O(jiān)聽器未注冊”也經(jīng)常出現(xiàn)。排查辦法很簡單啟動日志里會打印注冊過的監(jiān)聽器列表先確認(rèn)你的監(jiān)聽器類有沒有出現(xiàn)在里面。沒出現(xiàn)就是掃描路徑的問題出現(xiàn)了但不觸發(fā)再去查事件類型和優(yōu)先級。5.2 事件重復(fù)觸發(fā)三種常見姿勢事件重復(fù)觸發(fā)比不觸發(fā)更難排查因為日志看起來一切正常只是下游狀態(tài)亂了。我歸納為三類。第一類是自發(fā)布循環(huán)。監(jiān)聽器處理完業(yè)務(wù)后又發(fā)布了一個同類事件自己監(jiān)聽自己形成無限循環(huán)。這種問題通常表現(xiàn)為某個監(jiān)聽器被反復(fù)執(zhí)行甚至打爆線程池。解決方法是約定監(jiān)聽器里不允許發(fā)布它正在監(jiān)聽的那一類事件如果必須發(fā)布要在事件對象里帶一個來源標(biāo)記自己判斷后跳過。第二類是事務(wù)重試導(dǎo)致的重復(fù)發(fā)布。業(yè)務(wù)方法里先發(fā)布事件事務(wù)失敗后框架重試同一個事件就被發(fā)布了兩三次。這種問題最佳解是事件發(fā)布放在事務(wù)提交成功后也就是用發(fā)布事務(wù)同步事件同時事件對象里帶上唯一標(biāo)識監(jiān)聽器消費時做冪等判斷。第三類是監(jiān)聽器注冊重復(fù)。比如同一個類既加了 DaisyEventListener又在配置里被手工注冊了一次注冊表里就有兩個相同的監(jiān)聽器副本。排查時注意看啟動日志里是否有重復(fù)注冊的警告。5.3 同步鏈路太長怎么優(yōu)化如果你的某個監(jiān)聽器特別慢慢到主接口超時別急著把它改成異步。先定位慢的原因可能是它在查詢大量數(shù)據(jù)可能是它在調(diào)外部接口也可能是它在循環(huán)里做復(fù)雜計算。我的優(yōu)化順序是先給監(jiān)聽器加好日志和耗時統(tǒng)計確認(rèn)瓶頸所在能并行處理的多個監(jiān)聽器可以考慮用框架提供的并行支持允許多個同級監(jiān)聽器并發(fā)執(zhí)行最后才考慮異步化。為什么最后才異步因為異步引入了線程池、上下文傳遞、異常隔離三層復(fù)雜度能不用就不用。并行執(zhí)行適用于那些彼此之間沒有順序依賴、可以同時跑的邏輯。但要注意并發(fā)執(zhí)行時不要共享同一個可變對象事件對象必須是只讀的。否則兩個線程同時讀一個集合一個改一個讀很容易出并發(fā)問題。6. 用事件監(jiān)聽重構(gòu)一段支付鏈路的真實記錄6.1 重構(gòu)前一把梭的支付回調(diào)模擬項目X早期是一段支付回調(diào)寫完所有動作的。核心方法大約 180 行里面依次是更新訂單狀態(tài)、扣庫存、給用戶加積分、寫訂單操作日志、調(diào)用消息服務(wù)發(fā)通知、調(diào)用問卷服務(wù)發(fā)調(diào)查邀請。每次上線加需求都要改這個方法而且必須小心翼翼不破壞原有順序。那段時間最痛苦的是日常問題排查用戶反饋說支付成功但沒收到優(yōu)惠券我得打開這段 180 行的老代碼從頭到尾捋還要看是不是前一步異常導(dǎo)致后面的邏輯沒執(zhí)行。問題定位一次可能花一小時。后來我們把整段邏輯改成事件驅(qū)動效果非常明顯。6.2 重構(gòu)后發(fā)布一條事件各取所需重構(gòu)后的支付回調(diào)只有三件事支付服務(wù)處理真實支付、更新本地訂單狀態(tài)、發(fā)布訂單支付成功事件。后面所有動作都變成獨立的監(jiān)聽器分別監(jiān)聽訂單支付事件。下面是簡化后的監(jiān)聽器規(guī)劃監(jiān)聽器職責(zé)優(yōu)先級是否異步庫存監(jiān)聽器扣減真實庫存10否積分監(jiān)聽器增加用戶積分20否訂單日志監(jiān)聽器寫訂單操作日志30否通知監(jiān)聽器發(fā)送 App 推送40是問卷監(jiān)聽器發(fā)送問卷邀請50是扣庫存、加積分這些和資金資產(chǎn)相關(guān)的動作保持同步因為它們需要強(qiáng)一致性發(fā)推送、發(fā)問卷這些及時性要求不高的動作改成異步。這樣主接口的響應(yīng)時間立刻降下來而且后續(xù)增加一個新動作只需要新增監(jiān)聽器支付回調(diào)一行不用改。6.3 重構(gòu)過程中的三個經(jīng)驗細(xì)節(jié)第一事件字段不要塞太多。最初我把整個 Order 對象放進(jìn)事件后來發(fā)現(xiàn)監(jiān)聽器多了某些字段被偷偷修改定位起來非常麻煩。改成只放訂單號、用戶 ID、金額這幾個關(guān)鍵字段后數(shù)據(jù)一致性問題大幅減少。第二監(jiān)聽器之間嚴(yán)禁直接調(diào)用。我曾看到有同事在通知監(jiān)聽器里直接調(diào)用庫存監(jiān)聽器的某個公共方法理由是“復(fù)用扣減邏輯”。這等于變相把監(jiān)聽器串成了鏈路事件的解耦優(yōu)勢全沒了。正確做法是把公共邏輯抽到 Service 層監(jiān)聽器只做業(yè)務(wù)流程編排。第三一定要給事件加發(fā)生時間字段。之前在事件里沒加支付時間調(diào)試一個歷史訂單時根本無法判斷監(jiān)聽器執(zhí)行時點。后來統(tǒng)一在事件基類里加上 occurredAt用框架的時鐘填充排查問題方便多了。這個字段也可以用來做鏈路耗時統(tǒng)計一舉兩得。7. 一些值得堅持的實操習(xí)慣7.1 給事件和監(jiān)聽器建立統(tǒng)一規(guī)范我在團(tuán)隊里定過三條約定事件類統(tǒng)一放在 events 包下命名以 Event 結(jié)尾用過去時監(jiān)聽器統(tǒng)一放在 listeners 包下一個監(jiān)聽器類只處理同領(lǐng)域的事件監(jiān)聽器方法命名用動詞開頭能一眼看出動作含義。這個看似簡單的約定讓跨模塊協(xié)作的溝通成本下降了很多。代碼結(jié)構(gòu)上我習(xí)慣把同一個領(lǐng)域的事件、監(jiān)聽器、發(fā)布入口放在同一個模塊里。比如訂單模塊內(nèi)部有一個 events 子包包含訂單領(lǐng)域的所有事件和監(jiān)聽器。這樣后來的人接手時不需要在整個項目里到處找事件定義直接翻訂單模塊就能看全。7.2 冪等設(shè)計要提前做事件監(jiān)聽是異步分散的天然會面臨“同一個事件被處理兩次”的可能。哪怕你現(xiàn)在用的場景沒有重試也要在監(jiān)聽器入口做冪等判斷。最常見的做法是維護(hù)一張消費記錄表以事件唯一 ID 作為去重鍵。這個放到重構(gòu)后再補(bǔ)會非常痛苦所以建議項目一開始就帶上。冪等不僅是為了防消息中間件重投本地事件也可能因事務(wù)重試、手動補(bǔ)償、定時任務(wù)兜底而重復(fù)觸發(fā)。我在實際項目中因為沒做冪等出現(xiàn)過用戶被發(fā)放兩次優(yōu)惠券的事故。從那以后所有涉及資金、權(quán)益、庫存的監(jiān)聽器一律先查消費記錄再執(zhí)行。7.3 監(jiān)控和日志別等出問題再補(bǔ)事件鏈路比普通方法調(diào)用難追蹤得多。我踩過多次“用戶說沒收到通知但不知道是事件沒發(fā)、還是監(jiān)聽器沒執(zhí)行、還是執(zhí)行失敗”的坑。后來我在事件基類里加了 eventId在發(fā)布和每個監(jiān)聽器執(zhí)行時打印結(jié)構(gòu)化日志再配合一個簡單的指標(biāo)統(tǒng)計事件發(fā)布數(shù)和監(jiān)聽器執(zhí)行結(jié)果問題定位時間從小時級降到了分鐘級。日志格式我用的是一行 JSON包含 eventId、eventType、listenerClass、method、costMs、result 這幾個字段。排查問題時直接按 eventId 過濾日志能看到一個事件從發(fā)布到所有監(jiān)聽器處理完的完整鏈路。這個習(xí)慣在線上排查時幫了大忙強(qiáng)烈建議從項目初期就建立。最后分享一點我個人的體會。事件監(jiān)聽這套機(jī)制真正難的不是 API 怎么調(diào)而是設(shè)計者有沒有克制力。你能很容易地把所有邏輯都塞進(jìn)事件和監(jiān)聽器讓代碼看起來解耦實際卻把復(fù)雜度轉(zhuǎn)移到了事件鏈路上。我在實際使用中最受益的一條原則是如果你說不清楚某個動作為什么是事件驅(qū)動而不是直接調(diào)用那它大概率就不應(yīng)該寫成事件。只有那些真正“發(fā)生在某個事實之后、且和主流程不強(qiáng)耦合”的動作才值得放進(jìn)監(jiān)聽器。這個判斷標(biāo)準(zhǔn)聽起來很虛但它幫我擋住了很多過度設(shè)計。