企業(yè)系統(tǒng)里的消息通知很容易從“提醒用戶及時(shí)處理”變成“到處彈、到處發(fā)、沒(méi)人看”。站內(nèi)信、郵件、短信、企業(yè)微信、釘釘、App 推送都能發(fā)但真正難的是什么事件值得通知通知誰(shuí)用哪個(gè)渠道失敗要不要重試用戶能不能退訂業(yè)務(wù)動(dòng)作是否會(huì)被通知失敗拖垮。通知系統(tǒng)不是把消息發(fā)出去這么簡(jiǎn)單。它連接業(yè)務(wù)事件、用戶偏好、渠道能力、成本控制和審計(jì)追蹤。設(shè)計(jì)得好通知能幫用戶減少遺漏設(shè)計(jì)得差通知會(huì)變成新的噪音和投訴來(lái)源。本文用一個(gè)常見場(chǎng)景做示例維修工單關(guān)閉后需要通知申請(qǐng)人和資產(chǎn)管理員。申請(qǐng)人只需要站內(nèi)信和郵件資產(chǎn)管理員需要站內(nèi)信如果郵件失敗不應(yīng)該影響工單關(guān)閉如果同一工單被重復(fù)關(guān)閉請(qǐng)求觸發(fā)也不能反復(fù)轟炸用戶。這個(gè)例子不局限于維修工單。審批待辦、合同到期、庫(kù)存預(yù)警、付款成功、導(dǎo)入失敗、客戶跟進(jìn)超時(shí)都可以用同一套通知設(shè)計(jì)方法。差別只是事件類型、接收人規(guī)則、渠道優(yōu)先級(jí)和頻控策略不同。示例環(huán)境Java 17、Spring Boot 風(fēng)格服務(wù)層、MySQL 8.x。本文會(huì)給出表結(jié)構(gòu)、輕量代碼骨架、測(cè)試思路和 SQL 驗(yàn)證但重點(diǎn)放在通知策略本身不會(huì)把篇幅主要花在代碼堆疊上。目錄通知系統(tǒng)先回答六個(gè)問(wèn)題輸入案例維修工單關(guān)閉通知渠道選擇站內(nèi)信、郵件和短信各管什么MySQL表結(jié)構(gòu)事件、收件人和發(fā)送記錄實(shí)現(xiàn)骨架業(yè)務(wù)寫outbox發(fā)送異步執(zhí)行測(cè)試重點(diǎn)少測(cè)發(fā)送SDK多測(cè)策略邊界SQL驗(yàn)證上線后查通知有沒(méi)有亂發(fā)異常邊界和上線驗(yàn)收小結(jié)和延伸閱讀一、通知系統(tǒng)先回答六個(gè)問(wèn)題設(shè)計(jì)通知之前先不要急著接短信平臺(tái)或郵件服務(wù)器。更重要的是回答六個(gè)問(wèn)題。問(wèn)題設(shè)計(jì)含義沒(méi)想清楚的后果什么事件要通知只選用戶需要及時(shí)知道的業(yè)務(wù)變化系統(tǒng)到處發(fā)消息用戶屏蔽所有通知通知誰(shuí)根據(jù)業(yè)務(wù)關(guān)系和角色計(jì)算接收人漏發(fā)關(guān)鍵人或把內(nèi)部信息發(fā)給無(wú)關(guān)人用什么渠道站內(nèi)信、郵件、短信各有邊界低價(jià)值消息走高成本渠道什么時(shí)候發(fā)實(shí)時(shí)、延遲、匯總、工作時(shí)間發(fā)送半夜短信擾民或提醒太晚失效失敗怎么辦重試、降級(jí)、人工查看通知失敗拖垮主業(yè)務(wù)或失敗無(wú)人發(fā)現(xiàn)能否退訂和頻控尊重用戶偏好和成本限制同一事件反復(fù)提醒用戶反感這六個(gè)問(wèn)題比代碼更重要。很多系統(tǒng)通知混亂不是因?yàn)榘l(fā)送接口難寫而是因?yàn)槭录颓罌](méi)有邊界。比如“審批待辦”可能要實(shí)時(shí)站內(nèi)信“合同明天到期”可以每天早上匯總郵件“驗(yàn)證碼”才適合短信。圖1通知設(shè)計(jì)要先明確事件、收件人、渠道、時(shí)機(jī)、失敗處理和頻控。二、輸入案例維修工單關(guān)閉通知本文固定一組輸入后面的數(shù)據(jù)模型、代碼骨架和 SQL 驗(yàn)證都圍繞它展開。業(yè)務(wù)對(duì)象維修工單 WO-20260924-001 事件類型WORK_ORDER_CLOSED 事件標(biāo)題維修工單已關(guān)閉 觸發(fā)動(dòng)作維修人員確認(rèn)處理完成工單狀態(tài)從 PROCESSING 變?yōu)?CLOSED 申請(qǐng)人user_id 1008 資產(chǎn)管理員user_id 2001 通知策略 申請(qǐng)人站內(nèi)信 郵件 資產(chǎn)管理員站內(nèi)信 短信不發(fā)送 冪等鍵WORK_ORDER_CLOSED:WO-20260924-001 失敗策略郵件失敗最多重試3次不影響工單關(guān)閉 頻控策略同一工單關(guān)閉事件只通知一次這個(gè)案例里有幾個(gè)關(guān)鍵點(diǎn)。第一通知來(lái)自業(yè)務(wù)事件而不是頁(yè)面按鈕。工單真正關(guān)閉后才寫通知事件如果關(guān)閉失敗不應(yīng)該提前通知。第二接收人來(lái)自業(yè)務(wù)關(guān)系。申請(qǐng)人關(guān)心處理結(jié)果資產(chǎn)管理員關(guān)心臺(tái)賬狀態(tài)其他人沒(méi)有必要收到。第三不同渠道承擔(dān)不同作用。站內(nèi)信作為系統(tǒng)內(nèi)留痕郵件作為離線提醒短信成本高且打擾強(qiáng)本案例不需要使用。第四通知失敗不應(yīng)該讓業(yè)務(wù)回滾。工單關(guān)閉是主業(yè)務(wù)郵件只是提醒。正確做法是業(yè)務(wù)事務(wù)里寫 outbox發(fā)送動(dòng)作異步執(zhí)行。三、渠道選擇站內(nèi)信、郵件和短信各管什么通知渠道不是越多越好。一個(gè)事件同時(shí)發(fā)站內(nèi)信、郵件、短信、企業(yè)微信看起來(lái)很重視實(shí)際可能是在消耗用戶耐心。站內(nèi)信適合做系統(tǒng)內(nèi)留痕。它成本低、可查詢、可標(biāo)記已讀適合待辦、處理結(jié)果、導(dǎo)入完成、審批結(jié)果等大多數(shù)業(yè)務(wù)通知。缺點(diǎn)是用戶不登錄系統(tǒng)就看不到。郵件適合做離線提醒和正式通知。它適合日?qǐng)?bào)、周報(bào)、到期提醒、處理結(jié)果、外部協(xié)作信息。缺點(diǎn)是到達(dá)不穩(wěn)定容易進(jìn)垃圾箱不適合做強(qiáng)實(shí)時(shí)保證。短信適合做高優(yōu)先級(jí)、短內(nèi)容、強(qiáng)觸達(dá)場(chǎng)景例如驗(yàn)證碼、緊急告警、重要審批超時(shí)。短信有成本也容易打擾用戶不應(yīng)該用來(lái)發(fā)送普通狀態(tài)變化。企業(yè)微信、釘釘、App 推送適合組織內(nèi)部即時(shí)提醒但也要遵守頻控和免打擾策略。不要因?yàn)榻尤敕奖憔桶阉姓緝?nèi)消息同步到即時(shí)通訊工具。可以用一個(gè)簡(jiǎn)單分級(jí)來(lái)控制渠道消息等級(jí)示例推薦渠道普通留痕工單關(guān)閉、導(dǎo)入完成站內(nèi)信需要離線提醒合同到期、審批待辦站內(nèi)信 郵件/企業(yè)微信緊急且高價(jià)值生產(chǎn)告警、支付異常站內(nèi)信 短信/電話匯總類每日待辦、周報(bào)郵件或站內(nèi)匯總圖2站內(nèi)信、郵件、短信和即時(shí)通訊不要承擔(dān)同一種通知任務(wù)。四、MySQL表結(jié)構(gòu)事件、收件人和發(fā)送記錄通知表不要只存“標(biāo)題、內(nèi)容、是否已讀”。一個(gè)可靠通知系統(tǒng)至少要區(qū)分事件、收件人、渠道發(fā)送記錄。CREATETABLEmsg_event_outbox(idBIGINTPRIMARYKEYAUTO_INCREMENT,company_idBIGINTNOTNULL,event_typeVARCHAR(80)NOTNULL,biz_typeVARCHAR(64)NOTNULL,biz_idBIGINTNOTNULL,biz_noVARCHAR(64)NOTNULL,event_keyVARCHAR(120)NOTNULL,titleVARCHAR(200)NOTNULL,contentTEXTNOTNULL,payload_json JSONNULL,statusVARCHAR(32)NOTNULL,next_retry_timeDATETIMENULL,retry_countINTNOTNULLDEFAULT0,create_timeDATETIMENOTNULL,update_timeDATETIMENULL,UNIQUEKEYuk_msg_event_key(event_key),KEYidx_msg_event_status(status,next_retry_time));CREATETABLEmsg_recipient(idBIGINTPRIMARYKEYAUTO_INCREMENT,event_idBIGINTNOTNULL,user_idBIGINTNOTNULL,recipient_roleVARCHAR(64)NOTNULL,channelsVARCHAR(100)NOTNULL,read_timeDATETIMENULL,create_timeDATETIMENOTNULL,UNIQUEKEYuk_msg_recipient(event_id,user_id),KEYidx_msg_user_unread(user_id,read_time));CREATETABLEmsg_delivery_log(idBIGINTPRIMARYKEYAUTO_INCREMENT,event_idBIGINTNOTNULL,recipient_idBIGINTNOTNULL,user_idBIGINTNOTNULL,channelVARCHAR(32)NOTNULL,statusVARCHAR(32)NOTNULL,provider_msg_idVARCHAR(120)NULL,error_codeVARCHAR(80)NULL,error_messageVARCHAR(500)NULL,send_timeDATETIMENULL,create_timeDATETIMENOTNULL,update_timeDATETIMENULL,UNIQUEKEYuk_msg_delivery_once(event_id,user_id,channel),KEYidx_msg_delivery_status(status,create_time));這三張表分工不同。msg_event_outbox表示一次業(yè)務(wù)事件。它解決的是“有沒(méi)有一件事需要通知”。event_key是冪等鍵同一個(gè)工單關(guān)閉事件只能寫一次。msg_recipient表示這次事件要通知哪些人。一個(gè)事件可以有多個(gè)收件人每個(gè)收件人可以有不同渠道。msg_delivery_log表示某個(gè)收件人在某個(gè)渠道上的發(fā)送狀態(tài)。郵件失敗、短信失敗、站內(nèi)信成功要分開記錄后續(xù)才能重試和排查。圖3通知事件、收件人和渠道發(fā)送記錄拆開后才能做冪等、重試和審計(jì)。五、實(shí)現(xiàn)骨架業(yè)務(wù)寫outbox發(fā)送異步執(zhí)行通知不要在主業(yè)務(wù)事務(wù)里直接調(diào)用 SMTP、短信網(wǎng)關(guān)或第三方 API。更穩(wěn)的方式是業(yè)務(wù)成功時(shí)寫 outbox后臺(tái) worker 掃描待發(fā)送事件發(fā)送失敗后按策略重試。業(yè)務(wù)側(cè)只做一件事在業(yè)務(wù)狀態(tài)變更成功時(shí)寫事件。Transactional(rollbackForException.class)publicvoidcloseWorkOrder(CloseCommandcommand){WorkOrderorderworkOrderRepository.lockById(command.workOrderId());if(!PROCESSING.equals(order.status())){thrownewServiceException(當(dāng)前工單不能關(guān)閉order.status());}workOrderRepository.close(order.id(),command.operatorId(),command.occurredAt());notificationOutboxRepository.insertIgnore(newNotificationEvent(order.companyId(),WORK_ORDER_CLOSED,WORK_ORDER,order.id(),order.workOrderNo(),WORK_ORDER_CLOSED:order.workOrderNo(),維修工單已關(guān)閉,你的維修工單已處理完成請(qǐng)查看處理結(jié)果。,command.occurredAt()));}發(fā)送側(cè)負(fù)責(zé)策略算收件人、算渠道、生成發(fā)送記錄、調(diào)用具體渠道。publicvoiddispatchOneEvent(LongeventId){NotificationEventeventoutboxRepository.lockPending(eventId);ListRecipientPlanrecipientsrecipientResolver.resolve(event);for(RecipientPlanrecipient:recipients){for(Stringchannel:recipient.channels()){if(preferenceService.isMuted(recipient.userId(),event.eventType(),channel)){deliveryLogRepository.skip(event.id(),recipient.userId(),channel,USER_MUTED);continue;}if(rateLimitService.exceeded(recipient.userId(),event.eventType(),channel)){deliveryLogRepository.skip(event.id(),recipient.userId(),channel,RATE_LIMITED);continue;}deliverySender.send(event,recipient,channel);}}outboxRepository.markDispatched(event.id());}這兩段代碼故意保持簡(jiǎn)短因?yàn)橹攸c(diǎn)不在語(yǔ)法而在邊界。業(yè)務(wù)事務(wù)只保證“事件被記錄”。它不保證郵件一定已經(jīng)發(fā)出。發(fā)送 worker 可以失敗可以重試可以暫停也可以切換供應(yīng)商。它不應(yīng)該反向影響工單是否關(guān)閉。接收人和渠道不寫死在業(yè)務(wù)代碼里。真實(shí)系統(tǒng)可以從通知策略表、角色關(guān)系、用戶偏好和業(yè)務(wù)對(duì)象關(guān)系里計(jì)算。圖4業(yè)務(wù)事務(wù)寫通知事件發(fā)送 worker 按策略異步處理渠道。六、測(cè)試重點(diǎn)少測(cè)發(fā)送SDK多測(cè)策略邊界通知測(cè)試不要把主要精力放在第三方 SDK 是否真的能發(fā)郵件。SDK 的聯(lián)通性可以用集成環(huán)境驗(yàn)證日常單元測(cè)試更應(yīng)該覆蓋策略邊界。建議至少覆蓋這些測(cè)試1. 工單關(guān)閉成功后只寫入一條 WORK_ORDER_CLOSED 事件。 2. 同一 event_key 重復(fù)寫入時(shí)不產(chǎn)生重復(fù)事件。 3. 申請(qǐng)人生成站內(nèi)信和郵件資產(chǎn)管理員只生成站內(nèi)信。 4. 用戶退訂郵件后郵件發(fā)送記錄標(biāo)記為 USER_MUTED。 5. 頻控命中后發(fā)送記錄標(biāo)記為 RATE_LIMITED。 6. 郵件發(fā)送失敗后retry_count 增加next_retry_time 后移。 7. 郵件失敗不影響工單狀態(tài) CLOSED。如果要寫成 JUnit可以聚焦一兩個(gè)核心測(cè)試而不是把所有發(fā)送渠道都 mock 一遍。TestvoidshouldWriteOnlyOneEventWhenWorkOrderClosedTwice(){FixturefxFixture.processingWorkOrder(WO-20260924-001);fx.workOrderService().closeWorkOrder(fx.closeCommand());fx.workOrderService().closeWorkOrder(fx.sameRequestCommand());assertEquals(CLOSED,fx.workOrderRepository().status());assertEquals(1,fx.outboxRepository().countByEventKey(WORK_ORDER_CLOSED:WO-20260924-001));}TestvoidshouldSkipEmailWhenUserMutedThisEventType(){FixturefxFixture.event(WORK_ORDER_CLOSED);fx.preferenceService().mute(1008L,WORK_ORDER_CLOSED,EMAIL);fx.dispatcher().dispatchOneEvent(fx.eventId());assertEquals(SKIPPED,fx.deliveryLog().status(1008L,EMAIL));assertEquals(USER_MUTED,fx.deliveryLog().errorCode(1008L,EMAIL));assertEquals(SENT,fx.deliveryLog().status(1008L,INBOX));}這類測(cè)試比“調(diào)用郵件SDK返回 true”更有價(jià)值。因?yàn)橥ㄖ到y(tǒng)真正容易出錯(cuò)的地方是重復(fù)、誤發(fā)、漏發(fā)、退訂不生效、失敗重試失控。七、SQL驗(yàn)證上線后查通知有沒(méi)有亂發(fā)通知上線后要能用 SQL 看清楚是否亂發(fā)、漏發(fā)和重試異常。檢查同一事件是否重復(fù)SELECTevent_key,COUNT(*)AScntFROMmsg_event_outboxGROUPBYevent_keyHAVINGCOUNT(*)1;預(yù)期結(jié)果empty set檢查郵件失敗率SELECTchannel,status,COUNT(*)AScntFROMmsg_delivery_logWHEREcreate_timeDATE_SUB(NOW(),INTERVAL1DAY)GROUPBYchannel,status;這條不是要求失敗為 0而是要能看趨勢(shì)。如果郵件失敗突然升高要排查 SMTP、模板參數(shù)、收件地址質(zhì)量或供應(yīng)商限制。檢查是否有無(wú)限重試SELECTid,event_type,biz_no,retry_count,next_retry_timeFROMmsg_event_outboxWHEREretry_count3ANDstatusIN(PENDING,RETRY);預(yù)期結(jié)果empty set檢查短信是否被普通事件濫用SELECTe.event_type,COUNT(*)ASsms_countFROMmsg_delivery_log dJOINmsg_event_outbox eONe.idd.event_idWHEREd.channelSMSANDd.create_timeDATE_SUB(NOW(),INTERVAL7DAY)GROUPBYe.event_typeORDERBYsms_countDESC;這條要人工判斷。如果大量普通工單、普通審批都走短信就說(shuō)明渠道策略失控了。圖5通知驗(yàn)收要檢查重復(fù)事件、失敗率、重試次數(shù)和高成本渠道使用情況。八、異常邊界和上線驗(yàn)收通知系統(tǒng)要提前講清楚這些邊界。業(yè)務(wù)成功但通知失敗主業(yè)務(wù)不應(yīng)該被通知失敗回滾。應(yīng)該記錄失敗狀態(tài)進(jìn)入重試或人工處理列表。通知成功但用戶沒(méi)看到系統(tǒng)只能證明消息已發(fā)送、已投遞或已讀不能保證用戶真的理解了內(nèi)容。關(guān)鍵任務(wù)不能只靠通知還要有待辦列表。重復(fù)事件同一個(gè)業(yè)務(wù)事件必須有穩(wěn)定冪等鍵。沒(méi)有冪等鍵重復(fù)提交和重試會(huì)造成重復(fù)通知。用戶退訂非強(qiáng)制消息要尊重用戶偏好。強(qiáng)制消息也要有明確范圍比如安全告警、審批待辦、合規(guī)通知。渠道降級(jí)郵件失敗是否改發(fā)站內(nèi)信短信失敗是否改發(fā)郵件要按事件等級(jí)決定。不要所有失敗都自動(dòng)升級(jí)到短信。模板參數(shù)缺失模板參數(shù)缺失應(yīng)當(dāng)在發(fā)送前校驗(yàn)。不能讓用戶收到“{workOrderNo} 已關(guān)閉”這種半成品消息。上線驗(yàn)收可以按下面清單執(zhí)行每類業(yè)務(wù)事件都有明確通知策略。普通通知、重要通知、緊急通知的渠道不同。同一事件有穩(wěn)定event_key重復(fù)觸發(fā)不會(huì)重復(fù)發(fā)送。業(yè)務(wù)事務(wù)只寫 outbox不直接調(diào)用外部發(fā)送服務(wù)。站內(nèi)信、郵件、短信的發(fā)送記錄分開保存。用戶偏好和退訂規(guī)則能生效。頻控能阻止短時(shí)間重復(fù)提醒。失敗重試有次數(shù)上限和下次重試時(shí)間。模板參數(shù)缺失會(huì)阻止發(fā)送并記錄錯(cuò)誤。SQL 能查出重復(fù)事件、失敗率、無(wú)限重試和短信濫用。九、小結(jié)和延伸閱讀消息通知的目標(biāo)不是“能發(fā)出去”而是“在合適的時(shí)間用合適的渠道把合適的信息發(fā)給合適的人”。這句話聽起來(lái)像原則但落到系統(tǒng)里就是事件模型、收件人規(guī)則、渠道策略、outbox、冪等、退訂、頻控和發(fā)送日志。如果系統(tǒng)還很小可以先做站內(nèi)信和 outbox等通知量上來(lái)再擴(kuò)展郵件、短信和即時(shí)通訊。不要一開始把所有渠道都接上也不要讓外部渠道失敗影響主業(yè)務(wù)。把通知邊界打穩(wěn)后續(xù)再做模板管理、消息中心和運(yùn)營(yíng)統(tǒng)計(jì)會(huì)順很多。延伸閱讀MicrosoftTransactional Outbox patternSpring Framework聲明式事務(wù)管理MySQL 8.4CREATE TABLE