丨h(huán)ttptunnel復(fù)雜網(wǎng)絡(luò)下消息通道高可用設(shè)計(jì)的思考

那么，在面對(duì)如何保障消息通道的高可用這一問題時(shí)，業(yè)界有哪些比較常用的優(yōu)化呢來好像挺簡(jiǎn)單的，不就是申請(qǐng)個(gè)虛擬IP，把接入層服務(wù)器掛上去，然后通過出去就行了嗎況復(fù)雜性高。比如，有的用戶走2G網(wǎng)絡(luò)來連，有的通過HTTP來連，還有的會(huì)出現(xiàn)DNS解析服務(wù)被封的情況，諸如此類。多端首先就是端口的連通性問題計(jì)算機(jī)端口范圍是0~65535，主要分成三大類：公認(rèn)端口（0~1023）、端（1024~49151）、動(dòng)態(tài)或私有端口（49152~65535）端口限制，以及一些軟件為了控制安全風(fēng)險(xiǎn)，只允許某些端口，因此大部分端口都目前，業(yè)界確認(rèn)比較安全的端口基本上只有80、8080、443、14000這幾個(gè)。因此如果開此外，還可以通過同時(shí)這幾個(gè)端口中的某幾個(gè)，來進(jìn)一步提升可連通性。當(dāng)其中一個(gè)端口出現(xiàn)連通性問題時(shí)，另外的端口還可以作為Failoer端口，當(dāng)作備用端口來連接。HTTP比如，一些公司或者酒店的網(wǎng)絡(luò)只允許通過HTTP協(xié)議（PS：早期通過CMWAP入點(diǎn)上網(wǎng)也有這個(gè)限制，不過在2011后，隨著CMWAPCMNET入點(diǎn)融合，這個(gè)問題得到了解決），這樣即時(shí)消息系統(tǒng)中，通過TCP或者UDP實(shí)現(xiàn)的私有這種場(chǎng)景，我們可以通過HTTPTunnel的方式來對(duì)網(wǎng)絡(luò)進(jìn)行所謂HTTPTunnel，其實(shí)就是通過HTTP協(xié)議，來封裝其他由于網(wǎng)絡(luò)原因不兼容的（比如TCP私有協(xié)議）這樣不僅解決了網(wǎng)絡(luò)協(xié)議連通性問題，而且因?yàn)镠TTPTunnel也只是在原來的私有協(xié)議內(nèi)容最外層做了最輕量的HTTP封裝（HTTPBody內(nèi)容就是二進(jìn)制的私有協(xié)議），所以協(xié)議多接入點(diǎn)IP列在第6講“HttpDNS和TLS：你的消息聊天真的安全嗎？”中講消息通道安全性的時(shí)候，我就有提到，通過HttpDNS能解決DNS劫持的問題。其實(shí)，借助HttpDNS，我們還能通過返回多個(gè)接入點(diǎn)IP來解決連通性的問題，后續(xù)一個(gè)連接失敗就嘗試下一個(gè)，這樣就相當(dāng)于給我們提供了一個(gè)接入點(diǎn)的Failover機(jī)制。同時(shí)，為了防止通過HTTP請(qǐng)求DNS時(shí)出現(xiàn)失敗或者超時(shí)的問題，我們還可以在客戶端進(jìn)比如，預(yù)埋一個(gè)和幾個(gè)常用的接入 IP，用這個(gè)作為請(qǐng)求接入最后的兜底策略。然，這些預(yù)埋的和接入點(diǎn)IP一般需要盡量保證穩(wěn)定性，如果有變動(dòng)，需要及時(shí)預(yù)埋到新版App中。解決了通道連得上的問題，接下來我們需要考慮的就是怎么讓接入方能連得快。這里有兩種實(shí)現(xiàn)方式：一個(gè)是通過解決跨網(wǎng)延遲來避免通道連接過慢，另一個(gè)可以通過跑馬競(jìng)速來選擇速度最快的通道進(jìn)行接入。解決跨網(wǎng)延同樣在第6講中有提到，由于運(yùn)營(yíng)商跨網(wǎng)延遲的問題，我們希望能盡量讓某一個(gè)運(yùn)營(yíng)商的快，首先要求我們需要有多運(yùn)營(yíng)商機(jī)房的接入點(diǎn)；其次，要避免運(yùn)營(yíng)商DNS解析轉(zhuǎn)發(fā)和NAT導(dǎo)致接入IP被解析到其他運(yùn)營(yíng)商的問題。第一個(gè)多運(yùn)營(yíng)商機(jī)房的要求比較好實(shí)現(xiàn)，基本只是成本方面的投入，目前很多IDC第二個(gè)問題，我們可以通過之前講到的HttpDNS來解決。HttpDNS能直接獲取到用戶的出口網(wǎng)關(guān)IP，調(diào)度更精準(zhǔn)，而且繞過了運(yùn)營(yíng)商的LocalDNS，不會(huì)出現(xiàn)DNS解析轉(zhuǎn)發(fā)導(dǎo)致跑馬競(jìng)除了避免跨網(wǎng)導(dǎo)致通道連接慢的問題之外，對(duì)于返回的多個(gè)接入點(diǎn)IP，實(shí)際上由于用戶上網(wǎng)地點(diǎn)不同和路由規(guī)則不同等原因，連接接入點(diǎn)IP時(shí)，延遲也是不一樣的。因此，我們還可以通過跑馬競(jìng)速的方式，來動(dòng)態(tài)調(diào)整每一個(gè)用戶優(yōu)先連接的接入點(diǎn)IP。所謂的“跑馬競(jìng)速”，你可以理解為類似賽馬一樣，我們一次放出多匹馬參與比賽，最終跑得最快的馬勝出。App終端會(huì)對(duì)返回的接入點(diǎn)IP列表中的所有IP進(jìn)行跑馬測(cè)試，并將測(cè)速結(jié)果上報(bào)給服務(wù)端，服務(wù)端根據(jù)這個(gè)測(cè)速結(jié)果，結(jié)合后端接入服務(wù)器的負(fù)載，來動(dòng)態(tài)調(diào)整接入點(diǎn)IP列表的這里我舉一個(gè)簡(jiǎn)單的接入點(diǎn)跑馬競(jìng)速實(shí)現(xiàn)的例子：客戶端在啟動(dòng)時(shí)，通過HttpDNS服務(wù)獲取到多個(gè)接入點(diǎn)VIP1、VIP2和VIP3，此時(shí)客戶端針對(duì)這3個(gè)VIP進(jìn)行并發(fā)測(cè)速（一般可以通過一個(gè)固定大小的靜態(tài)頁(yè)面來實(shí)現(xiàn)），根據(jù)每個(gè)VIP的整體響應(yīng)耗時(shí)來決定后續(xù)正式的連接使用哪個(gè)VIP。這里，由于VIP2響應(yīng)耗時(shí)最少，最后客戶端會(huì)選擇使用VIP2解決了消息通道連得上和連得快的問題，另一個(gè)提高消息通道可用性的重要是讓通道能通道和業(yè)務(wù)解我們知道，對(duì)于通道中收發(fā)的消息會(huì)進(jìn)行很多業(yè)務(wù)邏輯的操作，比如消息、加未讀、版本兼容邏輯等。隨著需求的不斷迭代和新功能的增加，可能還會(huì)新增業(yè)務(wù)協(xié)議或者修改原有業(yè)務(wù)協(xié)議的字段，這些變更都是緊隨業(yè)務(wù)變化的，相對(duì)會(huì)比較頻繁。但是在即時(shí)消息系統(tǒng)中，消息的收發(fā)是嚴(yán)重依賴長(zhǎng)連接通道的，如果我們的通道層需要跟隨業(yè)務(wù)的變化而不斷調(diào)整，那么就會(huì)導(dǎo)致通道服務(wù)也需要頻繁地上線、重啟。這些操作會(huì)讓已經(jīng)連到通道機(jī)器的用戶連接斷開，雖然客戶端一般都會(huì)有斷線重連的機(jī)制，但是頻繁地?cái)噙B也會(huì)降低消息收發(fā)的成功率和用戶體驗(yàn)。比如，用戶和連接的映射、通信協(xié)議的編、建連和斷連邏輯處理、ACK包和心跳包處理等，將變化較大的業(yè)務(wù)邏輯下沉到后端的業(yè)務(wù)處理層。這樣不管業(yè)務(wù)怎么變動(dòng)，我們的通道網(wǎng)關(guān)服務(wù)都不需要跟著變更，穩(wěn)定性也會(huì)更好。上下行通道除了讓通道層和業(yè)務(wù)，面對(duì)消息下推壓力比較大的場(chǎng)景，還可以對(duì)上下行通道進(jìn)行拆分比如對(duì)于互動(dòng)的場(chǎng)景，下推消息由于扇出大，因此當(dāng)遇到大型的時(shí)候下行通道的壓力會(huì)加大，雖然可以通過限流、降級(jí)、擴(kuò)容等方式來緩解，但在這時(shí)，系統(tǒng)的整體負(fù)載和流量都是比較大的。這種場(chǎng)景下，我們可以對(duì)上下行通道進(jìn)行拆分，用戶上行的消息和行為通過一個(gè)短連通道發(fā)送到服務(wù)端。這樣既能避免客戶端多個(gè)長(zhǎng)連接的開銷，也能解決上行通道被下推消息影響的問題。間的空閑而不斷開（比如2分鐘），這樣對(duì)于用戶連續(xù)發(fā)消息的情況，不需要每次再有重下面畫了一個(gè)圖來簡(jiǎn)單描述下如何對(duì)上下行通道進(jìn)行拆分用戶A和用戶B分別都通過接入查詢服務(wù)來獲取最優(yōu)接入點(diǎn)，用戶A通過上行通道的短連接網(wǎng)關(guān)來發(fā)送消息，發(fā)送的消息在上行業(yè)務(wù)處理服務(wù)進(jìn)行、加未讀等業(yè)務(wù)操作；然后通過消息隊(duì)列把這條消息給到下行通道，下行分發(fā)邏輯服務(wù)查詢用戶B的狀態(tài)等信息，并對(duì)消息進(jìn)行必要的推送準(zhǔn)備處理（比如版本兼容處理）；接著把消息給到用戶B的長(zhǎng)連接所在的長(zhǎng)連網(wǎng)關(guān)機(jī)器，長(zhǎng)連網(wǎng)關(guān)機(jī)器再將消息推送到用戶B的設(shè)備中。這樣，我們的上下行通道就通過消息隊(duì)列的方式進(jìn)行了和解耦獨(dú)立多上傳對(duì)于、等多消息，由于數(shù)據(jù)傳輸量一般都比較大，如果也和普通文本消息收發(fā)的通道放在一條連接里，可能會(huì)導(dǎo)致消息收發(fā)通道出現(xiàn)阻塞，因此我們一般會(huì)開辟新的連接通道來傳輸二進(jìn)制的文件流。這種優(yōu)化方式除了能保護(hù)消息收發(fā)的通道，也能縮短上傳的鏈路，提高消息收發(fā)的性能。針對(duì)多消息的整體上傳的優(yōu)化，我們?cè)诮酉聛淼?4和15篇中會(huì)詳細(xì)講解，這里先不做展開了。我們簡(jiǎn)單回顧一下今天的課程內(nèi)容。這節(jié)課我介紹了一下消息通道在復(fù)雜網(wǎng)絡(luò)情況下，會(huì)出現(xiàn)連通性、延遲問題，以及在連接穩(wěn)定性等方面容易出現(xiàn)連不上、速度慢、連接不穩(wěn)定的問題，通過分析這些問題出現(xiàn)的具體原因，有針對(duì)性地提出了解決這些問題的辦法。口，來解決端口連通性問題；通過HTTPTunnel，來解決某些網(wǎng)絡(luò)情況下只允許HTTP協(xié)議的數(shù)據(jù)傳輸?shù)膯栴}；通過HttpDNS和客戶端預(yù)埋的方式，提供多個(gè)可選的通道接入在解決“通道連接慢”的問題上，我們可以通過支持多運(yùn)營(yíng)商機(jī)房接入點(diǎn)，來避免用戶的跨運(yùn)營(yíng)商網(wǎng)絡(luò)；此外，對(duì)于提供的多接入點(diǎn)，客戶端還可以通過“跑馬競(jìng)速”的方式優(yōu)先使用連接速度更快的接入點(diǎn)來。在解決“通道不穩(wěn)定”的問題上，我們主要從服務(wù)端的架構(gòu)設(shè)計(jì)著手，讓我們的通道層服務(wù)和變化頻繁的業(yè)務(wù)進(jìn)行解耦，避免業(yè)務(wù)頻繁變動(dòng)導(dǎo)致通道層服務(wù)不穩(wěn)定；對(duì)于消息下行通道壓力大的業(yè)務(wù)場(chǎng)景，還可以消息上下行通道，避免消息的上行被壓力大的下行通道所影響；另外，將多的上傳通道和消息收發(fā)的通道進(jìn)行，避免傳輸量大的多消息造成通道的阻塞，影響消息收發(fā)。面對(duì)復(fù)雜的移動(dòng)網(wǎng)絡(luò)場(chǎng)景，由于不可控因素實(shí)在太多，稍不注意我們就容易踩到這樣或者那樣的坑。比如，我以前的業(yè)務(wù)里，曾經(jīng)就出現(xiàn)過由于對(duì)外的接入端口不是常見端口，導(dǎo)致很多用戶連接不上的情況。但是，通過逐步的摸索和踩坑，也積累了針對(duì)移動(dòng)網(wǎng)絡(luò)復(fù)雜環(huán)境下的諸多經(jīng)驗(yàn)，希望這些經(jīng)驗(yàn)?zāi)軌驇椭阋院蟊M量避免出現(xiàn)同樣的問題。最后，給你留一道思考題：上下行通道能夠保護(hù)我們的消息接收和消息發(fā)送，那么通道會(huì)不會(huì)帶來一些影響呢？以上就是今天課程的內(nèi)容，歡迎你給我留言，我們可以在留言區(qū)一起討論。感謝你的收聽， 不得售賣。頁(yè)面已增加防盜追蹤，將依 上一 12|服務(wù)高可用：保證鏈路穩(wěn)定性的流控和熔斷機(jī)下一 14|分片上傳：如何讓你的、音消息發(fā)送得更快精選留言展1老師在第十課的<自動(dòng)智能擴(kuò)縮容：互動(dòng)場(chǎng)景中峰值流量的應(yīng)對(duì)>中提到關(guān)于上下的優(yōu)點(diǎn)"能夠各自上行操作，避免下行推送通道產(chǎn)生影響，輕量、獨(dú)立的長(zhǎng)連接服務(wù)容展HTTPTunnel在下行通道也會(huì)使用嗎，如果存在的情況，下行通道發(fā)送給的數(shù)據(jù)作者回復(fù):我們自己的業(yè)務(wù)中目前只用于上行短連通道中。理論上也是可以用在下行通道