從技術角度來看的話，涉及經典的生產消費模型，第三方平臺對接，任務和狀態機管理等，消息中心作為分布式架構的基礎服務，在設計上還要考慮一定的復用性。
一、背景簡介
在常規的分布式架構下，「消息中心」的服務里通常會集成「短信」的渠道，作為信息觸達的重要手段，其他常用的手段還包括：「某微」、「某釘」、「郵件」等方式；
對于《消息中心》的設計和實現來說，在前面已經詳細的總結過，本文重點來聊聊消息中心的短信渠道的方式；
短信在實現的邏輯上，也遵循消息中心的基礎設計，即消息生產之后，通過消息中心進行投遞和消費，屬于典型的生產消費模型；
二、渠道方對接
在大部分的系統中，短信功能的實現都依賴第三方的短信推送，之前總結過《三方對接》的經驗，這里不再贅述；
但是與常規第三方對接不同的是，短信的渠道通常會對接多個，從而應對各種消息投遞的場景，比如常見的「驗證碼」場景，「通知提醒」場景，「營銷推廣」場景；
這里需要考慮的核心因素有好幾個，比如成本問題，短信平臺的穩定性，時效性，觸達率，并發能力，需要進行不同場景的綜合考量；
驗證碼：該場景通常是用戶和產品的關鍵交互環節，十分依賴短信的時效性和穩定性，如果出問題直接影響用戶體驗；
通知提醒：該場景同樣與業務聯系密切，但是相對來說對短信觸達的時效性依賴并不高，只要在一定的時間范圍內最終觸達用戶即可；
營銷推廣：該場景的數據量比較大，并且從實際效果來看，具有很大的不確定性，會對短信渠道的成本和并發能力重點考量；
三、短信渠道
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
