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