分布式消息通道廣泛應(yīng)用在很多公司，尤其是在移動(dòng)App和服務(wù)端需要上傳、推送大量的數(shù)據(jù)和消息時(shí)。比如打車(chē)App每天要上傳大量的位置信息，服務(wù)端也有很多訂單要及時(shí)推送給司機(jī)；此外，由于司機(jī)是在高速移動(dòng)過(guò)程中，所以網(wǎng)絡(luò)連接的穩(wěn)定性也不是很好這類(lèi)場(chǎng)景給消息通道的高可用設(shè)計(jì)帶來(lái)很大的挑戰(zhàn)。


 
一個(gè)典型的移動(dòng)Ap的消息通道的設(shè)計(jì)架構(gòu)圖，這種設(shè)計(jì)比較適合上傳數(shù)據(jù)量大，并且高速移動(dòng)導(dǎo)致網(wǎng)絡(luò)不太穩(wěn)定的鏈路。
 
鏈路1是 Client和整個(gè)服務(wù)端的長(zhǎng)連接鏈路，一般采用私有協(xié)議的TCP請(qǐng)求。如果是第一次請(qǐng)求還會(huì)通過(guò)2做鏈接認(rèn)證，認(rèn)證通過(guò)后會(huì)把該 Client和接入集群的某個(gè)服務(wù)器做個(gè)KV對(duì)，并記錄到路由表里這可以方便下發(fā)消息時(shí)找到該鏈接。經(jīng)過(guò)鏈路4，上行消息處理集群會(huì)將TCP請(qǐng)求轉(zhuǎn)成普通的HTTP請(qǐng)求，再調(diào)用后端業(yè)務(wù)執(zhí)行具體的業(yè)務(wù)邏輯，或者只是上傳一個(gè)數(shù)據(jù)而已，不做任何響應(yīng)。如果業(yè)務(wù)有數(shù)據(jù)需要下發(fā)，會(huì)經(jīng)過(guò)鏈路6，把消息推送到消息下發(fā)處理集群，由它把消息推送給 Client。
 
消息下發(fā)集群公査向鏈接路表，確足當(dāng)前Cent的鏈按在言，再通該服務(wù)器把消息推送下去。這里常見(jiàn)的問(wèn)題是當(dāng)前 Client的網(wǎng)絡(luò)不可達(dá)，導(dǎo)致消息無(wú)法推送。在這種情況下，消息下發(fā)處理集群會(huì)保持該消息，并定時(shí)嘗試再推送；如果Client重新建立連接，連接的服務(wù)器也會(huì)隨之變化，那么消息下發(fā)集群會(huì)去查詢鏈接路由表再重新連接新的KV對(duì)。
 
鏈路9是為了處理 Client端的一些同步請(qǐng)求而設(shè)計(jì)的。例如 Client需要發(fā)送一個(gè)HTTP請(qǐng)求并且期望能返回結(jié)果，這時(shí)Client中的業(yè)務(wù)層可能直接請(qǐng)求HTTP，再經(jīng)過(guò) Client I中的網(wǎng)絡(luò)模塊轉(zhuǎn)成私有TCP協(xié)議，在上行長(zhǎng)鏈請(qǐng)求集群轉(zhuǎn)成HTP請(qǐng)求，調(diào)用后端業(yè)務(wù)并將HTTP的response轉(zhuǎn)成消息發(fā)送到消息下發(fā)處理集群，異步下發(fā)給Client，到達(dá)Client再轉(zhuǎn)成業(yè)務(wù)的HTTPresponse。這種設(shè)計(jì)的主要考慮是當(dāng)HTTP響應(yīng)返回時(shí)，如果長(zhǎng)鏈已經(jīng)斷掉，該響應(yīng)就沒(méi)法再推送回去。因此，這種上行同步請(qǐng)求而下行異步推送是一種更高可用的設(shè)計(jì)。
 
從整體架構(gòu)上看，只有接入集群是有狀態(tài)的，其他集群都是無(wú)狀態(tài)的，這也保證了網(wǎng)站設(shè)計(jì)集群的擴(kuò)展性。如果接入點(diǎn)在全國(guó)有多個(gè)點(diǎn)，并且這些點(diǎn)與服務(wù)端有專線網(wǎng)絡(luò)服務(wù)，接人集群還可以做到就近接入。