1. 項(xiàng)目概述與核心需求拆解1.1 什么是企業(yè)級(jí)消息通知系統(tǒng)消息通知系統(tǒng)說(shuō)白了就是解決“業(yè)務(wù)系統(tǒng)如何把一條消息可靠地送到用戶手里”這個(gè)問(wèn)題的中間層服務(wù)。你點(diǎn)外賣、收驗(yàn)證碼、接到訂單狀態(tài)變更提醒背后都是一套通知服務(wù)在干活。很多團(tuán)隊(duì)初期圖省事直接在業(yè)務(wù)代碼里寫死一個(gè)函數(shù)調(diào)短信接口或郵件服務(wù)等業(yè)務(wù)跑起來(lái)了才發(fā)現(xiàn)問(wèn)題一大堆每天幾百萬(wàn)條通知把第三方供應(yīng)商的配額打爆了、其中一個(gè)通道掛了導(dǎo)致所有通知全部丟失、產(chǎn)品臨時(shí)要新增一個(gè)釘釘機(jī)器人通知結(jié)果要改十幾個(gè)業(yè)務(wù)方代碼。我這篇文章要講的就是如何從零搭建一個(gè)能支撐企業(yè)級(jí)規(guī)模的消息通知服務(wù)核心圍繞三條主線高可用、可擴(kuò)展、可觀測(cè)。高可用解決通道故障和流量洪峰下的存活問(wèn)題可擴(kuò)展解決新通道接入和業(yè)務(wù)方接入的效率問(wèn)題可觀測(cè)解決出了問(wèn)題能快速定位的問(wèn)題。這套方案適用于電商平臺(tái)、SaaS產(chǎn)品、企業(yè)內(nèi)部協(xié)同工具的通用通知需求架構(gòu)上以Spring Boot Redis RabbitMQ為底座不做任何商業(yè)組件依賴團(tuán)隊(duì)有Java后端基礎(chǔ)就能落地。1.2 通知系統(tǒng)的業(yè)務(wù)邊界與通用場(chǎng)景企業(yè)級(jí)通知服務(wù)一般要承擔(dān)三類場(chǎng)景第一類是交易類通知比如訂單支付成功、退款到賬、物流狀態(tài)變更這類通知對(duì)可靠性要求最高漏發(fā)一條可能引發(fā)客訴甚至合規(guī)風(fēng)險(xiǎn)第二類是營(yíng)銷類通知比如優(yōu)惠券到期提醒、活動(dòng)上線推送這類通知量大、時(shí)效要求相對(duì)寬松但必須考慮用戶退訂意愿第三類是運(yùn)維類通知比如告警觸發(fā)、工單流轉(zhuǎn)這類通知通常走IM或Webhook要求分鐘級(jí)觸達(dá)。在設(shè)計(jì)系統(tǒng)時(shí)我習(xí)慣先把三類場(chǎng)景的SLA指標(biāo)定下來(lái)交易類要求全年可用性不低于99.95%單條推送到達(dá)率不低于99.99%營(yíng)銷類允許批量發(fā)送但有頻控約束運(yùn)維類要求通道故障自動(dòng)切換時(shí)間不超過(guò)30秒。很多團(tuán)隊(duì)一上來(lái)就寫代碼后面返工十有八九是因?yàn)闆](méi)有事先定義這些指標(biāo)。指標(biāo)定清楚了架構(gòu)選型才有依據(jù)。1.3 項(xiàng)目初始評(píng)估與技術(shù)選型依據(jù)在動(dòng)手編碼之前先評(píng)估一下核心依賴組件的選型。通知服務(wù)的本質(zhì)是“消息轉(zhuǎn)儲(chǔ) 路由分發(fā) 渠道適配”所以關(guān)鍵組件是消息隊(duì)列、緩存、數(shù)據(jù)庫(kù)和任務(wù)調(diào)度框架。我選型的思路是這樣的消息隊(duì)列使用RabbitMQ而不是Kafka雖然Kafka吞吐更高但通知場(chǎng)景的核心訴求是“每條消息不丟、可重試”RabbitMQ的ack機(jī)制、死信隊(duì)列、延遲隊(duì)列生態(tài)更成熟中小團(tuán)隊(duì)維護(hù)成本更低。緩存統(tǒng)一用Redis既要支撐消息去重、計(jì)數(shù)限流也要承擔(dān)頻控令牌桶的存儲(chǔ)Redis單實(shí)例性能足夠生產(chǎn)環(huán)境用哨兵模式做主從高可用。數(shù)據(jù)庫(kù)用MySQLPercona分支通知記錄表雖然寫入量大但業(yè)務(wù)簡(jiǎn)單分庫(kù)分表不需要一上來(lái)就做先按天分表即可。任務(wù)調(diào)度用XXL-Job負(fù)責(zé)掃表補(bǔ)償、定時(shí)批量發(fā)送這樣的場(chǎng)景。這套組合的特點(diǎn)就是每個(gè)組件聽(tīng)上去都沒(méi)有什么驚艷的地方但合在一起就是一套很皮實(shí)的架構(gòu)也是我在多個(gè)項(xiàng)目里驗(yàn)證過(guò)的組合。2. 整體架構(gòu)設(shè)計(jì)與關(guān)鍵決策2.1 分層架構(gòu)與數(shù)據(jù)流向整個(gè)通知系統(tǒng)我把它拆成四層接入層、處理層、發(fā)送層、管理面。接入層負(fù)責(zé)接收業(yè)務(wù)方請(qǐng)求統(tǒng)一鑒權(quán)、參數(shù)校驗(yàn)、數(shù)據(jù)脫敏處理層負(fù)責(zé)消息的模板渲染、去重、頻控、路由決策發(fā)送層負(fù)責(zé)與各個(gè)第三方通道短信、郵件、App Push等交互管理面是后臺(tái)配置包括模板管理、通道配置、重試策略配置。數(shù)據(jù)流向是這樣的業(yè)務(wù)側(cè)調(diào)用HTTP接口或者寫入MQ生產(chǎn)一條通知事件事件進(jìn)入處理層后會(huì)先做冪等去重和頻控校驗(yàn)通過(guò)后把通知任務(wù)持久化到MySQL同時(shí)投遞到RabbitMQ的待發(fā)送隊(duì)列。發(fā)送層的消費(fèi)端拿到任務(wù)按路由規(guī)則選擇通道執(zhí)行發(fā)送執(zhí)行結(jié)果回寫數(shù)據(jù)庫(kù)失敗的任務(wù)進(jìn)入重試隊(duì)列。以上每一條鏈路都埋了TraceID方便全鏈路追蹤。這里有一個(gè)很多人容易犯的錯(cuò)誤把發(fā)送動(dòng)作放在接入請(qǐng)求的同步鏈路里。用戶請(qǐng)求支付成功回調(diào)同步去調(diào)短信接口等第三方響應(yīng)結(jié)果第三方超時(shí)5秒用戶的HTTP請(qǐng)求也卡了5秒整個(gè)支付鏈路被拖垮。通知服務(wù)必須做到接入異步化同步接口只保證“接單成功”不保證“發(fā)送成功”發(fā)送動(dòng)作全發(fā)生在異步鏈路里。2.2 高可用設(shè)計(jì)的三重保險(xiǎn)高可用不能靠口號(hào)得靠具體的冗余機(jī)制。第一重保險(xiǎn)是存儲(chǔ)層高可用MySQL一主一從半同步復(fù)制Redis哨兵模式三節(jié)點(diǎn)MQ做鏡像隊(duì)列。任何一個(gè)組件宕機(jī)系統(tǒng)都有自動(dòng)切換的兜底能力不需要人工介入。第二重保險(xiǎn)是無(wú)狀態(tài)多副本所有應(yīng)用節(jié)點(diǎn)都是無(wú)狀態(tài)的可任意橫向擴(kuò)容前置負(fù)載均衡用Nginx或SLB某一個(gè)節(jié)點(diǎn)掛了流量自動(dòng)摘除。第三重保險(xiǎn)是通道層容災(zāi)短信、App Push這類渠道依賴第三方供應(yīng)商我會(huì)給每個(gè)通道配置主備兩個(gè)供應(yīng)商路由策略里加入健康檢查連續(xù)失敗N次自動(dòng)切換到備用通道。這三重保險(xiǎn)是疊buff的關(guān)系層層兜底。我踩過(guò)最大的坑是只做了應(yīng)用層高可用覺(jué)得節(jié)點(diǎn)多了就穩(wěn)了結(jié)果短信供應(yīng)商因?yàn)榍焚M(fèi)直接停了服務(wù)系統(tǒng)里幾千條通知積壓。后來(lái)才加了通道健康檢查和自動(dòng)熔斷這種情況才能自動(dòng)切換。2.3 可擴(kuò)展性設(shè)計(jì)的插件化思路可擴(kuò)展性的核心是“新通道接入不改業(yè)務(wù)流程代碼”。我的做法是定義一套統(tǒng)一的Channel接口所有通道短信、郵件、Push、Webhook、站內(nèi)信都實(shí)現(xiàn)同一套接口各自封裝各自的供應(yīng)商對(duì)接邏輯。新接一個(gè)通道就是新增一個(gè)實(shí)現(xiàn)類并注冊(cè)到Spring容器不需要?jiǎng)尤魏紊蠈舆壿?。public interface NotifyChannel { // 通道唯一編碼如 sms、email、push_ios String getChannelCode(); // 發(fā)送消息 SendResult send(NotifyMessage message); // 健康檢查 boolean healthCheck(); // 當(dāng)前通道是否支持該消息類型 boolean support(NotifyType notifyType); }接口抽象出來(lái)之后還有一個(gè)很關(guān)鍵的點(diǎn)消息模型也要統(tǒng)一。業(yè)務(wù)方不用關(guān)心用什么通道發(fā)只需要提交一個(gè)“通知事件”里面帶上業(yè)務(wù)類型、接收人、模板編號(hào)、模板參數(shù)具體走哪個(gè)通道由服務(wù)端路由決定。這樣即使未來(lái)新增一個(gè)“企業(yè)微信”通道上游業(yè)務(wù)方一行代碼都不用動(dòng)。還有一個(gè)擴(kuò)展點(diǎn)容易被忽略模板渲染。不同通道對(duì)內(nèi)容的格式要求不同短信有70字限制郵件支持HTMLPush有標(biāo)題加正文。模板需要按通道維度獨(dú)立配置渲染引擎負(fù)責(zé)把業(yè)務(wù)參數(shù)填充到不同模板里這里我選擇的是Java原生SPEL表達(dá)式模板不引入額外的模板框架保持輕量。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 消息數(shù)據(jù)模型與表結(jié)構(gòu)設(shè)計(jì)先看數(shù)據(jù)庫(kù)設(shè)計(jì)這是整個(gè)系統(tǒng)的地基。通知系統(tǒng)最核心的表是通知任務(wù)表我給它命名為notify_task。這個(gè)表有幾個(gè)關(guān)鍵字段biz_type業(yè)務(wù)類型、biz_id業(yè)務(wù)冪等ID、template_id模板編號(hào)、channel_code路由后的通道編碼、receiver接收人、params模板參數(shù)JSON、status狀態(tài)、retry_count重試次數(shù)、next_retry_time下次重試時(shí)間、trace_id鏈路追蹤ID。狀態(tài)流轉(zhuǎn)要設(shè)計(jì)得簡(jiǎn)潔清晰我用了這幾個(gè)狀態(tài)PENDING待處理、SENDING發(fā)送中、SUCCESS成功、FAILED失敗、DEAD死亡即重試耗盡。每次發(fā)送動(dòng)作只做狀態(tài)之間的原子轉(zhuǎn)換避免并發(fā)情況下?tīng)顟B(tài)錯(cuò)亂。建表時(shí)需要特別關(guān)注索引設(shè)計(jì)。實(shí)踐中查詢頻率最高的是“按狀態(tài)和下次重試時(shí)間掃補(bǔ)償任務(wù)”以及“按業(yè)務(wù)ID查重”所以至少要建這兩個(gè)組合索引idx_status_next_retry_time(status, next_retry_time)、idx_biz_type_biz_id(biz_type, biz_id)。順序別反了反了會(huì)導(dǎo)致索引失效。模板和通道配置是低頻數(shù)據(jù)單獨(dú)建立notify_template、notify_channel_config、notify_channel_route三張表業(yè)務(wù)上支持動(dòng)態(tài)修改。通道配置里要保存供應(yīng)商的AK/SK、接口地址、限流閾值等信息這些字段需要加密存儲(chǔ)項(xiàng)目里我用的是AES256加密后落庫(kù)服務(wù)啟動(dòng)時(shí)解密加載到內(nèi)存緩存。3.2 模板渲染與參數(shù)校驗(yàn)的細(xì)節(jié)處理模板渲染環(huán)節(jié)有不少細(xì)節(jié)講究。每個(gè)模板可能被多個(gè)業(yè)務(wù)方復(fù)用參數(shù)命名必須收斂規(guī)范化。我規(guī)定參數(shù)名統(tǒng)一為駝峰格式模板里通過(guò)${userName}這樣的占位符引用。渲染引擎實(shí)現(xiàn)時(shí)要注意兩點(diǎn)一是參數(shù)缺失時(shí)不要直接拋異常而是用空字符串占位并記錄一條WARN日志因?yàn)橥ㄖ皇呛诵慕灰祖溌肪植繀?shù)錯(cuò)誤不能讓整條任務(wù)失敗二是渲染結(jié)果要按通道重新校驗(yàn)長(zhǎng)度最典型的是短信超過(guò)70字要拆條拆條邏輯按字符合并而不是簡(jiǎn)單截?cái)嘁幚頁(yè)Q行和標(biāo)點(diǎn)的邊界。參數(shù)校驗(yàn)的層級(jí)要區(qū)分開(kāi)。接入層校驗(yàn)的是參數(shù)類型和必填項(xiàng)處理層校驗(yàn)的是業(yè)務(wù)規(guī)則比如同一用戶同一類型通知的頻控發(fā)送層校驗(yàn)的是通道約束比如手機(jī)號(hào)格式、郵箱格式。這個(gè)分層不做的話后面會(huì)很痛苦我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)把所有校驗(yàn)堆在接入層結(jié)果加一個(gè)“郵件通道不支持發(fā)送手機(jī)號(hào)”的規(guī)則要改接入層代碼發(fā)布上線才能生效完全放棄了動(dòng)態(tài)性。模板數(shù)據(jù)還需要支持SuperVar多語(yǔ)言或動(dòng)態(tài)配置的替換但這個(gè)視團(tuán)隊(duì)實(shí)際情況不需要過(guò)度設(shè)計(jì)。3.3 去重、頻控與防刷的實(shí)現(xiàn)策略去重和頻控是企業(yè)級(jí)通知和玩具項(xiàng)目之間最明顯的分水嶺。去重要做兩層接入層的冪等去重和發(fā)送層的重復(fù)發(fā)送控制。冪等去重利用biz_type biz_id做唯一索引重復(fù)提交時(shí)直接返回原任務(wù)ID不產(chǎn)生新任務(wù)。發(fā)送層的去重更加精細(xì)比如短信通道同一個(gè)手機(jī)號(hào)5分鐘內(nèi)收到同一條模板消息的次數(shù)不能超過(guò)1次我用Redis的SETNX 過(guò)期時(shí)間來(lái)實(shí)現(xiàn)。頻控則要區(qū)分用戶維度和通道維度。用戶維度限制的是“單個(gè)用戶每天最多收到多少條營(yíng)銷通知”這個(gè)容易理解通道維度限制的是“短信供應(yīng)商每秒最多接受多少條請(qǐng)求”這個(gè)經(jīng)常被忽視。通道頻控我用的Redis令牌桶每個(gè)通道一個(gè)Key每秒放入固定數(shù)量的令牌取不到令牌的消息進(jìn)入等待隊(duì)列而不是直接丟棄。這里多說(shuō)一句防刷和頻控如果不做被黑的成本極高。比如攻擊者拿到開(kāi)放接口后批量偽造手機(jī)號(hào)提交幾萬(wàn)條短信費(fèi)用幾個(gè)小時(shí)內(nèi)就能把預(yù)算打光。所以接入層必須有API級(jí)鑒權(quán)每個(gè)業(yè)務(wù)方一個(gè)AppId 密鑰再加IP白名單和總調(diào)用量限制。3.4 通道路由與失敗切換機(jī)制通道路由是通知系統(tǒng)的“大腦”它決定了一條消息應(yīng)該走哪個(gè)通道。路由決策我推薦使用可配置的規(guī)則鏈先根據(jù)NotifyType確定通道候選集比如交易驗(yàn)證碼優(yōu)先短信、營(yíng)銷通知優(yōu)先Push和郵件再根據(jù)用戶偏好過(guò)濾用戶在App里主動(dòng)關(guān)閉了Push通知就要剔除Push通道然后按照通道健康狀態(tài)過(guò)濾已熔斷的通道剔除最后按優(yōu)先級(jí)權(quán)重選擇最終通道。路由規(guī)則要存儲(chǔ)在數(shù)據(jù)庫(kù)里而不是寫在代碼里。這樣產(chǎn)品同學(xué)調(diào)整消息策略時(shí)不需要發(fā)版后臺(tái)改配置即時(shí)生效。我見(jiàn)過(guò)一些團(tuán)隊(duì)把路由邏輯寫在Java代碼里改一次規(guī)則發(fā)一次版這種效率不可接受。失敗切換的兜底邏輯是發(fā)送失敗時(shí)如果存在備用通道且失敗原因不是“消息內(nèi)容本身有問(wèn)題”比如模板渲染失敗而是“通道不可用”超時(shí)、限流、供應(yīng)商報(bào)錯(cuò)則自動(dòng)切換到備用通道重試。切換的同時(shí)要發(fā)送一條內(nèi)部告警提醒運(yùn)維處理主通道故障。這個(gè)降級(jí)策略能夠讓交易類通知在短信通道故障時(shí)自動(dòng)轉(zhuǎn)走郵件或者站內(nèi)信保住最低限度的觸達(dá)能力。4. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 基礎(chǔ)環(huán)境準(zhǔn)備與組件部署我先梳理一下基礎(chǔ)環(huán)境的部署以一臺(tái)4核8G的Linux服務(wù)器為例生產(chǎn)建議至少三臺(tái)同配置機(jī)器組成集群。操作系統(tǒng)使用Rocky Linux 9或Ubuntu 22.04均可Java環(huán)境用OpenJDK 17這部分不做過(guò)多贅述。MySQL、Redis、RabbitMQ三個(gè)中間件我傾向于用Docker Compose統(tǒng)一編排管理雖然是生產(chǎn)環(huán)境但只是這三個(gè)基礎(chǔ)組件容器化的運(yùn)維效率更高。需要特別注意的是Redis部分生產(chǎn)環(huán)境不要裸跑單實(shí)例至少要開(kāi)啟主從哨兵模式。我的Redis高可用部署方案是1個(gè)主節(jié)點(diǎn)、2個(gè)從節(jié)點(diǎn)、3個(gè)哨兵進(jìn)程哨兵配置里quorum設(shè)為2表示至少2個(gè)哨兵同意才能判定主節(jié)點(diǎn)故障并觸發(fā)切換。這個(gè)方案我跑過(guò)很長(zhǎng)時(shí)間穩(wěn)定性非常可靠。RabbitMQ開(kāi)啟鏡像隊(duì)列在Management UI或者通過(guò)Policy設(shè)置ha-mode: all保證任何一個(gè)MQ節(jié)點(diǎn)宕機(jī)消息不丟失。給通知服務(wù)單獨(dú)建兩個(gè)隊(duì)列notify.task.queue用于待發(fā)送任務(wù)notify.dead.queue用于延遲重試和死信處理。4.2 應(yīng)用工程結(jié)構(gòu)與核心代碼實(shí)現(xiàn)應(yīng)用工程采用標(biāo)準(zhǔn)的Maven多模塊結(jié)構(gòu)我按職責(zé)拆成四個(gè)模塊notify-api、notify-core、notify-channel、notify-admin。API模塊給業(yè)務(wù)方提供SDK的Feign接口定義Core模塊承載核心處理流程Channel模塊放各個(gè)通道實(shí)現(xiàn)Admin模塊是后臺(tái)管理界面。核心處理流程的入口是NotifyService.submit()方法流程如下先做接口鑒權(quán)再校驗(yàn)參數(shù)然后根據(jù)biz_type biz_id到Redis做冪等檢查通過(guò)后持久化任務(wù)并投遞到MQ。關(guān)鍵代碼如下實(shí)際項(xiàng)目里我還加了全局異常處理和日志埋點(diǎn)這里只展示核心邏輯。Service public class NotifyServiceImpl implements NotifyService { Autowired private NotifyTaskMapper taskMapper; Autowired private StringRedisTemplate redisTemplate; Autowired private RabbitTemplate rabbitTemplate; Transactional public Long submit(NotifyRequest request) { // 1. 鑒權(quán)校驗(yàn) authService.checkAppAccess(request.getAppId()); // 2. 冪等去重 String idempotentKey request.getBizType() : request.getBizId(); Boolean firstSubmit redisTemplate.opsForValue() .setIfAbsent(idempotentKey, 1, Duration.ofHours(24)); if (Boolean.FALSE.equals(firstSubmit)) { throw new DuplicateSubmitException(重復(fù)提交的通知請(qǐng)求); } // 3. 持久化任務(wù) NotifyTask task buildTask(request); taskMapper.insert(task); // 4. 發(fā)送到MQ待處理隊(duì)列 rabbitTemplate.convertAndSend(notify.exchange, notify.task.queue, task); return task.getId(); } }4.3 發(fā)送端消費(fèi)邏輯與重試機(jī)制發(fā)送端的消費(fèi)邏輯要特別注意一定不要用默認(rèn)的自動(dòng)ack模式改用手動(dòng)ack。手動(dòng)ack的含義是MQ推送消息給消費(fèi)者消費(fèi)者處理完成后再告訴MQ“這條消息我處理好了”MQ才把消息從隊(duì)列中刪除如果沒(méi)有ackMQ會(huì)把消息重新投遞給其他消費(fèi)者。這樣能保證消息不會(huì)因?yàn)橄M(fèi)者宕機(jī)而丟失。消費(fèi)處理器拿到任務(wù)后調(diào)用路由服務(wù)選擇通道再調(diào)用通道發(fā)送。如果通道發(fā)送成功更新任務(wù)狀態(tài)為SUCCESS并提交ack如果失敗判斷重試次數(shù)是否達(dá)到上限沒(méi)達(dá)到則把任務(wù)投遞到延遲隊(duì)列延遲時(shí)間按照指數(shù)退避計(jì)算第一次30秒、第二次1分鐘、第三次5分鐘達(dá)到上限則標(biāo)記為DEAD并走人工補(bǔ)償流程。這塊有個(gè)很容易出問(wèn)題的點(diǎn)消費(fèi)端是并發(fā)消費(fèi)的同一個(gè)手機(jī)號(hào)可能有兩條不同業(yè)務(wù)的通知同時(shí)進(jìn)入發(fā)送流程如果通道實(shí)現(xiàn)不是線程安全的會(huì)產(chǎn)生數(shù)據(jù)競(jìng)爭(zhēng)。比如某些短信供應(yīng)商的SDK內(nèi)部用一個(gè)非線程安全的連接池并發(fā)調(diào)用時(shí)會(huì)報(bào)錯(cuò)。我的建議是每個(gè)通道實(shí)例內(nèi)部單獨(dú)持有連接資源用ThreadPoolExecutor做隔離避免一個(gè)通道卡死影響其他通道。延遲隊(duì)列在RabbitMQ里的實(shí)現(xiàn)原理是設(shè)置消息的expiration屬性讓消息在隊(duì)列中待夠指定時(shí)間才能被消費(fèi)。這里有一個(gè)需要注意的坑同一個(gè)隊(duì)列里的消息如果設(shè)置了不同的過(guò)期時(shí)間RabbitMQ只會(huì)看隊(duì)首消息的過(guò)期時(shí)間所以如果隊(duì)首消息過(guò)期時(shí)間是5分鐘后面的消息過(guò)期時(shí)間即使是30秒也要等隊(duì)首消息時(shí)間到了才會(huì)被掃描。解決辦法是按照延遲級(jí)別拆成多個(gè)獨(dú)立隊(duì)列每個(gè)隊(duì)列只處理固定的延遲時(shí)間。4.4 通道接入實(shí)站以阿里云短信為例我用短信通道作為例子完整走一遍通道接入流程。首先在notify-channel模塊里新建AliyunSmsChannel類實(shí)現(xiàn)NotifyChannel接口。getChannelCode()返回sms_aliyunsend()方法里調(diào)用阿里云短信SDK發(fā)送發(fā)送之前要做手機(jī)號(hào)格式校驗(yàn)發(fā)送之后根據(jù)SDK返回結(jié)果構(gòu)造統(tǒng)一的SendResult。Component public class AliyunSmsChannel extends AbstractSmsChannel { Value(${sms.aliyun.accessKeyId:}) private String accessKeyId; Value(${sms.aliyun.accessKeySecret:}) private String accessKeySecret; Value(${sms.aliyun.signName:}) private String signName; Override protected SendResult doSend(NotifyMessage message) { DefaultProfile profile DefaultProfile.getProfile(cn-hangzhou, accessKeyId, accessKeySecret); IAcsClient client new DefaultAcsClient(profile); CommonRequest request new CommonRequest(); request.setSysMethod(MethodType.POST); request.setSysDomain(dysmsapi.aliyuncs.com); request.setSysVersion(2017-05-25); request.setSysAction(SendSms); request.putQueryParameter(PhoneNumbers, message.getReceiver()); request.putQueryParameter(SignName, signName); request.putQueryParameter(TemplateCode, message.getTemplateCode()); request.putQueryParameter(TemplateParam, message.getTemplateParams()); try { CommonResponse response client.getCommonResponse(request); MapString, Object result JSON.parseObject(response.getData()); if (OK.equals(result.get(Code))) { return SendResult.success(); } return SendResult.fail(String.valueOf(result.get(Message))); } catch (Exception e) { return SendResult.fail(e.getMessage()); } } }通道接入的關(guān)鍵是把供應(yīng)商的差異全部隔離在通道實(shí)現(xiàn)類內(nèi)部。業(yè)務(wù)層只認(rèn)SendResult的success和fail不關(guān)心通道內(nèi)部調(diào)用了什么接口、用了什么認(rèn)證方式。這樣接新通道的工時(shí)基本可以控制在半天以內(nèi)無(wú)非是照葫蘆畫瓢再實(shí)現(xiàn)一個(gè)類。4.5 消息積壓與補(bǔ)償機(jī)制的兜底方案即使架構(gòu)設(shè)計(jì)得再完美在大促或者突發(fā)流量面前消費(fèi)速度仍有可能趕不上生產(chǎn)速度造成消息積壓。積壓并不可怕可怕的是沒(méi)有積壓的感知和補(bǔ)償機(jī)制。我做的方案是監(jiān)控RabbitMQ隊(duì)列中待消費(fèi)消息的數(shù)量超過(guò)閾值就觸發(fā)告警并自動(dòng)擴(kuò)容消費(fèi)者實(shí)例手動(dòng)擴(kuò)容或K8s的HPA策略。同時(shí)維護(hù)一個(gè)補(bǔ)償任務(wù)每隔5分鐘掃描一次notify_task表中狀態(tài)為PENDING且next_retry_time小于當(dāng)前時(shí)間的任務(wù)重新投遞到MQ隊(duì)列。這個(gè)補(bǔ)償任務(wù)能兜底處理一切因?yàn)橄到y(tǒng)重啟、MQ宕機(jī)等原因遺漏的消息。補(bǔ)償任務(wù)的設(shè)計(jì)上要注意不要和正常的消費(fèi)任務(wù)沖突。掃描SQL必須帶上next_retry_time字段條件并且一次最多取500條避免一把梭查全表導(dǎo)致數(shù)據(jù)庫(kù)壓力過(guò)大。處理完的任務(wù)要立即更新時(shí)間戳防止被下一次掃描重復(fù)撈起。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 高頻故障案例提煉我在多個(gè)項(xiàng)目的生產(chǎn)環(huán)境里總結(jié)了一些高頻故障整理成速查表方便大家在項(xiàng)目上線后對(duì)照排查故障現(xiàn)象可能原因排查命令/工具解決方案消息大量積壓、消費(fèi)速率極低消費(fèi)線程數(shù)過(guò)小或某一通道阻塞rabbitmqctl list_queues、查看線程池活躍度調(diào)大消費(fèi)線程數(shù)通道線程池隔離通知延時(shí)明顯增大模板渲染耗時(shí)過(guò)高或頻控等待Tracing查看耗時(shí)Redis Key數(shù)量檢查模板渲染加緩存頻控改為異步等待短信丟失率高供應(yīng)商限流被拒查看通道返回碼檢查限流閾值開(kāi)啟備用通道自動(dòng)切換重復(fù)推送消費(fèi)端業(yè)務(wù)處理超時(shí)MQ重投導(dǎo)致查看任務(wù)表biz_id是否有重復(fù)發(fā)送前增加Redis去重檢查數(shù)據(jù)庫(kù)壓力大黃金時(shí)段頻繁掃表補(bǔ)償慢SQL日志、SHOW PROCESSLIST調(diào)整掃描周期分批處理通知內(nèi)容亂碼模板參數(shù)編碼問(wèn)題查看渲染日志確認(rèn)字符串編碼統(tǒng)一UTF-8編碼并在接入層強(qiáng)校驗(yàn)5.2 排查鏈路追蹤與日志規(guī)范排查問(wèn)題最重要的工具是鏈路追蹤和結(jié)構(gòu)化日志。我的做法是在接入層生成一個(gè)trace_id用UUID或雪花算法然后在處理層、發(fā)送層每個(gè)關(guān)鍵模塊的日志中都打印這個(gè)trace_id。這樣一條消息從提交到成功全鏈路日志可以用一個(gè)ID串起來(lái)查問(wèn)題效率提升非常明顯。日志規(guī)范上我要求核心模塊的WARN和ERROR日志統(tǒng)一用JSON格式輸出帶上時(shí)間戳、trace_id、biz_type、channel_code等字段方便接入ELK或者Loki做日志檢索。一個(gè)時(shí)刻大量ERROR日志報(bào)警時(shí)用tail -f加grep trace_id的方式能快速定位到具體是哪一批消息在哪一步出了問(wèn)題。5.3 高可用切換的真實(shí)場(chǎng)景復(fù)盤有一次生產(chǎn)環(huán)境中短信通道的底層供應(yīng)商因?yàn)橄到y(tǒng)升級(jí)頻繁超時(shí)成功率從99%掉到70%。我的通道健康檢查邏輯檢測(cè)到連續(xù)失敗30次后自動(dòng)熔斷并切換到了備用短信供應(yīng)商整個(gè)過(guò)程沒(méi)有人工干預(yù)。事后復(fù)盤發(fā)現(xiàn)兩個(gè)問(wèn)題一個(gè)是健康檢查的失敗閾值設(shè)得偏保守導(dǎo)致的后果是熔斷觸發(fā)前已經(jīng)有一小部分消息失敗了另一個(gè)是切換過(guò)程中正在發(fā)送中的消息因?yàn)橥ǖ罓顟B(tài)不一致丟失了幾十條。后來(lái)我做了兩個(gè)改進(jìn)第一健康檢查的窗口從“連續(xù)失敗N次”改成“滑動(dòng)窗口內(nèi)失敗率超過(guò)50%”這樣能更快感知故障第二通道切換動(dòng)作不直接在發(fā)送線程里做而是通過(guò)一個(gè)獨(dú)立的管理線程完成切換前要等正在發(fā)送的消息返回結(jié)果或者超時(shí)保證發(fā)送中的消息不會(huì)被白白丟棄。5.4 性能壓測(cè)與容量評(píng)估記錄系統(tǒng)上線前一定要做壓測(cè)不能拍腦袋覺(jué)得“夠用”。我的壓測(cè)方案用JMeter模擬業(yè)務(wù)方調(diào)用目標(biāo)場(chǎng)景是“峰值每秒5000條通知提交持續(xù)10分鐘”。測(cè)試結(jié)果基本符合預(yù)期單機(jī)4核8G部署的應(yīng)用節(jié)點(diǎn)TPS穩(wěn)定在3000左右CPU利用率約70%瓶頸出現(xiàn)在Redis的頻控檢查上單個(gè)Redis實(shí)例的GETSET操作在高并發(fā)下毛刺明顯。優(yōu)化方案是頻控Key的拆分和本地緩存。每個(gè)通道的頻控計(jì)數(shù)從“Redis每秒一個(gè)Key”改成“Redis每5秒一個(gè)Key 本地內(nèi)存補(bǔ)一次”這樣Redis壓力直接降到原來(lái)的五分之一。另外壓測(cè)時(shí)建議把日志級(jí)別調(diào)到WARN不然大量INFO日志的IO開(kāi)銷會(huì)占掉不少CPU。容量評(píng)估方面我給的參考公式是單機(jī)支撐能力TPS× 節(jié)點(diǎn)數(shù) × 安全系數(shù)0.7 ≥ 預(yù)估峰值TPS。比如預(yù)估峰值5000單機(jī)3000那至少需要3臺(tái)節(jié)點(diǎn)。安全系數(shù)0.7是為故障節(jié)點(diǎn)預(yù)留的冗余不能算得太滿否則一臺(tái)機(jī)器宕機(jī)整個(gè)集群就扛不住了。6. 項(xiàng)目落地與經(jīng)驗(yàn)總結(jié)6.1 從0到1的落地路線圖如果你所在團(tuán)隊(duì)想要落地這樣一套通知服務(wù)我的建議是分四個(gè)階段走。第一階段搞定MVP實(shí)現(xiàn)HTTP接入、RabbitMQ異步處理、短信和郵件兩個(gè)通道能夠完成“提交通知任務(wù) → 發(fā)送成功”的基礎(chǔ)閉環(huán)。第二階段完善可靠性加上Redis去重頻控、失敗重試、死信補(bǔ)償確保消息不丟不重復(fù)。第三階段提升可擴(kuò)展性完善后臺(tái)管理功能模板做到按通道獨(dú)立配置路由規(guī)則做到動(dòng)態(tài)可調(diào)整。第四階段做高可用和可觀測(cè)部署多個(gè)應(yīng)用節(jié)點(diǎn)中間件全部高可用接入監(jiān)控告警和鏈路追蹤。每個(gè)階段的驗(yàn)收標(biāo)準(zhǔn)也要提前想好。第一階段是“能發(fā)出去”第二階段是“發(fā)得可靠”第三階段是“改得快”第四階段是“掛不了”。6.2 關(guān)于n8n等自動(dòng)化工具的融合思考在做完自研通知服務(wù)之后我其實(shí)還調(diào)研過(guò)n8n這類自動(dòng)化工作流工具的企業(yè)級(jí)部署方案。它們擅長(zhǎng)的是把不同系統(tǒng)的動(dòng)作編排成自動(dòng)化流程比如當(dāng)CRM里新增一個(gè)線索自動(dòng)發(fā)釘釘通知并建一條企微待辦。這類工具和自研通知服務(wù)并不沖突甚至是一個(gè)很好的補(bǔ)充自研服務(wù)負(fù)責(zé)“中心化的通道能力和可靠性保障”n8n負(fù)責(zé)“輕量化的業(yè)務(wù)自動(dòng)化編排”。如果你團(tuán)隊(duì)里有很多需要“事件觸發(fā) → 多步驟動(dòng)作”的場(chǎng)景可以考慮在通知服務(wù)之上再套一層工作流引擎讓業(yè)務(wù)人員也能自助編排通知行為。不過(guò)n8n的節(jié)點(diǎn)執(zhí)行效率和一些高級(jí)特性可能與自研服務(wù)有差距大規(guī)模、高并發(fā)場(chǎng)景還是自研服務(wù)更可控。這個(gè)取舍就看團(tuán)隊(duì)業(yè)務(wù)的側(cè)重點(diǎn)了。6.3 維護(hù)成本與團(tuán)隊(duì)能力要求最后聊一下維護(hù)成本和團(tuán)隊(duì)要求。這套系統(tǒng)落地后日常維護(hù)核心就是三塊中間件的健康巡檢、通道供應(yīng)商的配額和價(jià)格監(jiān)控、模板和路由規(guī)則的變更配置。代碼層面的改動(dòng)頻率并不會(huì)太高主要集中在新通道接入和異常邏輯優(yōu)化。對(duì)團(tuán)隊(duì)的能力要求是至少有一名成員熟悉RabbitMQ和Redis的原理和運(yùn)維有兩名成員能看懂核心業(yè)務(wù)代碼并做代碼Review。如果團(tuán)隊(duì)連這些基礎(chǔ)能力都不具備我建議先不要上自研用云廠商的現(xiàn)成推送服務(wù)過(guò)渡會(huì)更穩(wěn)妥。還有一個(gè)心得通知系統(tǒng)的代碼量雖然不大但它的跨團(tuán)隊(duì)協(xié)作屬性很強(qiáng)。上線前一定要和業(yè)務(wù)方、客服團(tuán)隊(duì)對(duì)齊“通知延遲超過(guò)XX分鐘應(yīng)該找誰(shuí)”“短信發(fā)送失敗用戶投訴應(yīng)該走什么流程”這些非技術(shù)問(wèn)題。很多項(xiàng)目技術(shù)方案都很好最后因?yàn)閰f(xié)作流程沒(méi)定清楚系統(tǒng)上線后被投訴淹沒(méi)。我個(gè)人在實(shí)際項(xiàng)目里最大的體會(huì)是做通知系統(tǒng)細(xì)節(jié)決定成敗。一個(gè)模板參數(shù)沒(méi)配上、一個(gè)頻控閾值設(shè)少了、一個(gè)通道沒(méi)做健康檢查生產(chǎn)上就是真實(shí)的資損和客訴。架構(gòu)上可以借鑒成熟方案但真正的功力都藏在那些不起眼的重試策略、路由降級(jí)、日志規(guī)范里。希望這篇文章能讓大家少走一些我之前走過(guò)的彎路把消息通知這個(gè)“小系統(tǒng)”做出真正可靠的企業(yè)級(jí)水準(zhǔn)。