分布式網(wǎng)站消息通道服務的設計發(fā)布者：本站 時間：2019-03-27 20:03:00
分布式消息通道廣泛應用在很多公司，尤其是在移動App和服務端需要上傳、推送大量的數(shù)據(jù)和消息時。比如打車App每天要上傳大量的位置信息，服務端也有很多訂單要及時推送給司機；此外，由于司機是在高速移動過程中，所以網(wǎng)絡連接的穩(wěn)定性也不是很好這類場景給消息通道的高可用設計帶來很大的挑戰(zhàn)。
一個典型的移動Ap的消息通道的設計架構圖，這種設計比較適合上傳數(shù)據(jù)量大，并且高速移動導致網(wǎng)絡不太穩(wěn)定的鏈路。
鏈路1是 Client和整個服務端的長連接鏈路，一般采用私有協(xié)議的TCP請求。如果是第一次請求還會通過2做鏈接認證，認證通過后會把該 Client和接入集群的某個服務器做個KV對，并記錄到路由表里這可以方便下發(fā)消息時找到該鏈接。經(jīng)過鏈路4，上行消息處理集群會將TCP請求轉成普通的HTTP請求，再調(diào)用后端業(yè)務執(zhí)行具體的業(yè)務邏輯，或者只是上傳一個數(shù)據(jù)而已，不做任何響應。如果業(yè)務有數(shù)據(jù)需要下發(fā)，會經(jīng)過鏈路6，把消息推送到消息下發(fā)處理集群，由它把消息推送給 Client。
消息下發(fā)集群公査向鏈接路表，確足當前Cent的鏈按在言，再通該服務器把消息推送下去。這里常見的問題是當前 Client的網(wǎng)絡不可達，導致消息無法推送。在這種情況下，消息下發(fā)處理集群會保持該消息，并定時嘗試再推送；如果Client重新建立連接，連接的服務器也會隨之變化，那么消息下發(fā)集群會去查詢鏈接路由表再重新連接新的KV對。
鏈路9是為了處理 Client端的一些同步請求而設計的。例如 Client需要發(fā)送一個HTTP請求并且期望能返回結果，這時Client中的業(yè)務層可能直接請求HTTP，再經(jīng)過 Client I中的網(wǎng)絡模塊轉成私有TCP協(xié)議，在上行長鏈請求集群轉成HTP請求，調(diào)用后端業(yè)務并將HTTP的response轉成消息發(fā)送到消息下發(fā)處理集群，異步下發(fā)給Client，到達Client再轉成業(yè)務的HTTPresponse。這種設計的主要考慮是當HTTP響應返回時，如果長鏈已經(jīng)斷掉，該響應就沒法再推送回去。因此，這種上行同步請求而下行異步推送是一種更高可用的設計。
從整體架構上看，只有接入集群是有狀態(tài)的，其他集群都是無狀態(tài)的，這也保證了網(wǎng)站設計集群的擴展性。如果接入點在全國有多個點，并且這些點與服務端有專線網(wǎng)絡服務，接人集群還可以做到就近接入。
選擇我們，優(yōu)質(zhì)服務，不容錯過
1. 優(yōu)秀的網(wǎng)絡資源，強大的網(wǎng)站優(yōu)化技術，穩(wěn)定的網(wǎng)站和速度保證
2. 15年上海網(wǎng)站建設經(jīng)驗，優(yōu)秀的技術和設計水平，更放心
3. 全程省心服務，不必擔心自己不懂網(wǎng)絡，更省心。
------------------------------------------------------------
24小時聯(lián)系電話：021-58370032