IM架构

应用范围

架构

• 接入服务的主要是为客户端提供消息收发的出入口，而业务处理服务主要是处理各种聊天消息的业务逻辑

• 在很多基于私有通信协议的 IM 系统实现中，接入服务还提供协议的编解码工作

  • 编解码实际主要是为了节省网络流量，系统会针对传输的内容进行紧凑的编码（比如 Protobuf）

• 为什么接入服务和业务处理服务要独立拆分呢？

  • 接入服务作为消息收发的出入口，必须是一个高可用的服务
    • 而业务处理服务由于随着产品需求迭代，变更非常频繁
    • 如果消息收发接入和业务逻辑处理都在一起，势必会让接入模块随着业务逻辑的变更上线，而频繁起停，导致已通过网络接入的客户端连接经常性地断连、重置、重连
    • 连接层的不稳定性会导致消息下推不及时、消息发送流畅性差，甚至会导致消息发送失败，从而降低用户消息收发的体验
  • 有助于提升业务开发效率
    • 接入服务负责处理一切网络通信相关的部分，比如网络的稳定性、通信协议的编解码等
    • 负责业务开发的同事就可以更加专注于业务逻辑的处理，而不用关心让人头痛的网络问题

• App 在进程关闭，或者长时间后台运行时，App 和 IM 服务端的连接会被手机操作系统断开

  • 为了让用户在 App 未打开时，或者在后台运行时，也能接收到新消息，我们会将消息给到第三方外部接口服务，来通过手机操作系统自身的公共连接服务来进行操作系统级的“消息推送”
  • 第三方系统推送服务有苹果手机自带的 **APNs（Apple Push Notification service）**服务、安卓手机内置的谷歌公司的 **GCM（Google Cloud Messaging）**服务

• 业务模块发消息给用户时，怎么知道用户处于接入模块的那一个实例服务？

  • 可以在用户上线时维护一个全局的uid到接入网关的映射来做到定向推送
  • 对于超大群或者直播互动场景可以不区分某一个用户落在哪个接入网关，而是让所有网关获取后来下推连到本机的用户

• IM架构中也会使用HTTP协议，不全是Websocket

  • 比如一个图片或者视频，一般是会先通过Websocket把这个图片或者视频的ID推到客户端，然后再由端上发起http请求来获取真正的图片和视频

安全性

• 采用多通道方式避免消息链路中断

  • 从 HttpDNS 服务返回的多个“接入 IP”中选择性进行切换，防止某一个“接入 IP”的中间链路被破坏
  • 从当前数据传输协议切换到其他传输协议
    • 比如从基于 UDP 协议的 QUIC 协议切换到基于 TCP 协议的私有协议；或者针对 TCP 的私有协议提供 HTTP Tunnel 来对数据进行二次封装
    • 防止某些针对特定协议的中断攻击

• 端到端加密

  • 通信双方各自生成秘钥对并进行公钥的交换，私钥各自保存在本地不给到 IM 服务端
    • 发送方的消息使用接收方的公钥来进行加密，因此即使是 IM 服务端拿到了加密信息，由于没有接收方的私钥，也无法解密消息
  • 很多聊天软件如Telegram 就采用了“端到端加密”方式来保证消息内容的安全
    • 国内的大部分即时消息软件如 QQ、微信等由于网络安全要求，目前暂时还没有采用“端到端加密”

• 敏感内容识别

  • 建立敏感词库，针对文字内容进行安全识别
  • 依托图片识别技术来对色情图片和视频、广告图片、涉政图片等进行识别处置
  • 使用“语音转文字”和 OCR（图片文本识别）来辅助对图片和语音的进一步挖掘识别
  • 通过爬虫技术来对链接内容进行进一步分析，识别“风险外链”

实时性

可靠性（消息不丢失、不重复）

一致性（顺序一致，多终端一致）