有多久，沒有發過簡訊了？

一、背景簡介

在常規的分散式架構下，「消息中心」的服務里通常會集成「簡訊」的渠道，作為信息觸達的重要手段，其他常用的手段還包括：「某微」、「某釘」、「郵件」等方式；

對於《消息中心》的設計和實現來說，在前面已經詳細的總結過，本文重點來聊聊消息中心的簡訊渠道的方式；

簡訊在實現的邏輯上，也遵循消息中心的基礎設計，即消息生產之後，通過消息中心進行投遞和消費，屬於典型的生產消費模型；

二、渠道方對接

在大部分的系統中，簡訊功能的實現都依賴第三方的簡訊推送，之前總結過《三方對接》的經驗，這裡不再贅述；

但是與常規第三方對接不同的是，簡訊的渠道通常會對接多個，從而應對各種消息投遞的場景，比如常見的「驗證碼」場景，「通知提醒」場景，「營銷推廣」場景；

這裡需要考慮的核心因素有好幾個，比如成本問題，簡訊平臺的穩定性，時效性，觸達率，併發能力，需要進行不同場景的綜合考量；

驗證碼：該場景通常是用戶和產品的關鍵交互環節，十分依賴簡訊的時效性和穩定性，如果出問題直接影響用戶體驗；

通知提醒：該場景同樣與業務聯繫密切，但是相對來說對簡訊觸達的時效性依賴並不高，只要在一定的時間範圍內最終觸達用戶即可；

營銷推廣：該場景的數據量比較大，並且從實際效果來看，具有很大的不確定性，會對簡訊渠道的成本和併發能力重點考量；

三、簡訊渠道

1、流程設計

從整體上來看簡訊的實現流程，可以分為三段：「1」簡訊需求的業務場景，「2」消息中心的簡訊集成能力，「3」對接的第三方簡訊渠道；

需求場景：在產品體系中，需要用到簡訊的場景很多，不過最主要的還是對用戶方的信息觸達，比如身份驗證，通知，營銷等，其次則是對內的重要消息通知；

消息中心：提供消息發送的統一介面方法，不同業務場景下的消息提交到消息中心，進行統一維護管理，並根據消息的來源和去向，適配相應的推送邏輯，簡訊只是作為其中的一種方式；

渠道對接：根據具體的需求場景來定，如果只有驗證碼的對接需求，可以只集成一個渠道，或者從成本方面統籌考慮，對接多個第三方簡訊渠道，建議設計時考慮一定的可擴展；

2、核心邏輯

單從簡訊這種方式的管理來看，邏輯複雜度並不算很高，但是很依賴細節的處理，很多不註意的細微點都可能導致推送失敗的情況；

實際在整個邏輯中，除了「驗證碼」功能有時效性依賴之外，其他場景的簡訊觸達都可以選擇「MQ隊列」進行解耦，在消息中心的設計上，也具備很高的流程復用性，圖中只是重點描述簡訊場景；

3、使用場景

3.1 驗證碼

對於「簡訊」功能中的「驗證碼」場景來說，個人感覺在常規的應用中是最複雜的，這可能會涉及到「賬戶」和相關「業務」的集成問題；

【驗證碼獲取】

這個流程相對來說路徑還比較簡短，只要完成手機號的校驗後，按照簡訊推送邏輯正常執行即可；

這裡需要說明的是，為了確保系統的安全性，通常會設定驗證碼的時效性，並且只能使用一次，但是偶爾可能因為延時問題，引起用戶多次申請驗證碼，基於緩存可以很好的管理這種場景的數據結構；

【驗證碼消費】

驗證碼的使用是非常簡單的，現在很多產品在設計上，都弱化了登錄和註冊的概念，只要通過驗證碼機制，會預設的新建帳戶和執行相關業務流程；

無論是何種業務場景下的「驗證碼」依賴，在處理流程時都要先校驗其「驗證碼」的正確與否，才能判斷流程是否向下執行，在部分敏感的場景中，還會限制驗證碼的錯誤次數，防止出現賬戶安全問題；

3.2 簡訊觸達

無論是「通知提醒」還是「營銷推廣」，其本質上是追求信息的最終觸達即可，大部分簡訊運營商都可以提供這種能力，只是系統內部的處理方式有很大差異；

在部分業務流程中，需要向用戶投遞簡訊消息，在營銷推廣的需求中，更多的是批量發送簡訊，部分需求其內部邏輯上，還可能存在一個轉化率統計的問題，需要監控相關簡訊的交互狀態；

四、模型設計

由於簡訊是集成在消息中心的服務中，其相關的數據結構模型都是復用消息管理的，具體細節描述，參考《消息中心》的內容即可，此處不贅述；

從技術角度來看的話，涉及經典的生產消費模型，第三方平臺對接，任務和狀態機管理等，消息中心作為分散式架構的基礎服務，在設計上還要考慮一定的復用性。

五、參考源碼

編程文檔：
https://gitee.com/cicadasmile/butte-java-note

應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent