分布式網(wǎng)站消息通道服務(wù)的設計發(fā)布者：本站     時(shí)間：2019-03-27 20:03:00

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


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