企業(yè)系統(tǒng)里的消息通知很容易從“提醒用戶及時處理”變成“到處彈、到處發(fā)、沒人看”。站內(nèi)信、郵件、短信、企業(yè)微信、釘釘、App 推送都能發(fā)但真正難的是什么事件值得通知通知誰用哪個渠道失敗要不要重試用戶能不能退訂業(yè)務(wù)動作是否會被通知失敗拖垮。通知系統(tǒng)不是把消息發(fā)出去這么簡單。它連接業(yè)務(wù)事件、用戶偏好、渠道能力、成本控制和審計追蹤。設(shè)計得好通知能幫用戶減少遺漏設(shè)計得差通知會變成新的噪音和投訴來源。本文用一個常見場景做示例維修工單關(guān)閉后需要通知申請人和資產(chǎn)管理員。申請人只需要站內(nèi)信和郵件資產(chǎn)管理員需要站內(nèi)信如果郵件失敗不應(yīng)該影響工單關(guān)閉如果同一工單被重復(fù)關(guān)閉請求觸發(fā)也不能反復(fù)轟炸用戶。這個例子不局限于維修工單。審批待辦、合同到期、庫存預(yù)警、付款成功、導(dǎo)入失敗、客戶跟進超時都可以用同一套通知設(shè)計方法。差別只是事件類型、接收人規(guī)則、渠道優(yōu)先級和頻控策略不同。示例環(huán)境Java 17、Spring Boot 風(fēng)格服務(wù)層、MySQL 8.x。本文會給出表結(jié)構(gòu)、輕量代碼骨架、測試思路和 SQL 驗證但重點放在通知策略本身不會把篇幅主要花在代碼堆疊上。目錄通知系統(tǒng)先回答六個問題輸入案例維修工單關(guān)閉通知渠道選擇站內(nèi)信、郵件和短信各管什么MySQL表結(jié)構(gòu)事件、收件人和發(fā)送記錄實現(xiàn)骨架業(yè)務(wù)寫outbox發(fā)送異步執(zhí)行測試重點少測發(fā)送SDK多測策略邊界SQL驗證上線后查通知有沒有亂發(fā)異常邊界和上線驗收小結(jié)和延伸閱讀一、通知系統(tǒng)先回答六個問題設(shè)計通知之前先不要急著接短信平臺或郵件服務(wù)器。更重要的是回答六個問題。問題設(shè)計含義沒想清楚的后果什么事件要通知只選用戶需要及時知道的業(yè)務(wù)變化系統(tǒng)到處發(fā)消息用戶屏蔽所有通知通知誰根據(jù)業(yè)務(wù)關(guān)系和角色計算接收人漏發(fā)關(guān)鍵人或把內(nèi)部信息發(fā)給無關(guān)人用什么渠道站內(nèi)信、郵件、短信各有邊界低價值消息走高成本渠道什么時候發(fā)實時、延遲、匯總、工作時間發(fā)送半夜短信擾民或提醒太晚失效失敗怎么辦重試、降級、人工查看通知失敗拖垮主業(yè)務(wù)或失敗無人發(fā)現(xiàn)能否退訂和頻控尊重用戶偏好和成本限制同一事件反復(fù)提醒用戶反感這六個問題比代碼更重要。很多系統(tǒng)通知混亂不是因為發(fā)送接口難寫而是因為事件和渠道沒有邊界。比如“審批待辦”可能要實時站內(nèi)信“合同明天到期”可以每天早上匯總郵件“驗證碼”才適合短信。圖1通知設(shè)計要先明確事件、收件人、渠道、時機、失敗處理和頻控。二、輸入案例維修工單關(guān)閉通知本文固定一組輸入后面的數(shù)據(jù)模型、代碼骨架和 SQL 驗證都圍繞它展開。業(yè)務(wù)對象維修工單 WO-20260924-001 事件類型WORK_ORDER_CLOSED 事件標題維修工單已關(guān)閉 觸發(fā)動作維修人員確認處理完成工單狀態(tài)從 PROCESSING 變?yōu)?CLOSED 申請人user_id 1008 資產(chǎn)管理員user_id 2001 通知策略 申請人站內(nèi)信 郵件 資產(chǎn)管理員站內(nèi)信 短信不發(fā)送 冪等鍵WORK_ORDER_CLOSED:WO-20260924-001 失敗策略郵件失敗最多重試3次不影響工單關(guān)閉 頻控策略同一工單關(guān)閉事件只通知一次這個案例里有幾個關(guān)鍵點。第一通知來自業(yè)務(wù)事件而不是頁面按鈕。工單真正關(guān)閉后才寫通知事件如果關(guān)閉失敗不應(yīng)該提前通知。第二接收人來自業(yè)務(wù)關(guān)系。申請人關(guān)心處理結(jié)果資產(chǎn)管理員關(guān)心臺賬狀態(tài)其他人沒有必要收到。第三不同渠道承擔(dān)不同作用。站內(nèi)信作為系統(tǒng)內(nèi)留痕郵件作為離線提醒短信成本高且打擾強本案例不需要使用。第四通知失敗不應(yīng)該讓業(yè)務(wù)回滾。工單關(guān)閉是主業(yè)務(wù)郵件只是提醒。正確做法是業(yè)務(wù)事務(wù)里寫 outbox發(fā)送動作異步執(zhí)行。三、渠道選擇站內(nèi)信、郵件和短信各管什么通知渠道不是越多越好。一個事件同時發(fā)站內(nèi)信、郵件、短信、企業(yè)微信看起來很重視實際可能是在消耗用戶耐心。站內(nèi)信適合做系統(tǒng)內(nèi)留痕。它成本低、可查詢、可標記已讀適合待辦、處理結(jié)果、導(dǎo)入完成、審批結(jié)果等大多數(shù)業(yè)務(wù)通知。缺點是用戶不登錄系統(tǒng)就看不到。郵件適合做離線提醒和正式通知。它適合日報、周報、到期提醒、處理結(jié)果、外部協(xié)作信息。缺點是到達不穩(wěn)定容易進垃圾箱不適合做強實時保證。短信適合做高優(yōu)先級、短內(nèi)容、強觸達場景例如驗證碼、緊急告警、重要審批超時。短信有成本也容易打擾用戶不應(yīng)該用來發(fā)送普通狀態(tài)變化。企業(yè)微信、釘釘、App 推送適合組織內(nèi)部即時提醒但也要遵守頻控和免打擾策略。不要因為接入方便就把所有站內(nèi)消息同步到即時通訊工具?？梢杂靡粋€簡單分級來控制渠道消息等級示例推薦渠道普通留痕工單關(guān)閉、導(dǎo)入完成站內(nèi)信需要離線提醒合同到期、審批待辦站內(nèi)信 郵件/企業(yè)微信緊急且高價值生產(chǎn)告警、支付異常站內(nèi)信 短信/電話匯總類每日待辦、周報郵件或站內(nèi)匯總圖2站內(nèi)信、郵件、短信和即時通訊不要承擔(dān)同一種通知任務(wù)。四、MySQL表結(jié)構(gòu)事件、收件人和發(fā)送記錄通知表不要只存“標題、內(nèi)容、是否已讀”。一個可靠通知系統(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ù)事件。它解決的是“有沒有一件事需要通知”。event_key是冪等鍵同一個工單關(guān)閉事件只能寫一次。msg_recipient表示這次事件要通知哪些人。一個事件可以有多個收件人每個收件人可以有不同渠道。msg_delivery_log表示某個收件人在某個渠道上的發(fā)送狀態(tài)。郵件失敗、短信失敗、站內(nèi)信成功要分開記錄后續(xù)才能重試和排查。圖3通知事件、收件人和渠道發(fā)送記錄拆開后才能做冪等、重試和審計。五、實現(xiàn)骨架業(yè)務(wù)寫outbox發(fā)送異步執(zhí)行通知不要在主業(yè)務(wù)事務(wù)里直接調(diào)用 SMTP、短信網(wǎng)關(guān)或第三方 API。更穩(wěn)的方式是業(yè)務(wù)成功時寫 outbox后臺 worker 掃描待發(fā)送事件發(fā)送失敗后按策略重試。業(yè)務(wù)側(cè)只做一件事在業(yè)務(wù)狀態(tài)變更成功時寫事件。Transactional(rollbackForException.class)publicvoidcloseWorkOrder(CloseCommandcommand){WorkOrderorderworkOrderRepository.lockById(command.workOrderId());if(!PROCESSING.equals(order.status())){thrownewServiceException(當前工單不能關(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)閉,你的維修工單已處理完成請查看處理結(jié)果。,command.occurredAt()));}發(fā)送側(cè)負責(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());}這兩段代碼故意保持簡短因為重點不在語法而在邊界。業(yè)務(wù)事務(wù)只保證“事件被記錄”。它不保證郵件一定已經(jīng)發(fā)出。發(fā)送 worker 可以失敗可以重試可以暫停也可以切換供應(yīng)商。它不應(yīng)該反向影響工單是否關(guān)閉。接收人和渠道不寫死在業(yè)務(wù)代碼里。真實系統(tǒng)可以從通知策略表、角色關(guān)系、用戶偏好和業(yè)務(wù)對象關(guān)系里計算。圖4業(yè)務(wù)事務(wù)寫通知事件發(fā)送 worker 按策略異步處理渠道。六、測試重點少測發(fā)送SDK多測策略邊界通知測試不要把主要精力放在第三方 SDK 是否真的能發(fā)郵件。SDK 的聯(lián)通性可以用集成環(huán)境驗證日常單元測試更應(yīng)該覆蓋策略邊界。建議至少覆蓋這些測試1. 工單關(guān)閉成功后只寫入一條 WORK_ORDER_CLOSED 事件。 2. 同一 event_key 重復(fù)寫入時不產(chǎn)生重復(fù)事件。 3. 申請人生成站內(nèi)信和郵件資產(chǎn)管理員只生成站內(nèi)信。 4. 用戶退訂郵件后郵件發(fā)送記錄標記為 USER_MUTED。 5. 頻控命中后發(fā)送記錄標記為 RATE_LIMITED。 6. 郵件發(fā)送失敗后retry_count 增加next_retry_time 后移。 7. 郵件失敗不影響工單狀態(tài) CLOSED。如果要寫成 JUnit可以聚焦一兩個核心測試而不是把所有發(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));}這類測試比“調(diào)用郵件SDK返回 true”更有價值。因為通知系統(tǒng)真正容易出錯的地方是重復(fù)、誤發(fā)、漏發(fā)、退訂不生效、失敗重試失控。七、SQL驗證上線后查通知有沒有亂發(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而是要能看趨勢。如果郵件失敗突然升高要排查 SMTP、模板參數(shù)、收件地址質(zhì)量或供應(yīng)商限制。檢查是否有無限重試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;這條要人工判斷。如果大量普通工單、普通審批都走短信就說明渠道策略失控了。圖5通知驗收要檢查重復(fù)事件、失敗率、重試次數(shù)和高成本渠道使用情況。八、異常邊界和上線驗收通知系統(tǒng)要提前講清楚這些邊界。業(yè)務(wù)成功但通知失敗主業(yè)務(wù)不應(yīng)該被通知失敗回滾。應(yīng)該記錄失敗狀態(tài)進入重試或人工處理列表。通知成功但用戶沒看到系統(tǒng)只能證明消息已發(fā)送、已投遞或已讀不能保證用戶真的理解了內(nèi)容。關(guān)鍵任務(wù)不能只靠通知還要有待辦列表。重復(fù)事件同一個業(yè)務(wù)事件必須有穩(wěn)定冪等鍵。沒有冪等鍵重復(fù)提交和重試會造成重復(fù)通知。用戶退訂非強制消息要尊重用戶偏好。強制消息也要有明確范圍比如安全告警、審批待辦、合規(guī)通知。渠道降級郵件失敗是否改發(fā)站內(nèi)信短信失敗是否改發(fā)郵件要按事件等級決定。不要所有失敗都自動升級到短信。模板參數(shù)缺失模板參數(shù)缺失應(yīng)當在發(fā)送前校驗。不能讓用戶收到“{workOrderNo} 已關(guān)閉”這種半成品消息。上線驗收可以按下面清單執(zhí)行每類業(yè)務(wù)事件都有明確通知策略。普通通知、重要通知、緊急通知的渠道不同。同一事件有穩(wěn)定event_key重復(fù)觸發(fā)不會重復(fù)發(fā)送。業(yè)務(wù)事務(wù)只寫 outbox不直接調(diào)用外部發(fā)送服務(wù)。站內(nèi)信、郵件、短信的發(fā)送記錄分開保存。用戶偏好和退訂規(guī)則能生效。頻控能阻止短時間重復(fù)提醒。失敗重試有次數(shù)上限和下次重試時間。模板參數(shù)缺失會阻止發(fā)送并記錄錯誤。SQL 能查出重復(fù)事件、失敗率、無限重試和短信濫用。九、小結(jié)和延伸閱讀消息通知的目標不是“能發(fā)出去”而是“在合適的時間用合適的渠道把合適的信息發(fā)給合適的人”。這句話聽起來像原則但落到系統(tǒng)里就是事件模型、收件人規(guī)則、渠道策略、outbox、冪等、退訂、頻控和發(fā)送日志。如果系統(tǒng)還很小可以先做站內(nèi)信和 outbox等通知量上來再擴展郵件、短信和即時通訊。不要一開始把所有渠道都接上也不要讓外部渠道失敗影響主業(yè)務(wù)。把通知邊界打穩(wěn)后續(xù)再做模板管理、消息中心和運營統(tǒng)計會順很多。延伸閱讀MicrosoftTransactional Outbox patternSpring Framework聲明式事務(wù)管理MySQL 8.4CREATE TABLE