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

之家短(duan)信(xin)平臺(tai)是一個提供企(qi)業(ye)(ye)級(ji)短(duan)信(xin)服(fu)務的(de)全(quan)面解決(jue)方案(an)。目前支持短(duan)信(xin)發送(song)、彩(cai)信(xin)發送(song)、提供一套完(wan)整安(an)全(quan)策(ce)略的(de)驗(yan)證(zheng)碼發送(song)服(fu)務，該平臺(tai)以高可用(yong)性(xing)、穩(wen)定性(xing)和安(an)全(quan)性(xing)為(wei)首(shou)要目標(biao)，為(wei)之家各業(ye)(ye)務線提供可靠的(de)短(duan)信(xin)發送(song)和接(jie)收功(gong)能。

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

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

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

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

• 故障監(jian)控(kong)報(bao)警：平(ping)臺設(she)有完(wan)善的監(jian)控(kong)系統，可以(yi)實(shi)時監(jian)測系統狀態，并在發現異常(chang)時立即發出告警。

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

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

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

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

分析原有短信(xin)架構，找出性(xing)能瓶(ping)頸

• 手機號驗證(zheng)、路由(you)分配、策略等配置(zhi)數(shu)據(ju)直接讀(du)庫(ku)。
• 接(jie)口接(jie)收到(dao)發送短(duan)信請求后(hou)同(tong)步調(diao)用三方短(duan)信通(tong)道商，如遇(yu)網(wang)絡卡頓或三方服務(wu)不(bu)穩(wen)定就會出現接(jie)口響應(ying)超時。
• 信息同步保(bao)存到數(shu)據(ju)(ju)庫，如(ru)果遇(yu)到網(wang)絡波動或數(shu)據(ju)(ju)庫繁忙的情況下會(hui)出現接口響應卡頓。
• 短(duan)信發送是異步請求，并非同步發送，流程如下圖(tu)：

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

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

Api服務：

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

分發服(fu)務：負責消費 “api服(fu)務” 產(chan)生的(de)合規(gui)數據(ju)，將調用三(san)方發送結果加(jia)密后發送到kafka。

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

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

經(jing)過調研，4層(ceng)(ceng)AnyCast是一種網絡(luo)尋址和路由(you)方法(fa)，它可以將(jiang)數(shu)據流(liu)重定向到最近(jin)、最佳或某特(te)定的(de)節點。因此，當A機(ji)房出現故(gu)障(zhang)時，系(xi)統(tong)會(hui)憑借4層(ceng)(ceng)AnyCast的(de)特(te)性，自(zi)(zi)動(dong)選擇并切換到功能正(zheng)常的(de)B機(ji)房，從而故(gu)障(zhang)自(zi)(zi)動(dong)轉(zhuan)移，且整個過程(cheng)是自(zi)(zi)動(dong)切換，沒有人工依(yi)賴大大縮短了故(gu)障(zhang)響應時間。

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

架構優(you)點：避(bi)免因網(wang)絡故障(zhang)導致A機(ji)房整體失聯(lian)。

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

狀(zhuang)(zhuang)態報告主要作用(yong)是能夠了(le)解短信送達情況和月底結算(suan)，由于狀(zhuang)(zhuang)態報告涉(she)及到網絡調(diao)用(yong)和更新操作，大(da)批(pi)量短信發(fa)送場(chang)景下，對于網絡和數據庫都(dou)有(you)一定壓力(li)都(dou)非(fei)常大(da)，所(suo)以在活(huo)動當天選(xuan)擇服務降級(ji)，等活(huo)動結束后(hou)選(xuan)擇業(ye)務量較少的時間點回推(tui)短信狀(zhuang)(zhuang)態報告。

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

架構再(zai)完(wan)美(mei)，也避(bi)免不(bu)了(le)會出現故(gu)障(zhang)，那(nei)么第一(yi)時間(jian)發(fa)出告警信息(xi)就顯得彌足珍貴，短信本身作為一(yi)個消息(xi)發(fa)送(song)方，那(nei)如何保證他本身出現問題還能發(fa)出消息(xi)告警呢？大家想象一(yi)下以下場景

• 短信服務本身(shen)異常了(le)
• 短信(xin)服務(wu)依賴的中間件故障了，Redis、TiDB、kafka
• 短信所(suo)處(chu)的1個機(ji)房故障了
• 短信所處的(de)2個機房都故障了
• 短信(xin)下發通道商(shang)正常，但通道商(shang)調用三大(da)運(yun)營商(shang)有問(wen)題
• 短信下發通道(dao)商失敗(bai)，網(wang)絡超時、DNS解析失敗(bai)等錯(cuo)誤
• 短(duan)信回調之(zhi)家業務方故障了，502、404、500等錯誤
• 上(shang)行短信(xin)通道商配置(zhi)錯誤導致數(shu)據回(hui)傳有問(wen)題(ti)
• 狀態報告(gao)非約定(ding)狀態碼(ma)
• 配(pei)置(zhi)文(wen)件修改錯誤導致短信下(xia)發失敗

等(deng)等(deng)

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

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

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