1. 先別急著寫(xiě)代碼短信服務(wù)商的選型邏輯和那些被忽略的坑做Java后端的朋友遲早都會(huì)接到短信需求?？赡苁怯脩糇?cè)時(shí)的驗(yàn)證碼可能是登錄二次校驗(yàn)也可能是訂單通知、營(yíng)銷觸達(dá)。我第一次接到短信接口對(duì)接任務(wù)時(shí)第一反應(yīng)是這有什么難的找個(gè)服務(wù)商SDK調(diào)一下就行了結(jié)果真正落地的時(shí)候才發(fā)現(xiàn)短信接口遠(yuǎn)不止調(diào)一個(gè)API這么簡(jiǎn)單。這篇內(nèi)容我就以Spring Boot項(xiàng)目為例把從零對(duì)接短信接口的全流程拆開(kāi)來(lái)講包括服務(wù)商如何選、配置怎么管、驗(yàn)證碼怎么存、異步發(fā)送怎么做、回調(diào)怎么接、生產(chǎn)環(huán)境還有哪些必須處理的細(xì)節(jié)。適合剛接觸短信開(kāi)發(fā)的后端工程師也適合準(zhǔn)備在自己的項(xiàng)目里接入短信驗(yàn)證碼功能的朋友參考。先說(shuō)結(jié)論短信服務(wù)商選型基本決定了你后面80%的踩坑體驗(yàn)。市面上主流的國(guó)內(nèi)服務(wù)商就是阿里云、騰訊云、華為云這幾家還有一堆中小型短信平臺(tái)。我自己的判斷標(biāo)準(zhǔn)就三條第一是到達(dá)率和穩(wěn)定性第二是SDK質(zhì)量和文檔完善度第三是審核速度和售后響應(yīng)。價(jià)格其實(shí)反而沒(méi)那么關(guān)鍵短信本身就不貴一條幾分錢真正貴的是你上線之后發(fā)現(xiàn)到達(dá)率低、用戶收不到驗(yàn)證碼導(dǎo)致流失的隱性成本。我最終選的是阿里云的短信服務(wù)一是因?yàn)樗襍DK更新積極Java調(diào)用方式比較統(tǒng)一二是文檔和示例相對(duì)完善遇到底層報(bào)錯(cuò)能查到解決方案三是簽名和模板審核有獨(dú)立的控制臺(tái)入口操作路徑清晰。騰訊云我也用過(guò)主要是它有個(gè)很實(shí)用的能力——正文模板內(nèi)支持變量動(dòng)態(tài)拼接做營(yíng)銷類通知很方便但如果你只是做驗(yàn)證碼場(chǎng)景阿里云和騰訊云差別不大。選型階段還有兩個(gè)前置工作必須提前做因?yàn)樗鼈兊膶徍酥芷跁?huì)直接影響你的上線計(jì)劃。一個(gè)是申請(qǐng)短信簽名一個(gè)是申請(qǐng)短信模板。簽名就是用戶收到短信時(shí)看到的發(fā)送方名稱比如某某科技模板就是你短信正文的格式比如您的驗(yàn)證碼為${code}5分鐘內(nèi)有效。審核時(shí)長(zhǎng)一般是一到兩個(gè)工作日如果涉及行業(yè)資質(zhì)可能更久。所以我的建議是項(xiàng)目啟動(dòng)第一天就把簽名和模板申請(qǐng)?zhí)峤涣瞬灰却a寫(xiě)完了再申請(qǐng)否則你只能干等著審核結(jié)果白白浪費(fèi)時(shí)間。注意簽名和模板的命名是有規(guī)范的個(gè)人開(kāi)發(fā)者可選的簽名類型通常只有APP應(yīng)用和公眾號(hào)/小程序企業(yè)用戶可以有公司全稱/簡(jiǎn)稱等更多類型。模板內(nèi)容不要出現(xiàn)營(yíng)銷敏感詞比如加微信點(diǎn)擊鏈接領(lǐng)取紅包這類否則大概率被駁回。2. 工程地基Spring Boot項(xiàng)目如何把短信配置做成一個(gè)干凈的后端模塊服務(wù)商定了、簽名模板審核通過(guò)了接下來(lái)才是正式寫(xiě)代碼。這里我建議從第一步就考慮好工程結(jié)構(gòu)不要直接把發(fā)送邏輯散落在Controller里。原因很簡(jiǎn)單短信功能涉及配置管理、參數(shù)校驗(yàn)、調(diào)用服務(wù)商、結(jié)果處理、日志記錄、重試策略多個(gè)環(huán)節(jié)任何一環(huán)寫(xiě)腫了后續(xù)維護(hù)都很難受。2.1 Maven依賴怎么加新舊版SDK到底選哪個(gè)阿里云短信的Java SDK目前有兩個(gè)路線。老一代的是aliyun-java-sdk-core加aliyun-java-sdk-dysmsapi代碼寫(xiě)起來(lái)比較繞需要手動(dòng)組裝Request對(duì)象很多老項(xiàng)目里能看到它。新一代的是com.aliyun:dysmsapi20170525基于tea-openapi框架構(gòu)建用起來(lái)明顯更順手參數(shù)鏈?zhǔn)劫x值日志也更清晰。我建議新項(xiàng)目直接上新版SDK別因?yàn)榫W(wǎng)上老教程多用舊版就跟著踩坑。dependency groupIdcom.aliyun/groupId artifactIddysmsapi20170525/artifactId version2.0.24/version /dependency這個(gè)版本號(hào)不一定是當(dāng)前最新的你可以在Maven中央倉(cāng)庫(kù)確認(rèn)一下。需要注意一個(gè)點(diǎn)新版SDK傳遞依賴了com.aliyun:tea-openapi和com.aliyun:tea如果你的項(xiàng)目里已有老舊的阿里云SDK版本可能產(chǎn)生類沖突。解決辦法是統(tǒng)一升級(jí)到該SDK依賴的最新版本或者排除掉沖突傳遞依賴。2.2 配置文件里到底該放什么不該放什么短信配置的核心是AccessKey ID和AccessKey Secret這兩個(gè)東西幾乎等價(jià)于你賬號(hào)的鑰匙。密鑰一旦泄露別人就能拿你的賬號(hào)發(fā)短信導(dǎo)致的直接后果是余額被刷光更嚴(yán)重的是簽名和模板可能被標(biāo)記為惡意從而被服務(wù)商封禁。我見(jiàn)過(guò)不少項(xiàng)目把AccessKey Secret直接明文寫(xiě)在application.yml里還給提交到Git倉(cāng)庫(kù)。這是非常危險(xiǎn)的習(xí)慣。即使只是內(nèi)網(wǎng)項(xiàng)目也不建議這么做。現(xiàn)在阿里云控制臺(tái)里可以直接創(chuàng)建子用戶AccessKey并限制其權(quán)限只能調(diào)用短信服務(wù)。生產(chǎn)環(huán)境更建議配合配置中心比如Nacos或Apollo把明文密鑰放在配置中心并做權(quán)限控制本地application.yml只保留開(kāi)發(fā)環(huán)境的測(cè)試密鑰。spring: application: name: sms-service aliyun: sms: # 生產(chǎn)和測(cè)試環(huán)境使用不同的key通過(guò)profile切換 access-key-id: ${SMS_ACCESS_KEY_ID} access-key-secret: ${SMS_ACCESS_KEY_SECRET} sign-name: 某某科技 template-code: SMS_123456789 endpoint: dysmsapi.aliyuncs.com我習(xí)慣把AccessKey等敏感配置通過(guò)環(huán)境變量的方式注入這個(gè)做法在Docker部署和Kubernetes部署時(shí)尤其方便。你只需要在運(yùn)行環(huán)境中設(shè)置好環(huán)境變量代碼里用${SMS_ACCESS_KEY_ID}占位Spring Boot會(huì)自動(dòng)完成替換。2.3 配置綁定和客戶端封裝要讓調(diào)用方無(wú)感知配置綁定我一般會(huì)建一個(gè)SmsProperties類用ConfigurationProperties自動(dòng)綁定配置項(xiàng)。這樣做的好處是后續(xù)無(wú)論是切換服務(wù)商還是增加簽名和模板的映射關(guān)系只需改動(dòng)配置和這一個(gè)類業(yè)務(wù)代碼完全不受影響。Component ConfigurationProperties(prefix aliyun.sms) Data public class SmsProperties { private String accessKeyId; private String accessKeySecret; private String signName; private String templateCode; private String endpoint; }然后是客戶端初始化。新版SDK的初始化方式如下Configuration public class SmsClientConfig { Bean public com.aliyun.dysmsapi20170525.Client smsClient(SmsProperties properties) { com.aliyun.teaopenapi.models.Config config new com.aliyun.teaopenapi.models.Config() .setAccessKeyId(properties.getAccessKeyId()) .setAccessKeySecret(properties.getAccessKeySecret()); config.endpoint properties.getEndpoint(); try { return new com.aliyun.dysmsapi20170525.Client(config); } catch (Exception e) { throw new RuntimeException(初始化短信客戶端失敗, e); } } }這里有一個(gè)經(jīng)驗(yàn)Client是線程安全的可以全局復(fù)用不要每次發(fā)送都new一個(gè)。如果你參照網(wǎng)上某些教程把Client放在方法里創(chuàng)建在高并發(fā)場(chǎng)景下你會(huì)頻繁創(chuàng)建連接既浪費(fèi)資源又增加了超時(shí)概率。3. 核心發(fā)送邏輯這樣設(shè)計(jì)驗(yàn)證碼場(chǎng)景的存儲(chǔ)、校驗(yàn)與異步發(fā)送一步到位短信發(fā)送的代碼本身不難難的是把發(fā)送邏輯設(shè)計(jì)得扛得住線上真實(shí)壓力。這部分的重點(diǎn)不只是調(diào)通接口而是想清楚驗(yàn)證碼怎么存、怎么校驗(yàn)、重復(fù)發(fā)送怎么攔截、接口超時(shí)怎么辦。下面這三個(gè)小節(jié)是我做短信功能時(shí)沉淀下來(lái)的核心設(shè)計(jì)。3.1 發(fā)送短信的主流程代碼這樣寫(xiě)最不容易出問(wèn)題一條短信的發(fā)送邏輯從業(yè)務(wù)側(cè)看很簡(jiǎn)單手機(jī)號(hào)、簽名、模板、模板參數(shù)四樣?xùn)|西齊了就能調(diào)。但實(shí)際工程里我們還要在調(diào)用服務(wù)商之前做好參數(shù)校驗(yàn)避免把亂七八糟的數(shù)據(jù)傳給第三方。Service public class SmsServiceImpl implements SmsService { Resource private Client smsClient; Resource private SmsProperties smsProperties; Resource private StringRedisTemplate redisTemplate; Override public void sendSmsCode(String phone) { // 1. 參數(shù)合法性校驗(yàn)手機(jī)號(hào)格式不對(duì)直接拒絕 if (!PhoneValidator.isValid(phone)) { throw new BizException(手機(jī)號(hào)格式不正確); } // 2. 防刷校驗(yàn)同一手機(jī)號(hào)60秒內(nèi)只能發(fā)一次 String sendFlagKey sms:send:count: phone; Boolean absent redisTemplate.opsForValue() .setIfAbsent(sendFlagKey, 1, Duration.ofSeconds(60)); if (Boolean.FALSE.equals(absent)) { throw new BizException(發(fā)送過(guò)于頻繁請(qǐng)稍后再試); } // 3. 生成6位隨機(jī)驗(yàn)證碼 String code String.valueOf(ThreadLocalRandom.current().nextInt(100000, 999999)); // 4. 驗(yàn)證碼先入庫(kù)這里用Redis設(shè)置5分鐘有效 redisTemplate.opsForValue() .set(buildCodeKey(phone), code, Duration.ofMinutes(5)); // 5. 異步調(diào)用服務(wù)商發(fā)送 asyncSendSms(phone, code); } Async(smsExecutor) protected void asyncSendSms(String phone, String code) { try { com.aliyun.dysmsapi20170525.models.SendSmsRequest request new com.aliyun.dysmsapi20170525.models.SendSmsRequest() .setPhoneNumbers(phone) .setSignName(smsProperties.getSignName()) .setTemplateCode(smsProperties.getTemplateCode()) .setTemplateParam({\code\:\ code \}); com.aliyun.dysmsapi20170525.models.SendSmsResponse response smsClient.sendSms(request); if (!OK.equals(response.getBody().getCode())) { log.error(短信發(fā)送失敗, phone:{}, code:{}, resp:{}, phone, code, response.getBody()); } } catch (Exception e) { log.error(短信發(fā)送異常, phone:{}, phone, e); } } }簡(jiǎn)單解釋一下setIfAbsent是Redis的原子操作當(dāng)key不存在時(shí)才會(huì)寫(xiě)入利用它可以直接實(shí)現(xiàn)60秒內(nèi)不能重復(fù)發(fā)送的防刷邏輯。驗(yàn)證碼先寫(xiě)入Redis再異步發(fā)送是因?yàn)橛脩趔w驗(yàn)優(yōu)先——接口要快速返回不能卡在第三方網(wǎng)絡(luò)請(qǐng)求上。至于異步發(fā)送失敗怎么辦下一節(jié)細(xì)說(shuō)。3.2 驗(yàn)證碼的存儲(chǔ)與校驗(yàn)正是體現(xiàn)后端功力的時(shí)候短信驗(yàn)證碼最常見(jiàn)的場(chǎng)景是用戶注冊(cè)或登錄時(shí)的校驗(yàn)。它的核心訴求有三個(gè)驗(yàn)證碼不能明文存數(shù)據(jù)庫(kù)、必須有過(guò)期時(shí)間、校驗(yàn)時(shí)要能防止暴力嘗試。用Redis存驗(yàn)證碼是目前最主流的做法。我把驗(yàn)證碼的key設(shè)計(jì)成sms:code:{phone}value直接存6位數(shù)字。校驗(yàn)的時(shí)候取出Redis里的值和用戶提交的驗(yàn)證碼比較相等則校驗(yàn)通過(guò)并立即刪除一次性使用不相等則記錄失敗次數(shù)超過(guò)5次就刪除驗(yàn)證碼要求用戶重新獲取。Override public boolean verifySmsCode(String phone, String code) { String key buildCodeKey(phone); String cachedCode redisTemplate.opsForValue().get(key); if (cachedCode null) { throw new BizException(驗(yàn)證碼已過(guò)期請(qǐng)重新獲取); } // 校驗(yàn)失敗次數(shù)防止暴力破解 String failKey key :fail; Long failCount redisTemplate.opsForValue().increment(failKey); if (failCount ! null failCount 5) { redisTemplate.delete(key); redisTemplate.delete(failKey); throw new BizException(嘗試次數(shù)過(guò)多請(qǐng)重新獲取驗(yàn)證碼); } if (cachedCode.equals(code)) { redisTemplate.delete(key); redisTemplate.delete(failKey); return true; } redisTemplate.expire(failKey, Duration.ofMinutes(5)); throw new BizException(驗(yàn)證碼錯(cuò)誤); }這里有個(gè)容易被忽視的細(xì)節(jié)驗(yàn)證碼是敏感信息不管在日志還是數(shù)據(jù)庫(kù)里都不能以明文形式整體出現(xiàn)。非要記錄日志建議只打印后四位或者做脫敏處理。因?yàn)轵?yàn)證碼短信一旦被中間人截獲或日志泄露攻擊者可以直接用來(lái)重置密碼、登錄賬號(hào)。3.3 異步發(fā)送和重試機(jī)制是短信接口穩(wěn)定性的關(guān)鍵保障短信發(fā)送依賴第三方服務(wù)商的網(wǎng)絡(luò)大概率會(huì)出現(xiàn)偶發(fā)性超時(shí)或失敗。如果發(fā)送邏輯寫(xiě)成同步用戶請(qǐng)求就會(huì)一直轉(zhuǎn)圈如果失敗后不做任何處理用戶就永遠(yuǎn)收不到驗(yàn)證碼只能重新觸發(fā)發(fā)送。這兩者都是糟糕體驗(yàn)。我的方案是使用Spring的Async注解配合自定義線程池將短信發(fā)送從主線程中剝離。實(shí)際項(xiàng)目中我通常單獨(dú)定義一個(gè)SmsExecutorConfigConfiguration public class SmsExecutorConfig { Bean(smsExecutor) public ThreadPoolTaskExecutor smsExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(4); executor.setMaxPoolSize(8); executor.setQueueCapacity(200); executor.setThreadNamePrefix(sms-exec-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }為什么用CallerRunsPolicy而不是直接丟棄因?yàn)楫?dāng)任務(wù)隊(duì)列滿了說(shuō)明系統(tǒng)短時(shí)間內(nèi)的短信請(qǐng)求量已經(jīng)很大這時(shí)候用調(diào)用者線程執(zhí)行相當(dāng)于天然限流避免任務(wù)靜默丟失。同時(shí)我在異步發(fā)送方法內(nèi)重試兩次第一次間隔2秒第二次間隔4秒。如果兩次重試都失敗就打WARN級(jí)別日志并標(biāo)記一條失敗記錄后續(xù)通過(guò)定時(shí)任務(wù)補(bǔ)償。這里要額外注意Async生效的前提是調(diào)用方和被調(diào)用方不能是同一個(gè)類內(nèi)部調(diào)用且必須是Spring Bean。所以我把a(bǔ)syncSendSms設(shè)計(jì)成了protected方法從sendSmsCode里跨類調(diào)用如果是同一個(gè)ServiceImpl內(nèi)部調(diào)用會(huì)出現(xiàn)自調(diào)用不代理的問(wèn)題異步注解失效。初次接觸Spring異步的朋友經(jīng)常在這里踩坑以為注解寫(xiě)上就行結(jié)果發(fā)現(xiàn)還是同步執(zhí)行就是這個(gè)原因。4. 跑通本地聯(lián)調(diào)和回調(diào)接收如何讓短信真正發(fā)出去并拿到狀態(tài)報(bào)告代碼寫(xiě)完了怎么驗(yàn)證邏輯對(duì)不對(duì)最直接的方式就是寫(xiě)一個(gè)測(cè)試Controller傳入真實(shí)手機(jī)號(hào)看短信能不能收到。但這一階段有些細(xì)節(jié)值得說(shuō)一說(shuō)因?yàn)楹芏嗳丝ㄔ诒镜卣{(diào)不通回調(diào)接不到這類問(wèn)題上。4.1 本地測(cè)試環(huán)境如何配置避免誤發(fā)線上短信短信是花錢的服務(wù)本地開(kāi)發(fā)聯(lián)調(diào)時(shí)如果每次都用真實(shí)手機(jī)號(hào)發(fā)送一天下來(lái)費(fèi)用也夠點(diǎn)幾頓外賣了。阿里云控制臺(tái)提供了測(cè)試專用簽名和測(cè)試模板申請(qǐng)通過(guò)后測(cè)試模板有固定的格式比如您的驗(yàn)證碼為${code}您正在使用測(cè)試模板發(fā)送短信。用測(cè)試模板發(fā)短信不會(huì)真正觸達(dá)用戶手機(jī)號(hào)碼而是在控制臺(tái)的短信記錄中看到發(fā)送詳情。如果你確實(shí)需要在自己手機(jī)上收到真實(shí)短信那就必須用已審核通過(guò)的正式簽名和模板。建議把測(cè)試手機(jī)號(hào)放到配置里只在開(kāi)發(fā)環(huán)境使用比如# application-dev.yml aliyun: sms: test-phone: 13800000000Controller接口里可以加一個(gè)邏輯當(dāng)spring.profiles.activedev且手機(jī)號(hào)不在白名單中時(shí)直接返回開(kāi)發(fā)環(huán)境僅允許測(cè)試號(hào)碼發(fā)送。這樣能防止聯(lián)調(diào)時(shí)誤把測(cè)試數(shù)據(jù)發(fā)到真實(shí)用戶手機(jī)里。4.2 回調(diào)接口的正確接入姿勢(shì)短信服務(wù)商會(huì)異步推送短信的狀態(tài)報(bào)告比如已發(fā)送已到達(dá)發(fā)送失敗用戶拒收等。這個(gè)回調(diào)是HTTP POST請(qǐng)求服務(wù)商把狀態(tài)數(shù)據(jù)以JSON格式POST到你提供的回調(diào)地址上。回調(diào)接口本質(zhì)上是接收第三方數(shù)據(jù)的入口寫(xiě)起來(lái)不復(fù)雜但有幾個(gè)安全性和業(yè)務(wù)性的問(wèn)題必須處理。RestController RequestMapping(/sms/callback) public class SmsCallbackController { PostMapping(/status) public MapString, Object receiveStatus(RequestBody MapString, Object body) { log.info(收到短信狀態(tài)回調(diào): {}, body); // 解析手機(jī)號(hào)、消息ID、狀態(tài)碼、狀態(tài)描述 String phone String.valueOf(body.get(phone_number)); String messageId String.valueOf(body.get(out_id)); String status String.valueOf(body.get(report_status)); String description String.valueOf(body.get(err_msg)); // 更新本地?cái)?shù)據(jù)庫(kù)中的發(fā)送記錄表 smsReportService.updateReport(messageId, status, description); // 返回success告訴服務(wù)商消息已收到否則服務(wù)商以為你沒(méi)收到會(huì)重復(fù)推送 return Map.of(code, 0, msg, success); } }回調(diào)處理的關(guān)鍵點(diǎn)有兩個(gè)一是必須給服務(wù)商返回明確的成功響應(yīng)否則它們會(huì)按自己的重試策略重復(fù)推送二是要做冪等處理因?yàn)橄⒖赡芡贫啻文愕臉I(yè)務(wù)表要通過(guò)messageId或out_id做唯一約束重復(fù)接收時(shí)只更新不重復(fù)寫(xiě)入。另外回調(diào)接口沒(méi)有用戶身份信息的只要URL被猜到任何人都可以往你接口上POST假數(shù)據(jù)。所以生產(chǎn)環(huán)境的回調(diào)地址建議加一個(gè)請(qǐng)求頭校驗(yàn)或簽名校驗(yàn)。阿里云的回調(diào)支持配置Token接收到請(qǐng)求時(shí)校驗(yàn)Header中的Token是否匹配這一步一定不要省。我的做法是自己封裝了一個(gè)SmsCallbackAuthFilter對(duì)所有/sms/callback/*的請(qǐng)求統(tǒng)一校驗(yàn)Token。提醒回調(diào)地址必須是公網(wǎng)可訪問(wèn)的HTTPS地址。本地調(diào)試時(shí)可以利用內(nèi)網(wǎng)穿透工具把回調(diào)地地址臨時(shí)暴露到公網(wǎng)但在生產(chǎn)環(huán)境千萬(wàn)不要圖方便繼續(xù)用這類工具直接配置公網(wǎng)域名加HTTPS才是正解。4.3 手機(jī)號(hào)加密傳輸與合規(guī)存儲(chǔ)短信接口對(duì)接的過(guò)程中手機(jī)號(hào)屬于用戶敏感信息。雖然這不是本篇重點(diǎn)但我強(qiáng)烈建議你在設(shè)計(jì)短信服務(wù)模塊時(shí)就考慮合規(guī)問(wèn)題。前后端交互時(shí)手機(jī)號(hào)字段最好用加密傳輸比如AES或國(guó)密SM4服務(wù)端落庫(kù)時(shí)做脫敏處理。日志打印時(shí)手機(jī)號(hào)只保留前三位和后四位。這個(gè)習(xí)慣越早養(yǎng)成越好等日后被合規(guī)審計(jì)要求整改的時(shí)候再來(lái)逐個(gè)字段checkout成本就高了。5. 生產(chǎn)環(huán)境不能回避的問(wèn)題限流、冪等、監(jiān)控和成本控制測(cè)試通過(guò)了代碼上線了短信功能看起來(lái)已經(jīng)跑起來(lái)了。但真實(shí)生產(chǎn)環(huán)境比測(cè)試環(huán)境復(fù)雜得多短信接口有幾個(gè)問(wèn)題如果不在上線前處理遲早會(huì)變成線上事故。這章我逐個(gè)說(shuō)。5.1 限流不只是防刷更是保護(hù)自己短信接口天然是攻擊者的目標(biāo)——只要能無(wú)限調(diào)用你的發(fā)送接口對(duì)方就能用你的短信通道轟炸任意手機(jī)號(hào)碼既刷你的余額也損害你域名的信譽(yù)。更可怕的是如果你的發(fā)送接口業(yè)務(wù)邏輯里還帶著用戶查詢或創(chuàng)建操作攻擊者甚至可以利用它做批量探測(cè)。所以網(wǎng)關(guān)層限流是必須的。如果你用Spring Cloud Gateway或Nginx可以直接對(duì)/sms/send這類路徑做QPS限制。如果是單機(jī)應(yīng)用也可以用Guava的RateLimiter或RedisLua實(shí)現(xiàn)分布式限流。我的實(shí)踐是兩層限流第一層是接口級(jí)QPS限制比如單機(jī)每秒最多200個(gè)請(qǐng)求超出直接拒絕第二層是業(yè)務(wù)級(jí)限制即每個(gè)手機(jī)號(hào)每天最多發(fā)10條驗(yàn)證碼每個(gè)IP每分鐘最多發(fā)5條。// 每天上限限制 String dailyKey sms:daily:limit: phone; Long count redisTemplate.opsForValue().increment(dailyKey); if (count ! null count 1) { redisTemplate.expire(dailyKey, Duration.ofDays(1)); } if (count 10) { throw new BizException(今日短信發(fā)送已達(dá)上限); }這個(gè)限流邏輯本身不會(huì)有太高性能消耗Redis的原子自增操作是常數(shù)復(fù)雜度。但要注意每次發(fā)送都做兩次Redis操作間隔限制和每日上限高峰期要觀察一下你Redis的QPS增長(zhǎng)情況如果成為瓶頸可以用本地緩存CaffeineRedis兩級(jí)方式優(yōu)化。5.2 發(fā)送記錄的持久化別等查不到日志才后悔短信發(fā)送記錄必須落庫(kù)。我維護(hù)過(guò)多個(gè)短信模塊最深的感觸是沒(méi)有發(fā)送記錄表出現(xiàn)問(wèn)題排查的成本會(huì)高到讓人抓狂。用戶投訴說(shuō)沒(méi)收到短信服務(wù)商說(shuō)已經(jīng)發(fā)出去了如果兩邊各執(zhí)一詞你手里沒(méi)有證據(jù)鏈根本無(wú)法定位問(wèn)題。CREATE TABLE sms_send_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, phone VARCHAR(20) NOT NULL COMMENT 接收手機(jī)號(hào), template_code VARCHAR(64) NOT NULL COMMENT 模板ID, template_param VARCHAR(500) COMMENT 模板參數(shù)JSON, biz_id VARCHAR(64) COMMENT 服務(wù)商返回的消息ID, status TINYINT NOT NULL DEFAULT 0 COMMENT 0-發(fā)送中 1-成功 2-失敗, err_code VARCHAR(64) COMMENT 錯(cuò)誤碼, err_msg VARCHAR(255) COMMENT 錯(cuò)誤描述, request_time DATETIME NOT NULL COMMENT 請(qǐng)求時(shí)間, report_time DATETIME COMMENT 回執(zhí)時(shí)間, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, INDEX idx_phone_time (phone, request_time) ) COMMENT 短信發(fā)送記錄表;記錄表的意義包含但不限于第一核對(duì)服務(wù)商賬單時(shí)用它做總量核對(duì)第二排查用戶投訴時(shí)查它判斷短信真實(shí)狀態(tài)第三統(tǒng)計(jì)到達(dá)率、發(fā)送成功率評(píng)估不同服務(wù)商的通道質(zhì)量。我在對(duì)接初期就設(shè)計(jì)了這張表后來(lái)服務(wù)商對(duì)賬和問(wèn)題排查都靠它。5.3 監(jiān)控指標(biāo)和異常告警短信模塊的監(jiān)控我建議重點(diǎn)關(guān)注四個(gè)指標(biāo)發(fā)送成功率、到達(dá)率、發(fā)送耗時(shí)、調(diào)用量。到達(dá)率依賴于回調(diào)的及時(shí)性如果你發(fā)現(xiàn)某個(gè)時(shí)段到達(dá)率低于正常值優(yōu)先懷疑服務(wù)商通道問(wèn)題及時(shí)切換備用通道。發(fā)送耗時(shí)如果從200毫秒漲到2秒大概率是SDK連接池或網(wǎng)絡(luò)問(wèn)題。我每次發(fā)布短信相關(guān)改動(dòng)后都會(huì)盯著這四個(gè)指標(biāo)看半小時(shí)再離開(kāi)。告警規(guī)則上成功率低于95%告警單日調(diào)用量環(huán)比上漲超過(guò)50%告警回執(zhí)超時(shí)超過(guò)10分鐘告警。告警通道可以用企業(yè)微信機(jī)器人或釘釘機(jī)器人把異常信息推送到群里這樣不用等用戶投訴就能第一時(shí)間感知。6. 回頭看這些坑我踩過(guò)希望你繞過(guò)最后分享幾個(gè)我在短信接口對(duì)接和線上運(yùn)維過(guò)程中踩過(guò)的坑每個(gè)都對(duì)應(yīng)一個(gè)真實(shí)的線上教訓(xùn)。第一模板參數(shù)必須嚴(yán)格按照模板定義傳。阿里云模板變量是通過(guò)JSON字符串傳遞的比如{code:123456}。如果你模板里定義的變量是${name}傳參時(shí)key就必須叫name大小寫(xiě)都敏感。我有一次把變量名寫(xiě)成Name結(jié)果發(fā)送報(bào)錯(cuò)isv.SMS_TEMPLATE_ILLEGAL排查了半天才發(fā)現(xiàn)是大小寫(xiě)問(wèn)題。第二別把endpoint配錯(cuò)了。新版SDK的endpoint應(yīng)該是dysmsapi.aliyuncs.com如果配成dysmsapi.aliyuncs.com.cn之類就會(huì)出現(xiàn)未知異常。這類配置項(xiàng)我一般直接抄官方文檔不要自己拼。第三Spring Boot項(xiàng)目如果同時(shí)引入了多個(gè)阿里云SDK要特別留意版本兼容問(wèn)題。舊版aliyun-java-sdk-core和新版dysmsapi20170525共用部分類名可能引發(fā)奇怪的NoSuchMethodError。解決方式是盡可能將阿里云所有SDK統(tǒng)一到最新的兼容版本或者在引入時(shí)排除沖突的傳遞依賴。第四異步發(fā)送的重試要設(shè)置最大次數(shù)避免服務(wù)商不可用時(shí)無(wú)休止重試導(dǎo)致線程池被打滿。我遇到過(guò)一次短信服務(wù)商大面積故障重試任務(wù)堆積排滿了隊(duì)列直接導(dǎo)致整個(gè)應(yīng)用響應(yīng)變慢。后來(lái)我加了熔斷邏輯當(dāng)連續(xù)失敗超過(guò)20次時(shí)暫停短信發(fā)送并開(kāi)啟降級(jí)開(kāi)關(guān)故障恢復(fù)后自動(dòng)放開(kāi)。根據(jù)我個(gè)人的實(shí)際操作經(jīng)驗(yàn)短信接口對(duì)接這件事本身不難真正拉開(kāi)差距的是對(duì)異常鏈路、數(shù)據(jù)閉環(huán)和成本控制的處理。你把這篇文章里的設(shè)計(jì)思路落地到項(xiàng)目里基本就能避免我踩過(guò)的那些坑。如果你正在做Spring Boot集成短信功能的方案設(shè)計(jì)希望這篇內(nèi)容能幫你把方案做得更完整。