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

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

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

• 高可用性：通過冗余硬件、軟件和網絡連接來保證服務的持續可用。系統采用分布式架構設計，實現了高并發、快速響應的通信能力。

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

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

• 故障監控報警：平臺設有完善的監控系統，可以實時監測系統狀態，并在發現異常時立即發出告警。

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

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

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

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

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

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

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

三個服務功能職責劃分

Api服務：

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

分發服務：負責消費 “api服務” 產生的合規數據，將調用三方發送結果加密后發送到kafka。

落庫服務：負責消費 “分發服務” 產生的數據，將發送結果保存到數據庫。

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

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

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

架構優點：避免因網絡故障導致A機房整體失聯。

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

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

結合以上五點優化，短信平臺經歷了5屆之車之家818全球購車節的檢驗，峰值可以滿足百萬QPS無延遲下發場景需求。

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

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

等等

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

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

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