我是3y，一年CRUD經(jīng)驗用十年的markdown程序員👨🏻?💻常年被譽為優(yōu)質八股文選手

austin項目實現(xiàn)的第一個渠道：：從發(fā)送短信開始

01、短信介紹

在項目介紹的時候，已經(jīng)定義了austin項目的核心功能：發(fā)送消息

我認為，短信是在一整個消息推送平臺里最重要的一個消息類型了（畢竟關聯(lián)了很多重要的業(yè)務場景），想想我們?nèi)粘Ｊ褂肁PP時的場景：

• 驗證碼：登錄注冊、支付等等重要場景
• 通知類：用戶訂單信息、重要信息通知用戶、重要信息通知商家等等場景
• 營銷類：運營在特定時間內(nèi)發(fā)送營銷短信，影響業(yè)務的KPI指標完成（不過這個相對就沒那么重要）
• …

（試想下，如果系統(tǒng)掛了10分鐘，會怎么樣）

發(fā)送短信在消息推送平臺里比較容易實現(xiàn)的一種消息類型了，我會在這篇文章中讓你體會發(fā)送消息如果要做得比較好也并沒有那么的簡單和容易，以及能夠體會到為什么我在介紹austin項目的時候需要引入那么多的中間件。

（一切從一條短信開始）

02、發(fā)送短信必要準備

隔著上次的系統(tǒng)架構圖也有好幾天了，先復習下我們austin系統(tǒng)的整個流程

由于是初步實現(xiàn)，所以我先開個接口直接調(diào)用austin-handler模塊，只要在austin-handler模塊下實現(xiàn)發(fā)送短信的邏輯就好了。

我們要發(fā)送短信，一般直接接入短信渠道商就好了。以我的理解，發(fā)短信的過程是這樣的：

正好前幾天在群里，有個兄弟的就是在公司做短信渠道商的相關業(yè)務的。他說接口有20W QPS并發(fā)量（之前在搞各種的中間件優(yōu)化避免消息的堆積），他進去了才知道發(fā)送一條短信原來是會經(jīng)過這么多的流程（我復制下他原話）

我現(xiàn)在才知道，原來一條短信發(fā)到我們手機，經(jīng)過了不知道多少流程，包括黑名單檢查風控檢查，關鍵字檢查，退訂檢查，模板檢查，客戶賬號檢查，路由網(wǎng)關檢查，通道檢查，狀態(tài)報告檢查，運營商檢查。。。。。。。

一般我們要去評估是否使用某短信渠道商來發(fā)送，考量的點有兩個：成本和成功率。這里應該還是比較好理解的，短信渠道商有很多，他們都需要賺錢，我們作為接入方需要省錢（那自然就有有價格的差異性）。如果某一個渠道商又便宜發(fā)送成功率又高，那當然用他作為主要渠道啊！

這次我選擇的是騰訊云作為austin項目下初步發(fā)送短信的渠道商。

我這次選擇的理由很簡單：我進去短信產(chǎn)品了以后，他免費給了我100條發(fā)送短信的體驗卡（應該是人人都有的？我不可能是天命之子吧）。

我發(fā)現(xiàn)有很多小伙伴在跟著我的步伐在做的，我肯定不能把自己的短信賬號和密碼直接公開給大家體驗的。所以到時候你們感興趣可以用自己的賬號體驗一波。

麻煩**@騰訊云給我打下廣告費。 @阿里云貌似有？（但入口太難找，罷了） @華為云**我還沒登錄體驗過，等等我！

想要發(fā)送一條短信又或是接入一個短信渠道商必不可少的兩個點：短信模板和短信簽名。看不懂？沒事，我以具體的一條測試短信為例：

有了短信簽名可以讓用戶知道這可能是誰發(fā)過來的短信，有了短信模板可以讓發(fā)送垃圾短信的概率大大減少。

有人可能就會問了：那我每發(fā)一條短信，都需要有對應模板的話，那我維護起來不就非常麻煩？這畢竟是一個推送平臺啊！每次有業(yè)務需要發(fā)送新的文案，還得去對應的渠道商后臺申請模板嗎？

本來我以為這是正常的，沒想到，如果你是公司的話，還能談的（🐶一般人我還不告訴他）。所以，可能會有通用短信模板的存在。

但不管怎么樣，短信渠道商還是會校驗各種邏輯（該驗證的還是會驗證，你亂發(fā)消息把你的賬號給限流和設置抽樣人工驗證文案，這樣就得不償失了）

03、功能實現(xiàn)

調(diào)用第三方API可能會有兩種選擇：HTTP調(diào)用和內(nèi)嵌SDK（如果平臺方有做SDK的話）。

我以前一般都是直接HTTP調(diào)用的，因為這樣我的代碼就不用內(nèi)嵌別人家的SDK了（內(nèi)嵌SDK意味著會引入其他依賴）。于是我就直接從他提供接入文檔入手，嘗試使用HTTP進行接入。

嗯，我花了兩天多，還沒接入成功。我直呼頂不住，再這樣下去，催更的人都要來我家敲門了！

騰訊云接口用HTTP驗簽也太太太復雜了吧！原來他的注不是在嚇唬我：

我搞了兩個晚上已經(jīng)心灰意冷了，只能妥協(xié)用他們提供的SDK了，再加上自動生成代碼，嘎嘎很快地就成功了（我好奇有沒有勇士曾經(jīng)按照最新的API文檔用HTTP接入過他們的接口）

具體的代碼我就不貼了，按照慣例大家在文末(閱讀原文)找到Gitee鏈接🔗看就好了。

跟著項目做的小伙伴，只要在配置文件改下賬號信息和調(diào)用下接口，就能收到自己的短信了。（問題應該不大，有問題來群里問就好了）

04、為什么austin是消息平臺

實現(xiàn)發(fā)送短信是一件很簡單的事（從它占文章篇幅即可推斷出），發(fā)送其他渠道的消息其實也很簡單。從本質上講，就是對接API調(diào)用發(fā)送接口進行發(fā)送。

作為一般項目，發(fā)完消息就沒有后續(xù)了，但如果作為一個「平臺」而言，這是遠遠不夠的。

4.1 調(diào)用發(fā)送短信接口后，如果用戶反饋收不到怎么辦？

我們只調(diào)用了發(fā)送短信的接口，沒有記錄接口的返回信息（也就沒有發(fā)送憑證），當別人找過來的時候，我們也無濟于事（我們什么都沒記錄，什么都不知道）。

解決方案：我們需要存儲把發(fā)送的記錄給存起來，也需要有接口把短信的回執(zhí)拉回來并存儲，并在推送后臺提供相關的頁面給予快速查詢。

4.2 某個短信渠道商掛了怎么辦？

別以為我們的依賴是阿里云、騰訊云或者華為云這種大公司，他們提供的產(chǎn)品不是萬無一失的，掛也是很正常的事。那如果我們只依賴一個短信渠道，它掛了，是不是相當于我們就掛了。

解決方案：短信需要接入多個渠道商，調(diào)用接口失敗需要繼續(xù)調(diào)用其他渠道商，支持動態(tài)分配渠道商的流量（一旦有提前預警，直接切換渠道商）

4.3 這個月短信花了多少錢，我怎么知道？

接入的短信后臺都有對應的統(tǒng)計，但我們量大的話是需要「對賬」，以我們的發(fā)送記錄與回執(zhí)統(tǒng)計跟短信的后臺進行統(tǒng)計。

畢竟都是錢啊，不能全部信他們的啊。我曾經(jīng)就有遇到過，對方的賬單跟我們自己統(tǒng)計的數(shù)量有比較大的出入，后來排查發(fā)現(xiàn)他們的統(tǒng)計是存在問題的。

解決方案：將短信的發(fā)送和回執(zhí)數(shù)據(jù)導入到Hive，每個月跑一次Hive腳本統(tǒng)計進行對賬

4.4 現(xiàn)在調(diào)用短信的量大嗎？

第三方接口一般都會有限流的，比如在騰訊云官網(wǎng)上看到對發(fā)送接口有3000QPS的限制。我們是需要知道現(xiàn)在各種類型的消息的發(fā)送情況是怎么樣的，是否有限流的操作。如果限流了，是不是可以告訴業(yè)務方可能是原因目前發(fā)送量過大導致觸發(fā)限流。

系統(tǒng)上有完備的監(jiān)控，你知道了各種的系統(tǒng)指標數(shù)據(jù)，自己才不會慌。（排查問題有監(jiān)控會很容易定位）

要是某一天有人跟你說你的系統(tǒng)掛了，你不會還傻乎乎地去服務器上看日志吧？打開監(jiān)控看下有沒有流量，流量正不正常不就一眼就能看到了嗎。

解決方案：監(jiān)控從接口調(diào)用到消息下發(fā)整個過程的數(shù)據(jù)（主要是接口QPS和下發(fā)人數(shù)）

4.5 業(yè)務方不小心連續(xù)發(fā)了兩次怎么辦？

業(yè)務方使用不當，不小心連續(xù)推送了兩次，如果沒有任何限制，那就真的下發(fā)了兩次。試想下，如果你點了下驗證碼，霎時間，收到了兩條一模一樣的短信，你是什么感受？

解決方案：作為平臺需要有這種兜底的功能（盡可能避免由于業(yè)務使用不恰當，導致出現(xiàn)事故）

4.6 這條短信誰發(fā)的啊？

客服反饋：用戶接收到了一條短信（用戶對具體短信的細節(jié)不理解）。客服看著短信也兩眼懵逼，公司那么大，不知道由哪個業(yè)務團隊下發(fā)出來的。現(xiàn)在只有短信的文案，怎么能快速找到下發(fā)短信的團隊呢。

我們需要讓所有經(jīng)過austin項目的消息都有一個「載體」（說白了就是模板），有了模板之后，業(yè)務方在接入的時候需要填寫各類的信息，有了這些信息再配合搜索引擎就可以快速定位出信息。

“溯源“在很多時候都很有用（比如：你提供了一個HTTP接口，如果沒對業(yè)務做任何的限制。或許有朝一日，你希望對該接口進行大改動，但你不知道現(xiàn)在有誰進行調(diào)用，就會很頭疼）

解決方案：給接入方套”模板“，有了模板才能溯源，才能做數(shù)據(jù)追蹤，模板是作為平臺的基石。（下一篇等我建表的時候，我會再來跟大家詳細說說對應的業(yè)務）

4.7 經(jīng)常要接入短信渠道怎么辦？

商務又找到了便宜的短信渠道了，接入一下看看效果吧？這可是實打實省錢的啊！每次寫一個類（接入短信就相當于寫一個類），我都要重啟發(fā)布上線嗎？這不靠譜吧？

解決方案：上規(guī)則引擎將業(yè)務代碼抽離，無須上下線即可實現(xiàn)功能。

05、總結

實現(xiàn)功能很簡單，但在實現(xiàn)功能的過程中代碼的健壯性、穩(wěn)定性以及靈活性如果你都考慮到了，那面試的過程中還怕什么？出去面試，就說我基于現(xiàn)有的場景引入了分布式配置中心，大大提高了工作效率。出去面試，就說我對整個系統(tǒng)進行完備的監(jiān)控和告警，在這個過程中線上無任何故障，平時遇到問題，我的解決思路是怎么樣的等等等。

這篇文章其實也相當于是“預告”，這些功能我后面都會一一進行實現(xiàn)（當然了，我的小目標也不僅僅上面所提到的如此）

開源項目Gitee鏈接：https://gitee.com/austin

開源項目GitHub鏈接：https://github.com/austin

總結

以上是生活随笔為你收集整理的【Java开源项目】消息推送平台发送一条短信的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。