在信(xin)息化(hua)時代，短信(xin)作為最基本的(de)(de)(de)通(tong)信(xin)方式，在各(ge)種(zhong)業(ye)務(wu)中(zhong)都扮演著重(zhong)要(yao)角色(se)。但(dan)是，隨著業(ye)務(wu)量(liang)的(de)(de)(de)增長(chang)和(he)用戶(hu)對服務(wu)質量(liang)要(yao)求(qiu)的(de)(de)(de)提(ti)高，短信(xin)平(ping)臺(tai)的(de)(de)(de)高可用性成為了(le)我們(men)面(mian)臨的(de)(de)(de)一個重(zhong)大挑戰(zhan)。接下來的(de)(de)(de)分享(xiang)，將帶領大家走進我們(men)在尋找短信(xin)平(ping)臺(tai)高可用解決方案的(de)(de)(de)探(tan)索之路。

之家(jia)(jia)短信平臺是一個提(ti)供企(qi)業級(ji)短信服(fu)務(wu)(wu)的全(quan)面(mian)解決方案。目前支持(chi)短信發(fa)送(song)(song)(song)、彩(cai)信發(fa)送(song)(song)(song)、提(ti)供一套完整(zheng)安(an)全(quan)策略的驗證(zheng)碼發(fa)送(song)(song)(song)服(fu)務(wu)(wu)，該(gai)平臺以(yi)高可用性、穩定(ding)性和安(an)全(quan)性為首要目標，為之家(jia)(jia)各業務(wu)(wu)線提(ti)供可靠的短信發(fa)送(song)(song)(song)和接(jie)收功能。

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

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

• 限(xian)頻限(xian)流：使用先(xian)進的算法(fa)進行(xing)流量(liang)控制(zhi)，確保系統在面臨(lin)大量(liang)請求時不(bu)會過載，保障短(duan)信(xin)服務質(zhi)量(liang)。

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

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

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

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

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

 隨(sui)著業務的發(fa)(fa)展和對大(da)型活動的支持，面對瞬(shun)時大(da)量短(duan)信(xin)發(fa)(fa)送場(chang)景（百萬(wan)QPS發(fa)(fa)送請(qing)求），以往的單一架構支撐(cheng)起(qi)來捉襟見肘，于(yu)是開(kai)啟(qi)了短(duan)信(xin)平臺的高可用探索實踐之路(lu)。

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

• 手機號驗證(zheng)、路由分(fen)配、策略等(deng)配置數據直接讀(du)庫(ku)。
• 接(jie)口接(jie)收到發送(song)短(duan)信請求后(hou)同步調用三方短(duan)信通道商，如遇網(wang)絡卡頓或三方服務不(bu)穩定(ding)就會出現接(jie)口響應超時(shi)。
• 信息同步保(bao)存到(dao)數據庫，如果(guo)遇到(dao)網絡波動或(huo)數據庫繁忙的(de)情況下會(hui)出現(xian)接口響應卡頓(dun)。
• 短信發送(song)是異步請求，并(bing)非(fei)同(tong)步發送(song)，流程(cheng)如下(xia)圖：

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

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

Api服務：

• 負責基本數據(ju)校驗(yan)，包括手機(ji)號合法性、黑(hei)白名單、路由通道等，所(suo)涉及到(dao)的配置信息全部從緩存中(zhong)讀取，不再依賴數據(ju)庫，合規(gui)數據(ju)加密后(hou)發(fa)送到(dao)kafka。
•  接收(shou)狀態報(bao)告(gao)回執(zhi)信(xin)息
• 接收用(yong)戶回復(fu)的短信內容(rong)

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

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

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

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

于是將完(wan)整的(de)短(duan)信(xin)服(fu)務在(zai)(zai)A機(ji)房(fang)和B機(ji)房(fang)分別部署(shu)一(yi)份，AB兩個(ge)機(ji)房(fang)所(suo)涉(she)及到的(de)中間件(jian)完(wan)全獨立。但是存在(zai)(zai)一(yi)個(ge)問(wen)題，數(shu)(shu)據(ju)庫數(shu)(shu)據(ju)不能分開，跟DBA商討后決定，數(shu)(shu)據(ju)層面采用TiDB互為主從的(de)方式實現，當A機(ji)房(fang)失(shi)聯(lian)后無需(xu)DBA干預(yu)，數(shu)(shu)據(ju)可以實時寫入B機(ji)房(fang)，AB機(ji)房(fang)數(shu)(shu)據(ju)實時同(tong)步。

架(jia)構優點：避免因網絡故障導致A機房(fang)整體(ti)失聯(lian)。

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

狀(zhuang)態報(bao)告(gao)主要(yao)作用是能夠了解短(duan)信(xin)送達(da)情(qing)況和(he)月底結算(suan)，由于(yu)狀(zhuang)態報(bao)告(gao)涉及到(dao)網絡(luo)調(diao)用和(he)更新操(cao)作，大批量(liang)短(duan)信(xin)發送場(chang)景下，對于(yu)網絡(luo)和(he)數據庫都(dou)有(you)一定壓力都(dou)非常大，所以在活動當天選擇服務(wu)(wu)降級(ji)，等活動結束后選擇業務(wu)(wu)量(liang)較少的時間點回(hui)推短(duan)信(xin)狀(zhuang)態報(bao)告(gao)。

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

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

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

等等

以(yi)上部分故(gu)障可以(yi)通(tong)過短(duan)信(xin)系(xi)統自身發(fa)出報(bao)(bao)(bao)警(jing)，但是(shi)有一些故(gu)障需要依賴三方(fang)才能夠(gou)實(shi)現(xian)消息(xi)的傳遞。短(duan)信(xin)平臺(tai)結合鷹眼日志(zhi)、真機短(duan)信(xin)發(fa)送與接收(shou)、運(yun)營商實(shi)時監(jian)(jian)控反饋、通(tong)道商客服(fu)24小時值守等外部系(xi)統進行監(jian)(jian)察，消息(xi)接收(shou)方(fang)式包括(kuo)短(duan)信(xin)、釘(ding)釘(ding)、微信(xin)、電話，設置多個(ge)報(bao)(bao)(bao)警(jing)接收(shou)人(ren)(ren)，避(bi)免單一報(bao)(bao)(bao)警(jing)系(xi)統出現(xian)問題，導致報(bao)(bao)(bao)警(jing)內容(rong)無法(fa)觸達短(duan)信(xin)平臺(tai)接收(shou)人(ren)(ren)員。

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

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