我在項目寫了個自定義注解
我是3y，一年CRUD經(jīng)驗用十年的markdown程序員???????常年被譽為職業(yè)八股文選手
今天繼續(xù)更新Austin，我發(fā)現(xiàn)很多同學(xué)在嘗試使用Austin的時候，總會把短信渠道放在第一個測試的渠道里。既然如此，我當然要把短信的代碼寫得更加符合線上生產(chǎn)環(huán)境的咯，代碼已經(jīng)push在遠程倉庫了，下面來講講上周我做了什么。
先鋪墊些背景，再來看看代碼。
在之前的版本，我們已經(jīng)完成了對短信的下發(fā)，下發(fā)的記錄存儲在MySQL數(shù)據(jù)庫里了
但是，數(shù)據(jù)庫里只有下發(fā)的記錄，并沒有用戶是否真正收到短信的憑證。所以Austin需要有接口把短信的回執(zhí)拉回來并存儲，并在推送后臺管理系統(tǒng)提供相關(guān)的頁面給予快速查詢。
別以為我們的依賴是阿里云、騰訊云或者華為云這種大公司，他們提供的產(chǎn)品不是萬無一失的，掛也是很正常的事。那如果我們只依賴一個短信渠道，它掛了，是不是相當于我們就掛了。
解決方案：短信需要接入多個渠道商，調(diào)用接口失敗需要繼續(xù)調(diào)用其他渠道商，支持動態(tài)分配渠道商的流量（一旦有提前預(yù)警，直接切換渠道商）
所以，我在上周實現(xiàn)了這兩個問題：
1、短信渠道的回執(zhí)信息拉回，在后臺給到相應(yīng)的頁面讓業(yè)務(wù)方自行查詢短信下發(fā)情況
2、多接入一個短信渠道，通過分布式配置中心（Apollo）做動態(tài)流量配置
01、動態(tài)流量配置
先看下我的入口代碼吧：com.java3y.austin.handler.handler.impl.SmsHandler#handler
從發(fā)送短信的章節(jié)里我提到過，我們一般發(fā)送短信是經(jīng)過各種廠商的"網(wǎng)關(guān)"，再由廠商去調(diào)用各大運營商下發(fā)的。我們拿到的回執(zhí)同樣也是運營商給廠商返回，然后我們再去拉取的。
絕大多數(shù)情況下，在我們一般都是通過回執(zhí)去排查用戶為什么收不到短信（一般都有可能是用戶側(cè)拉黑了某賬號、轉(zhuǎn)網(wǎng)存在問題、發(fā)送賬號存在問題等）。很少會懷疑騰訊云/阿里云/華為云等眾多短信廠商提供方的接口掛了，導(dǎo)致下發(fā)失敗了。
而這個是存在的，畢竟只要是接口就可能會出問題，所以我們在代碼里是需要做容錯的（有一個短信渠道在調(diào)用時就失敗了，應(yīng)該要嘗試換另一個短信渠道下發(fā)）。
當我們拉取回執(zhí)的時候，發(fā)現(xiàn)某個渠道的回執(zhí)異常地多，也應(yīng)該要留意是不是廠商渠道出了問題，及時切換短信的流量配置。好嘞，講完了背景了以后，再來看看代碼的細節(jié)。
之前我在項目里都沒怎么寫過自定義注解，正好遇到了比較合適的機會，來一個耍耍。我的想法是短信渠道會有很多，所以我會涉及一個短信的接口
而因為我們需要做流量配置，所以需要將短信渠道管理起來，于是會有SmsScriptHolder這個角色（實際上它就是一個Map）
那我怎么把短信渠道塞進這個Map里邊呢？搞個自定義注解就比較方便了。
那這個注解什么時候被解析加入到SmsScriptHolder這個Map里邊呢？那肯定是這個短信渠道初始化的時候嘛，所以我會有BaseSmsScript
這種寫法還是挺好玩的，感興趣的可以對著這種思路看自己有沒有類似的場景，改改優(yōu)化優(yōu)化。
02、回執(zhí)憑證拉回，頁面展示
由于這塊內(nèi)容比較簡單，我就不過多做介紹了，我就直接給出代碼入口吧
拉取回執(zhí)信息的代碼：com.java3y.austin.handler.receipt.SmsReceipt
消息推送后臺獲取短信記錄信息的接口代碼：com.java3y.austin.web.service.impl.DataServiceImpl#getTraceSmsInfo
頁面效果展示：
最近我開通了會員服務(wù)，感興趣的可戳：我開通了付費渠道
目前還有我的個人微信還有少量名額可拉進austin項目交流群，想進來的添加我下方的二維碼，備注【項目】即可，拒絕內(nèi)鬼?????♀?