在信息化時(shí)代，短信作為最基本的通信方式，在各種業(yè)務(wù)中都扮演著重要角色。但是，隨著業(yè)務(wù)量的增長和用戶對(duì)服務(wù)質(zhì)量要求的提高，短信平臺(tái)的高可用性成為了我們面臨的一個(gè)重大挑戰(zhàn)。接下來的分享，將帶領(lǐng)大家走進(jìn)我們?cè)趯ふ叶绦牌脚_(tái)高可用解決方案的探索之路。

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

之家短信平臺(tái)的主要特點(diǎn)包括：

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

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

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

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

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

2.0升級(jí)的主要解決的問題：

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

 隨著業(yè)務(wù)的發(fā)展和對(duì)大型活動(dòng)的支持，面對(duì)瞬時(shí)大量短信發(fā)送場(chǎng)景（百萬QPS發(fā)送請(qǐng)求），以往的單一架構(gòu)支撐起來捉襟見肘，于是開啟了短信平臺(tái)的高可用探索實(shí)踐之路。

分析原有短信架構(gòu)，找出性能瓶頸

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

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

三個(gè)服務(wù)功能職責(zé)劃分

Api服務(wù)：

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

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

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

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

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

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

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

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

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

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

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

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

等等

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

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

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