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