在信息化時代，短信作為最基本的通信方式，在各種業(yè)務中都扮演著重要角色。但是，隨著業(yè)務量的增長和用戶對服務質(zhì)量要求的提高，短信平臺的高可用性成為了我們面臨的一個重大挑戰(zhàn)。接下來的分享，將帶領大家走進我們在尋找短信平臺高可用解決方案的探索之路。

之家短信平臺是一個提供企業(yè)級短信服務的全面解決方案。目前支持短信發(fā)送、彩信發(fā)送、提供一套完整安全策略的驗證碼發(fā)送服務，該平臺以高可用性、穩(wěn)定性和安全性為首要目標，為之家各業(yè)務線提供可靠的短信發(fā)送和接收功能。

之家短信平臺的主要特點包括：

• 高可用性：通過冗余硬件、軟件和網(wǎng)絡連接來保證服務的持續(xù)可用。系統(tǒng)采用分布式架構設計，實現(xiàn)了高并發(fā)、快速響應的通信能力。

• 限頻限流：使用先進的算法進行流量控制，確保系統(tǒng)在面臨大量請求時不會過載，保障短信服務質(zhì)量。

• 故障自動切換：一旦檢測到系統(tǒng)出現(xiàn)故障，平臺會自動將流量切換到異地健康的服務集群上，從而減少對業(yè)務的影響。

• 故障監(jiān)控報警：平臺設有完善的監(jiān)控系統(tǒng)，可以實時監(jiān)測系統(tǒng)狀態(tài)，并在發(fā)現(xiàn)異常時立即發(fā)出告警。

隨著時間的推移，當初.Net版本程序維護成本逐漸增加，以及運營人員對管理功能的強烈需求，就產(chǎn)生的之家短信的2.0升級。

2.0升級的主要解決的問題：

• 使用Java語言將原有功能遷移到Java平臺上，便于日后維護。
• 管理端頁面重構，增加日常查詢統(tǒng)計
• 數(shù)據(jù)脫敏等一系列迭代升級。

 隨著業(yè)務的發(fā)展和對大型活動的支持，面對瞬時大量短信發(fā)送場景（百萬QPS發(fā)送請求），以往的單一架構支撐起來捉襟見肘，于是開啟了短信平臺的高可用探索實踐之路。

分析原有短信架構，找出性能瓶頸

• 手機號驗證、路由分配、策略等配置數(shù)據(jù)直接讀庫。
• 接口接收到發(fā)送短信請求后同步調(diào)用三方短信通道商，如遇網(wǎng)絡卡頓或三方服務不穩(wěn)定就會出現(xiàn)接口響應超時。
• 信息同步保存到數(shù)據(jù)庫，如果遇到網(wǎng)絡波動或數(shù)據(jù)庫繁忙的情況下會出現(xiàn)接口響應卡頓。
• 短信發(fā)送是異步請求，并非同步發(fā)送，流程如下圖：

重構思路：基于上述3個問題點和1個短信發(fā)送特性，將API接入校驗、調(diào)用三方、保存數(shù)據(jù)庫三部分進行解耦，每部分是一個服務，通過kafka進行削峰解耦，解耦后的程序為無狀態(tài)服務，理論上可以做到無限橫向擴展。

三個服務功能職責劃分

Api服務：

• 負責基本數(shù)據(jù)校驗，包括手機號合法性、黑白名單、路由通道等，所涉及到的配置信息全部從緩存中讀取，不再依賴數(shù)據(jù)庫，合規(guī)數(shù)據(jù)加密后發(fā)送到kafka。
•  接收狀態(tài)報告回執(zhí)信息
• 接收用戶回復的短信內(nèi)容

分發(fā)服務：負責消費 “api服務” 產(chǎn)生的合規(guī)數(shù)據(jù)，將調(diào)用三方發(fā)送結果加密后發(fā)送到kafka。

落庫服務：負責消費 “分發(fā)服務” 產(chǎn)生的數(shù)據(jù)，將發(fā)送結果保存到數(shù)據(jù)庫。

按照上述思路3.0很快落地了，運行速度相比2.0的時候邁進了一大步，可以支撐高達百萬QPS每秒，拆分開的三個服務每個服務是高可用的，每個服務依賴的中間件是高可用的，看起來萬無一失了，但是存在一個薄弱環(huán)節(jié)，如果三個服務所在的機房出現(xiàn)了故障，例如機房網(wǎng)線斷了，那么整個短信平臺就會失聯(lián)。

經(jīng)過調(diào)研，4層AnyCast是一種網(wǎng)絡尋址和路由方法，它可以將數(shù)據(jù)流重定向到最近、最佳或某特定的節(jié)點。因此，當A機房出現(xiàn)故障時，系統(tǒng)會憑借4層AnyCast的特性，自動選擇并切換到功能正常的B機房，從而故障自動轉移，且整個過程是自動切換，沒有人工依賴大大縮短了故障響應時間。

于是將完整的短信服務在A機房和B機房分別部署一份，AB兩個機房所涉及到的中間件完全獨立。但是存在一個問題，數(shù)據(jù)庫數(shù)據(jù)不能分開，跟DBA商討后決定，數(shù)據(jù)層面采用TiDB互為主從的方式實現(xiàn)，當A機房失聯(lián)后無需DBA干預，數(shù)據(jù)可以實時寫入B機房，AB機房數(shù)據(jù)實時同步。

架構優(yōu)點：避免因網(wǎng)絡故障導致A機房整體失聯(lián)。

架構缺點：AB機房平時只有一個對外提供服務，另外一個處于備用狀態(tài)，造成了資源的浪費，之所以不能同時對外提供服務的原因是，底層TiDB互為主從的實現(xiàn)方式，如果AB機房同時做讀寫操作會影響兩個數(shù)據(jù)庫的同步機制。

狀態(tài)報告主要作用是能夠了解短信送達情況和月底結算，由于狀態(tài)報告涉及到網(wǎng)絡調(diào)用和更新操作，大批量短信發(fā)送場景下，對于網(wǎng)絡和數(shù)據(jù)庫都有一定壓力都非常大，所以在活動當天選擇服務降級，等活動結束后選擇業(yè)務量較少的時間點回推短信狀態(tài)報告。

結合以上五點優(yōu)化，短信平臺經(jīng)歷了5屆之車之家818全球購車節(jié)的檢驗，峰值可以滿足百萬QPS無延遲下發(fā)場景需求。

架構再完美，也避免不了會出現(xiàn)故障，那么第一時間發(fā)出告警信息就顯得彌足珍貴，短信本身作為一個消息發(fā)送方，那如何保證他本身出現(xiàn)問題還能發(fā)出消息告警呢？大家想象一下以下場景

• 短信服務本身異常了
• 短信服務依賴的中間件故障了，Redis、TiDB、kafka
• 短信所處的1個機房故障了
• 短信所處的2個機房都故障了
• 短信下發(fā)通道商正常，但通道商調(diào)用三大運營商有問題
• 短信下發(fā)通道商失敗，網(wǎng)絡超時、DNS解析失敗等錯誤
• 短信回調(diào)之家業(yè)務方故障了，502、404、500等錯誤
• 上行短信通道商配置錯誤導致數(shù)據(jù)回傳有問題
• 狀態(tài)報告非約定狀態(tài)碼
• 配置文件修改錯誤導致短信下發(fā)失敗

等等

以上部分故障可以通過短信系統(tǒng)自身發(fā)出報警，但是有一些故障需要依賴三方才能夠實現(xiàn)消息的傳遞。短信平臺結合鷹眼日志、真機短信發(fā)送與接收、運營商實時監(jiān)控反饋、通道商客服24小時值守等外部系統(tǒng)進行監(jiān)察，消息接收方式包括短信、釘釘、微信、電話，設置多個報警接收人，避免單一報警系統(tǒng)出現(xiàn)問題，導致報警內(nèi)容無法觸達短信平臺接收人員。

此外，我們特設每日成功率告警和主力通道無短信提交告警等安全告警機制，使我們可以快速發(fā)現(xiàn)并應對各類風險，保證短信從發(fā)送到接收的全過程都在我們的監(jiān)控范圍內(nèi)。短信平臺擁有健全的短信故障監(jiān)控體系，我們以全面且精細化的監(jiān)察機制，確保短信服務的穩(wěn)定運行。體系涵蓋短信下發(fā)、狀態(tài)報告回執(zhí)、上行短信異常、中間件報錯等8大類17個重要的監(jiān)控細節(jié)，可以及時檢測并處理可能出現(xiàn)的問題。

短信平臺的高可用性涉及多個方面，包括異地多活架構、負載均衡技術、限頻限流、故障自動恢復機制、數(shù)據(jù)冗余和備份等策略，可以有效提升系統(tǒng)的穩(wěn)定性和可靠性，確保信息的及時傳遞和保障大型活動的順利進行。在故障發(fā)生時和發(fā)生后有相應監(jiān)控報警實時跟進，增加日常巡檢機制防范風險發(fā)生，只有持續(xù)探索和優(yōu)化，不斷提升系統(tǒng)的穩(wěn)定性和可靠性，才能在競爭激烈的市場中脫穎而出，為用戶提供卓越的體驗。