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

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

之家(jia)短(duan)信(xin)平臺的主要特點包括：

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

• 限頻限流：使用先進(jin)的(de)算法進(jin)行流量(liang)控制，確保系(xi)統(tong)在面臨大(da)量(liang)請求時不會(hui)過載，保障(zhang)短信服務(wu)質量(liang)。

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

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

隨著(zhu)時間的(de)推移，當(dang)初.Net版本(ben)程序維護成本(ben)逐漸增加，以及(ji)運(yun)營人員對(dui)管(guan)理功(gong)能(neng)的(de)強烈需求，就產生的(de)之家短信(xin)的(de)2.0升級(ji)。

2.0升(sheng)級的(de)主要解(jie)決的(de)問題：

• 使用Java語言(yan)將原有功能遷移到(dao)Java平臺上，便(bian)于日(ri)后維護。
• 管(guan)理端頁面(mian)重構，增(zeng)加(jia)日常查(cha)詢(xun)統計
• 數據脫敏(min)等一系列(lie)迭(die)代升級。

 隨著業(ye)務(wu)的(de)發(fa)(fa)展和對(dui)大型(xing)活動的(de)支持，面對(dui)瞬(shun)時(shi)大量短(duan)信(xin)發(fa)(fa)送場(chang)景（百萬QPS發(fa)(fa)送請求(qiu)），以往(wang)的(de)單一架構支撐起來捉襟見肘，于是開(kai)啟了(le)短(duan)信(xin)平臺(tai)的(de)高可(ke)用探(tan)索實踐之路。

分析原(yuan)有短信架構，找(zhao)出(chu)性能瓶頸

• 手機(ji)號驗(yan)證、路(lu)由分(fen)配(pei)(pei)、策略等配(pei)(pei)置(zhi)數據直接讀(du)庫。
• 接(jie)口接(jie)收到發送短信(xin)請(qing)求后同步調用三(san)方短信(xin)通道(dao)商，如遇網絡卡頓或三(san)方服務不(bu)穩(wen)定就會(hui)出現(xian)接(jie)口響應(ying)超時。
• 信息同步保存到數據庫(ku)，如果遇到網(wang)絡波動或(huo)數據庫(ku)繁忙(mang)的情(qing)況下會出現接口響應(ying)卡(ka)頓(dun)。
• 短信發(fa)送是異(yi)步(bu)(bu)請求，并非同步(bu)(bu)發(fa)送，流程(cheng)如下(xia)圖：

重構思(si)路：基于上(shang)述3個問題點和(he)1個短(duan)信發送特性，將API接(jie)入校驗(yan)、調用三方、保存數據庫(ku)三部分進行(xing)解(jie)耦(ou)，每部分是一個服(fu)務，通過(guo)kafka進行(xing)削(xue)峰解(jie)耦(ou)，解(jie)耦(ou)后(hou)的程(cheng)序(xu)為(wei)無狀態服(fu)務，理論(lun)上(shang)可以(yi)做到無限(xian)橫向(xiang)擴展。

三(san)個服(fu)務功能職責劃分

Api服務(wu)：

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

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

落庫服務(wu)：負責消(xiao)費 “分發(fa)服務(wu)” 產生(sheng)的數據，將發(fa)送結果保存到(dao)數據庫。

按照上述思(si)路3.0很快落(luo)地了(le)(le)，運行(xing)速(su)度(du)相比2.0的時候邁(mai)進了(le)(le)一(yi)大步，可(ke)以(yi)支撐(cheng)高(gao)(gao)達百(bai)萬(wan)QPS每(mei)(mei)秒，拆(chai)分開的三個服(fu)務每(mei)(mei)個服(fu)務是(shi)高(gao)(gao)可(ke)用(yong)的，每(mei)(mei)個服(fu)務依賴的中間件是(shi)高(gao)(gao)可(ke)用(yong)的，看起來萬(wan)無一(yi)失(shi)了(le)(le)，但是(shi)存在一(yi)個薄弱環(huan)節，如果三個服(fu)務所在的機(ji)房出現了(le)(le)故障，例如機(ji)房網線斷了(le)(le)，那么整個短(duan)信平(ping)臺就會失(shi)聯。

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

于是將(jiang)完(wan)(wan)整(zheng)的短信(xin)服務在(zai)(zai)A機房(fang)(fang)和B機房(fang)(fang)分別(bie)部署一份(fen)，AB兩個機房(fang)(fang)所涉及(ji)到的中(zhong)間件完(wan)(wan)全獨(du)立。但是存在(zai)(zai)一個問題，數(shu)(shu)據庫(ku)數(shu)(shu)據不能分開，跟DBA商(shang)討后決定，數(shu)(shu)據層面采用(yong)TiDB互為主從的方式(shi)實現，當A機房(fang)(fang)失聯后無需DBA干(gan)預，數(shu)(shu)據可(ke)以(yi)實時寫入(ru)B機房(fang)(fang)，AB機房(fang)(fang)數(shu)(shu)據實時同(tong)步。

架構優點：避(bi)免因網(wang)絡故(gu)障導(dao)致A機房(fang)整體失聯。

架構(gou)缺點：AB機房平(ping)時只(zhi)有一個(ge)對外提供服務，另外一個(ge)處(chu)于(yu)備用(yong)狀(zhuang)態(tai)，造成了資(zi)源的(de)浪(lang)費，之所以(yi)不能同(tong)時對外提供服務的(de)原因是，底層TiDB互為主從的(de)實現方(fang)式，如果AB機房同(tong)時做讀(du)寫操作(zuo)會影響(xiang)兩個(ge)數據庫(ku)的(de)同(tong)步(bu)機制。

狀(zhuang)態(tai)報(bao)告主要作(zuo)用是能夠了解短信(xin)送達(da)情(qing)況和(he)(he)月底(di)結算，由于狀(zhuang)態(tai)報(bao)告涉及到網絡調用和(he)(he)更新(xin)操作(zuo)，大批量短信(xin)發送場景(jing)下(xia)，對于網絡和(he)(he)數據庫都有一(yi)定壓力都非常大，所以在活動當天選擇服務(wu)降級(ji)，等(deng)活動結束(shu)后(hou)選擇業(ye)務(wu)量較少的時(shi)間(jian)點回(hui)推短信(xin)狀(zhuang)態(tai)報(bao)告。

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

架構(gou)再(zai)完美，也避免不了(le)會出(chu)現故障，那么第(di)一時(shi)間(jian)發(fa)出(chu)告警信息(xi)就顯得(de)彌足珍貴，短信本身作為一個消息(xi)發(fa)送方，那如何(he)保(bao)證他本身出(chu)現問題還能發(fa)出(chu)消息(xi)告警呢？大家(jia)想(xiang)象一下以下場景

• 短信服(fu)務本身異常了
• 短信服(fu)務(wu)依(yi)賴的中間(jian)件故障了，Redis、TiDB、kafka
• 短信所處的1個機房故(gu)障(zhang)了
• 短(duan)信所處的(de)2個機(ji)房都故障了
• 短信(xin)下發通(tong)道商正常，但通(tong)道商調(diao)用三大運營商有問(wen)題
• 短信下(xia)發通道(dao)商(shang)失敗，網(wang)絡超時(shi)、DNS解析失敗等(deng)錯誤
• 短(duan)信(xin)回調之家業務(wu)方故障了，502、404、500等錯誤
• 上行短信通道商配置錯誤(wu)導(dao)致(zhi)數據回傳有問題
• 狀態(tai)(tai)報告非約(yue)定狀態(tai)(tai)碼
• 配置文件修改(gai)錯誤導致短信下發失(shi)敗

等等

以上部分故障可以通過短(duan)信(xin)系(xi)(xi)統自(zi)身發出報警(jing)，但是有一(yi)些故障需要依賴三(san)方才(cai)能夠(gou)實(shi)現消(xiao)息的(de)傳遞。短(duan)信(xin)平臺結(jie)合鷹眼日志(zhi)、真(zhen)機短(duan)信(xin)發送與(yu)接(jie)(jie)收(shou)(shou)(shou)、運營(ying)商實(shi)時監控反(fan)饋(kui)、通道(dao)商客服(fu)24小時值守等外部系(xi)(xi)統進行(xing)監察(cha)，消(xiao)息接(jie)(jie)收(shou)(shou)(shou)方式(shi)包括短(duan)信(xin)、釘釘、微信(xin)、電話，設(she)置(zhi)多(duo)個(ge)報警(jing)接(jie)(jie)收(shou)(shou)(shou)人，避免單一(yi)報警(jing)系(xi)(xi)統出現問題，導致(zhi)報警(jing)內容無法觸達短(duan)信(xin)平臺接(jie)(jie)收(shou)(shou)(shou)人員。

此外，我(wo)(wo)們(men)特設每日成功率告(gao)警和(he)主力通(tong)道(dao)無(wu)短(duan)(duan)信(xin)(xin)(xin)提交(jiao)告(gao)警等安(an)全告(gao)警機制，使我(wo)(wo)們(men)可(ke)以快(kuai)速發現并(bing)應對各(ge)類(lei)風險，保(bao)證短(duan)(duan)信(xin)(xin)(xin)從發送到(dao)接收的(de)全過程都(dou)在我(wo)(wo)們(men)的(de)監控范(fan)圍內。短(duan)(duan)信(xin)(xin)(xin)平臺擁有(you)健(jian)全的(de)短(duan)(duan)信(xin)(xin)(xin)故障(zhang)監控體系，我(wo)(wo)們(men)以全面且精細(xi)化(hua)的(de)監察機制，確保(bao)短(duan)(duan)信(xin)(xin)(xin)服(fu)務的(de)穩(wen)定(ding)運行(xing)(xing)。體系涵蓋(gai)短(duan)(duan)信(xin)(xin)(xin)下發、狀(zhuang)態報告(gao)回執、上行(xing)(xing)短(duan)(duan)信(xin)(xin)(xin)異常、中(zhong)間件報錯(cuo)等8大類(lei)17個重(zhong)要(yao)的(de)監控細(xi)節(jie)，可(ke)以及時(shi)檢(jian)測并(bing)處理可(ke)能出(chu)現的(de)問題。

短信(xin)平臺的(de)(de)(de)高可(ke)用性(xing)涉(she)及(ji)多(duo)個方面，包括異(yi)地多(duo)活(huo)架構、負載均衡技(ji)術(shu)、限頻限流、故障(zhang)自動恢(hui)復機(ji)制(zhi)、數據(ju)冗余和(he)備(bei)份(fen)等(deng)策略(lve)，可(ke)以有效(xiao)提升(sheng)系統(tong)(tong)的(de)(de)(de)穩定性(xing)和(he)可(ke)靠性(xing)，確(que)保信(xin)息的(de)(de)(de)及(ji)時(shi)傳遞(di)和(he)保障(zhang)大型活(huo)動的(de)(de)(de)順(shun)利進(jin)行。在故障(zhang)發(fa)生(sheng)時(shi)和(he)發(fa)生(sheng)后有相應監控報警實時(shi)跟(gen)進(jin)，增加日常巡檢機(ji)制(zhi)防(fang)范風險(xian)發(fa)生(sheng)，只有持續探索和(he)優化，不斷提升(sheng)系統(tong)(tong)的(de)(de)(de)穩定性(xing)和(he)可(ke)靠性(xing)，才(cai)能在競(jing)爭激烈的(de)(de)(de)市場(chang)中脫穎而出，為用戶提供卓越的(de)(de)(de)體(ti)驗。