一个典型的移动Ap的消息通道的设计架构图,这种设计比较适合上传数据量大,并且高速移动导致网络不太稳定的链路。
链路1是 Client和整个服务端的长连接链路,一般采用私有协议的TCP请求。如果是第一次请求还会通过2做链接认证,认证通过后会把该 Client和接入集群的某个服务器做个KV对,并记录到路由表里这可以方便下发消息时找到该链接。经过链路4,上行消息处理集群会将TCP请求转成普通的HTTP请求,再调用后端业务执行具体的业务逻辑,或者只是上传一个数据而已,不做任何响应。如果业务有数据需要下发,会经过链路6,把消息推送到消息下发处理集群,由它把消息推送给 Client。
消息下发集群公査向链接路表,确足当前Cent的链按在言,再通该服务器把消息推送下去。这里常见的问题是当前 Client的网络不可达,导致消息无法推送。在这种情况下,消息下发处理集群会保持该消息,并定时尝试再推送;如果Client重新建立连接,连接的服务器也会随之变化,那么消息下发集群会去查询链接路由表再重新连接新的KV对。
链路9是为了处理 Client端的一些同步请求而设计的。例如 Client需要发送一个HTTP请求并且期望能返回结果,这时Client中的业务层可能直接请求HTTP,再经过 Client I中的网络模块转成私有TCP协议,在上行长链请求集群转成HTP请求,调用后端业务并将HTTP的response转成消息发送到消息下发处理集群,异步下发给Client,到达Client再转成业务的HTTPresponse。这种设计的主要考虑是当HTTP响应返回时,如果长链已经断掉,该响应就没法再推送回去。因此,这种上行同步请求而下行异步推送是一种更高可用的设计。
从整体架构上看,只有接入集群是有状态的,其他集群都是无状态的,这也保证了网站设计集群的扩展性。如果接入点在全国有多个点,并且这些点与服务端有专线网络服务,接人集群还可以做到就近接入。
本文地址://www.xrqsnxx.com//article/4459.html