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