外部接口服务
由于手机限制及资源优化的考虑,大部分App在进程关闭或长时间后台运行时,App和IM服务端的连接会被手机os断开。这样当有新的消息产生时,就没法通过IM服务再触达用户,因而会影响用户体验。
为让用户在App未打开或在后台运行时,也能接收到新消息,我们将消息给到第三方外部接口服务,来通过手机操作系统自身的公共连接服务来进行操作系统级的“消息推送”,通过这种方式下发的消息一般会在手机的“通知栏”对用户进行提醒和展示。常用的第三方系统推送服务:
苹果手机自带的APNs(Apple Push Notification service)服务
安卓手机内置的谷歌公司的GCM(Google Cloud Messaging)服务
但GCM服务在国内无法使用,为此很多国内手机厂商在各自手机系统中,也提供类似的公共系统推送服务,如小米、华为、OPPO、vivo等手机厂商都有相应的SDK。
接入服务和业务处理服务独立拆分原因:
接入服务作为消息收发的出入口,必须高可用
如果连接服务总不稳定:连不上或频繁断连,大大影响聊天流畅。
业务处理服务由于随产品需求迭代,变更非常频繁,随时有新业务需上线重启。
若消息收发接入和业务逻辑处理都在一起,势必让接入模块随业务逻辑的变更上线而频繁起停,导致已通过网络接入的客户端连接经常性地断连、重置、重连。
这种连接层的不稳定性会导致消息下推不及时、消息发送流畅性差,甚至会导致消息发送失败,从而降低用户消息收发的体验。
所以将“只负责网络通道维持,不参与业务逻辑,不需要频繁变更的接入层”抽离出来,不管业务逻辑如何调整变化,都不需要接入层进行变更,这样能保证连接层的稳定性,从而整体上提升消息收发的用户体验。
业务开发人员的角度看,接入服务和业务处理服务进行拆分有助于提升业务开发效率,降低业务开发门槛。
模块拆分后,接入服务负责处理一切网络通信相关的部分,比如网络的稳定性、通信协议的编解码等。这样负责业务开发的同事就可以更加专注于业务逻辑的处理,而不用关心让人头痛的网络问题,也不用关心“天书般的通信协议”了。
接入模块收到一个消息后,通过rpc或者mq来进行对接推送到业务模块。
业务模块下发消息给用户时,怎么知道用户处于接入模块的那一个实例服务(接入模块肯定是有多个实例同时运行的)
推送时,可以在用户上线时维护一个全局uid到接入网关的映射来做定向推送,对于超大群或直播互动场景可不区分某一个用户落在哪个接入网关,而是让所有网关获取后来下推连到本机用户。