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

一、背景簡介

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

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

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

二、渠道方對接

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

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

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

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

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

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

三、簡訊渠道

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