我是3y，一年CRUD經驗用十年的markdown程序員👨🏻💻常年被譽爲優質八股文選手
austin項目實現的第一個渠道：：從發送短信開始
01、短信介紹
在項目介紹的時候，已經定義了austin項目的核心功能：發送消息
我認爲，短信是在一整個消息推送平臺裏最重要的一個消息類型了（畢竟關聯了很多重要的業務場景），想想我們日常使用APP時的場景：
- 驗證碼：登錄註冊、支付等等重要場景
- 通知類：用戶訂單信息、重要信息通知用戶、重要信息通知商家等等場景
- 營銷類：運營在特定時間內發送營銷短信，影響業務的KPI指標完成（不過這個相對就沒那麼重要）
- ...
（試想下，如果系統掛了10分鐘，會怎麼樣）
發送短信在消息推送平臺裏比較容易實現的一種消息類型了，我會在這篇文章中讓你體會發送消息如果要做得比較好也並沒有那麼的簡單和容易，以及能夠體會到爲什麼我在介紹austin項目的時候需要引入那麼多的中間件。
（一切從一條短信開始）
02、發送短信必要準備
隔着上次的系統架構圖也有好幾天了，先複習下我們austin系統的整個流程
由於是初步實現，所以我先開個接口直接調用austin-handler模塊，只要在austin-handler模塊下實現發送短信的邏輯就好了。
我們要發送短信，一般直接接入短信渠道商就好了。以我的理解，發短信的過程是這樣的：
正好前幾天在羣裏，有個兄弟的就是在公司做短信渠道商的相關業務的。他說接口有20W QPS併發量（之前在搞各種的中間件優化避免消息的堆積），他進去了才知道發送一條短信原來是會經過這麼多的流程（我複製下他原話）
我現在才知道，原來一條短信發到我們手機，經過了不知道多少流程，包括黑名單檢查風控檢查，關鍵字檢查，退訂檢查，模板檢查，客戶賬號檢查，路由網關檢查，通道檢查，狀態報告檢查，運營商檢查。。。。。。。
一般我們要去評估是否使用某短信渠道商來發送，考量的點有兩個：成本和成功率。這裏應該還是比較好理解的，短信渠道商有很多，他們都需要賺錢，我們作爲接入方需要省錢（那自然就有有價格的差異性）。如果某一個渠道商又便宜發送成功率又高，那當然用他作爲主要渠道啊！
這次我選擇的是騰訊雲作爲austin項目下初步發送短信的渠道商。
我這次選擇的理由很簡單：我進去短信產品了以後，他免費給了我100條發送短信的體驗卡（應該是人人都有的？我不可能是天命之子吧）。
我發現有很多小夥伴在跟着我的步伐在做的，我肯定不能把自己的短信賬號和密碼直接公開給大家體驗的。所以到時候你們感興趣可以用自己的賬號體驗一波。
麻煩@騰訊雲給我打下廣告費。@阿里雲貌似有？（但入口太難找，罷了）@華爲雲我還沒登錄體驗過，等等我！
想要發送一條短信又或是接入一個短信渠道商必不可少的兩個點：短信模板和短信簽名。看不懂？沒事，我以具體的一條測試短信爲例：
有了短信簽名可以讓用戶知道這可能是誰發過來的短信，有了短信模板可以讓發送垃圾短信的概率大大減少。
有人可能就會問了：那我每發一條短信，都需要有對應模板的話，那我維護起來不就非常麻煩？這畢竟是一個推送平臺啊！每次有業務需要發送新的文案，還得去對應的渠道商後臺申請模板嗎？
本來我以爲這是正常的，沒想到，如果你是公司的話，還能談的（🐶一般人我還不告訴他）。所以，可能會有通用短信模板的存在。
但不管怎麼樣，短信渠道商還是會校驗各種邏輯（該驗證的還是會驗證，你亂髮消息把你的賬號給限流和設置抽樣人工驗證文案，這樣就得不償失了）
03、功能實現
調用第三方API可能會有兩種選擇：HTTP調用和內嵌SDK（如果平臺方有做SDK的話）。
我以前一般都是直接HTTP調用的，因爲這樣我的代碼就不用內嵌別人家的SDK了（內嵌SDK意味着會引入其他依賴）。於是我就直接從他提供接入文檔入手，嘗試使用HTTP進行接入。
嗯，我花了兩天多，還沒接入成功。我直呼頂不住，再這樣下去，催更的人都要來我家敲門了！
騰訊雲接口用HTTP驗籤也太太太複雜了吧！原來他的注不是在嚇唬我：
我搞了兩個晚上已經心灰意冷了，只能妥協用他們提供的SDK了，再加上自動生成代碼，嘎嘎很快地就成功了（我好奇有沒有勇士曾經按照最新的API文檔用HTTP接入過他們的接口）
具體的代碼我就不貼了，按照慣例大家在文末(閱讀原文)找到Gitee鏈接🔗看就好了。
跟着項目做的小夥伴，只要在配置文件改下賬號信息和調用下接口，就能收到自己的短信了。（問題應該不大，有問題來羣裏問就好了）
04、爲什麼austin是消息平臺
實現發送短信是一件很簡單的事（從它佔文章篇幅即可推斷出），發送其他渠道的消息其實也很簡單。從本質上講，就是對接API調用發送接口進行發送。
作爲一般項目，發完消息就沒有後續了，但如果作爲一個「平臺」而言，這是遠遠不夠的。
4.1 調用發送短信接口後，如果用戶反饋收不到怎麼辦？
我們只調用了發送短信的接口，沒有記錄接口的返回信息（也就沒有發送憑證），當別人找過來的時候，我們也無濟於事（我們什麼都沒記錄，什麼都不知道）。
解決方案：我們需要存儲把發送的記錄給存起來，也需要有接口把短信的回執拉回來並存儲，並在推送後臺提供相關的頁面給予快速查詢。
4.2 某個短信渠道商掛了怎麼辦？
別以爲我們的依賴是阿里雲、騰訊雲或者華爲雲這種大公司，他們提供的產品不是萬無一失的，掛也是很正常的事。那如果我們只依賴一個短信渠道，它掛了，是不是相當於我們就掛了。
解決方案：短信需要接入多個渠道商，調用接口失敗需要繼續調用其他渠道商，支持動態分配渠道商的流量（一旦有提前預警，直接切換渠道商）
4.3 這個月短信花了多少錢，我怎麼知道？
接入的短信後臺都有對應的統計，但我們量大的話是需要「對賬」，以我們的發送記錄與回執統計跟短信的後臺進行統計。
畢竟都是錢啊，不能全部信他們的啊。我曾經就有遇到過，對方的賬單跟我們自己統計的數量有比較大的出入，後來排查發現他們的統計是存在問題的。
解決方案：將短信的發送和回執數據導入到Hive，每個月跑一次Hive腳本統計進行對賬
4.4 現在調用短信的量大嗎？
第三方接口一般都會有限流的，比如在騰訊雲官網上看到對發送接口有3000QPS的限制。我們是需要知道現在各種類型的消息的發送情況是怎麼樣的，是否有限流的操作。如果限流了，是不是可以告訴業務方可能是原因目前發送量過大導致觸發限流。
系統上有完備的監控，你知道了各種的系統指標數據，自己纔不會慌。（排查問題有監控會很容易定位）
要是某一天有人跟你說你的系統掛了，你不會還傻乎乎地去服務器上看日誌吧？打開監控看下有沒有流量，流量正不正常不就一眼就能看到了嗎。
解決方案：監控從接口調用到消息下發整個過程的數據（主要是接口QPS和下發人數）
4.5 業務方不小心連續發了兩次怎麼辦？
業務方使用不當，不小心連續推送了兩次，如果沒有任何限制，那就真的下發了兩次。試想下，如果你點了下驗證碼，霎時間，收到了兩條一模一樣的短信，你是什麼感受？
解決方案：作爲平臺需要有這種兜底的功能（儘可能避免由於業務使用不恰當，導致出現事故）
4.6 這條短信誰發的啊？
客服反饋：用戶接收到了一條短信（用戶對具體短信的細節不理解）。客服看着短信也兩眼懵逼，公司那麼大，不知道由哪個業務團隊下發出來的。現在只有短信的文案，怎麼能快速找到下發短信的團隊呢。
我們需要讓所有經過austin項目的消息都有一個「載體」（說白了就是模板），有了模板之後，業務方在接入的時候需要填寫各類的信息，有了這些信息再配合搜索引擎就可以快速定位出信息。
"溯源"在很多時候都很有用（比如：你提供了一個HTTP接口，如果沒對業務做任何的限制。或許有朝一日，你希望對該接口進行大改動，但你不知道現在有誰進行調用，就會很頭疼）
解決方案：給接入方套”模板“，有了模板才能溯源，才能做數據追蹤，模板是作爲平臺的基石。（下一篇等我建表的時候，我會再來跟大家詳細說說對應的業務）
4.7 經常要接入短信渠道怎麼辦？
商務又找到了便宜的短信渠道了，接入一下看看效果吧？這可是實打實省錢的啊！每次寫一個類（接入短信就相當於寫一個類），我都要重啓發布上線嗎？這不靠譜吧？
解決方案：上規則引擎將業務代碼抽離，無須上下線即可實現功能。
05、總結
實現功能很簡單，但在實現功能的過程中代碼的健壯性、穩定性以及靈活性如果你都考慮到了，那面試的過程中還怕什麼？出去面試，就說我基於現有的場景引入了分佈式配置中心，大大提高了工作效率。出去面試，就說我對整個系統進行完備的監控和告警，在這個過程中線上無任何故障，平時遇到問題，我的解決思路是怎麼樣的等等等。
這篇文章其實也相當於是“預告”，這些功能我後面都會一一進行實現（當然了，我的小目標也不僅僅上面所提到的如此）
歡迎關注我的微信公衆號【Java3y】來聊聊Java面試，對線面試官系列持續更新中！
【對線面試官+從零編寫Java項目】 持續高強度更新中！求star！！原創不易！！求三連！！
Gitee鏈接：https://gitee.com/austin
GitHub鏈接：https://github.com/austin