我是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專案】 持續高強度更新中！求star！！原創不易！！求三連！！
Gitee連結：https://gitee.com/austin
GitHub連結：https://github.com/austin