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