汽车之家IM即时通讯平台技术分享

1.前言

早期之家在C端产品的即时通信功能是直接使用第三方商业软件服务（SaaS），功能扩展性上存在很大制约，某些定制化业务需求很难实现，考虑到后续业务发展需要、数据安全、内容实时审核及性能、自主可控高可用架构等因素，决定自主开发IM即时通信平台并逐步迭代替换。

2.网络通信框架及协议

2.1 网络通信框架

网络通信系统通常可以选择原生NIO库或者第三方网络框架进行开发，原生NIO的类库API比较底层基础，缺少对常用操作的封装，例如粘包、解码、重连等，开发工作量和维护成本会比较高，需要关注很多底层的东西。我们选择了目前非常热门的网络框架Netty进行开发，Netty功能强大开发门槛较低，预置了多种主流协议编解码功能，成熟、稳定，且修复了大量已经发现的JDK NIO BUG。

► Netty具备如下优点：

1.入门简单，文档齐全，无其他依赖，只依赖 JDK 就够了；

2.使用简单，预置了多种编解码功能，支持多种主流协议，对大量常用操作进行了封装，减少开发周期；

3.高性能，高吞吐，低延迟，资源消耗少；

4.灵活的线程模型，支持阻塞和非阻塞的I/O 模型；

5.代码质量高，目前主流版本基本没有 Bug；

6.社区活跃，版本迭代周期短，发现的BUG可以被及时修复，同时，更多的新功能会加入；

7.经历了大规模的商业应用考验，稳定性得到验证。

2.2 通信协议

TCP是个“流”协议，就是没有界限的一串数据，数据传输时可能会存多包或半包传输的情况，原因如下：

1. 应用程序写入字节大小于套接口发送缓冲区大小；

2. 进行 MSS 大小的 TCP 分段；

3. 以太网帧的 payload 大于 MTU 进行 IP 分片

► 解决策略

1. 消息定长，例如每个报文大小固定200字节，如果不够，空位补空格。

2. 用回车符进行分割，例如FTP协议。

3. 约定特殊字符作为消息结束标记。

4. 将消息分为消息头和消息体，消息头中包含表示消息总长度（或消息体长度）

5. 更复杂的应用层协议。

按约定的方式编解码保证数据完整性，就是通信协议。将消息分为消息头和消息体是最常见的协议设计方式（定长消息头，可变长度消息体），如下图：

► 消息头

固定长度字节来标记消息类型，及消息体字节长度。

►消息体

可以使用文本、XML、JSON、Protobuf等扩展性好的数据格式，尽量考虑以下几点：

1. 精简消息体大小，不要有冗余数据，减少网络带宽占用（尤其是大量用户发消息群聊场景下），提高传输效率

2. 数据安全性（例如加密传输）

3. 编码效率及可扩展性

► 除了自己设计实现通信协议，还可以直接使用现成的设计好的公开协议，如目前比较流行的websocket协议，相对于私有协议有以下优点：

1. 浏览器直接支持，方便web端接入

2. 降低接入成本，websocket是公开协议，接入时不需要在协议规范上耗费太多的沟通时间。

3. 很多框架包括Netty都自带实现了websocket协议解码器。

3.架构设计

客户端：用户收发消息终端

接入层：为客户端连接、收发消息、关系建立提供入口

数据层：负责各类业务逻辑数据及消息数据缓存或持久化存储，及消息指令的分发渠道。

3.1 消息设置

聊天场景常见的消息类型通常有：文本、图片、表情、语音，视频。我们把消息分为消息类型，及消息内容两部分，客户端通过识别消息类型去解析消息内容并展示，像图片视频等消息，并不需要通过消息即时传递其内容，而是先将图片或视频上传到文件服务器，消息中只需要把uri带过去，并且带上base64编码的缩略图即可，如下示例：

msgType:msg_image

msgContent: { user: { id:1,name:xxx,portrait:xxxx }, content: “缩略小图base64编码”,url:”大图地址”, extra: “” }

消息下发流程如下图：

如图，整体思路是将上行消息通过webapi写入消息队列，socket服务器通过消息队列或离线消息库进行增量消息分发同步。

socket服务承载连接着所有在线用户，发生部署上线将会导致所有在线用户断开重连，瞬间大量增加其它服务器的连接压力，且对部分用户行为可能会有短暂的影响，上行消息通过webAPI实现，统一了消息入口，方便各类渠道消息的接入，并且使得socket服务的职责变得简单单一，仅用于保持连接和推送消息，上行消息业务逻辑频繁变动时仅需要重新部署webAPI，对用户基本无感知。

还有一些建议是，对消息进行合并，压缩能极大提升消息推送吞吐能力，减少带宽占用，经测试十条以上消息压缩率能达到80%左右；细分消息队列，按不同维度拆分消息队列可以分散压力防止某类消息高峰期对其它业务消息造成延迟推送，保证其它消息的时效性，比如可以按场景用户消息，系统指令等各自使用独立的消息队列。

3.2 消息扩散

消息扩散分发是im设计的重点，尤其是一对多的场景，如群聊。简单的说就是每条消息需要扩散给群里所有人收到，通常有两种方式，读扩散，写扩散。什么是读扩散？什么是写扩散？

► 读扩散：

描述：每条消息只存一份，群组所有成员读取这一份数据。

优点：节省存储空间，无写入压力。

缺点：

1. 获取离线增量消息逻辑复杂，需要根据用户所有会话关系去遍历获取，且并未知道会话是否有增量消息，会造成大量无效空读，效率极慢。

2. 针对消息做单个用户个性化操作时设计会变的麻烦，比如其中一个用户删除消息，已读回执等操作时，不能去影响其它用户的视角。

► 写扩散：

描述：每个用户有独立的消息列表，每条消息给所有消息关联人同步一份副本。

优点：读取逻辑简单，效率极快，通过用户自身消息列表一次性获取所有离线增量消息即可，用户个性化操作实现简单，不会影响其它用户的视角。

缺点：存储空间增加，写入压力较大。

两种方案如图所示：

对比两种消息扩散方案优缺点都比较明确，同时也都面临无法接受的极端情况，比如读扩散，如果某用户拥有巨量会话，那他每次上线时读取消息就是灾难，再如写扩散，如遇到万人群，每条消息都会产生一万分副本，作为设计者必须根据实际情况从逻辑上去结合两种方案来平衡读写压力。

消息写扩散按需延迟扩散，我们通过登陆时间把用户分类活跃和非活跃，只对活跃用户进行即时写扩散，非活跃用户在上线时做一次补偿同步操作，这样能有效分散消息写入压力，还能对减少僵尸账号进行无意义消息副本同步。

3.3 IMSDK架构构图

IMSDK架构按模块分工可以分为中间件层、核心层、协议层。

►中间件层

负责请求连接时需要的Token，以及对Token的缓存、Token过期更新等逻辑。当App启动之后平台层会设置用户信息到中间件，中间件根据设置的用户信息判断本地是否缓存该用户的Token，如果有则直接用该Token进行连接；如果没有则会请求接口获取Token。获取到之后使用获取到的Token进行连接，连接成功之后将该Token本地缓存，方便下次使用。如果连接过程中服务器端返回Token过期的错误，客户端会删除掉本地缓存的Token，并重新请求Token进行再次连接。

►核心层

包含连接模块、监听模块、API封装模块、日志模块、本地数据库模块。连接模块负责Socket的连接、保活、断线重连、断开、收发消息等操作，连接模块每隔50秒发送一次ping来保活，连接模块重连机制是2秒、4秒、8秒、16秒等2的n次方逐渐增加，当重试次数到10次后会认为当前网络有问题，不再重试，等待监听网络变化或者前后台切换之后再次重试；监听模块当收到会话变更、消息变更、连接状态变更时将变更内容通知到所有注册监听的业务层，业务层根据收到的通知做出相应处理。

API封装模块提供一些SDK基础功能的API到业务层，例如发送消息、撤回消息、删除消息、获取会话未读数、会话草稿等等，业务层调用提供的API完成相关功能。日志模块提供日志采集的API，将每一条日志顺序的记录到日志文件中。日志模块还负责日志文件的创建、删除、保存与上传工作。本地数据库模块负责数据库相关的工作，当上层设置用户信息时，数据库模块会打开相应的数据库，如果没有则会新建。数据库模块负责会话表和消息表的创建，负责会话和消息的增、删、改、查。数据库模块执行操作时会增加一些必要的逻辑到其中，例如，在插入消息时需要更新会话的未读数、会话的最后一条消息；在删除消息时需要更新会话的未读数、会话的最后一条消息；在消息已读功能中需要修改会话的未读数等等。

►协议层

主要负责跟服务端通讯内容的编解码工作，包括消息的编解码、会话的编解码、命令的编解码等工作，协议层将收到的数据进行解析，区分出诸如收到新消息、删除消息、撤回消息、增加会话、删除会话、会话更新等行为，同时将收到的数据解码成消息或者会话Model传递到上层，通知到业务层。

3.4 连接流程图

App需要同App Server进行数据交互，获取IM连接需要的Token数据，并且App Server负责维护业务数据，如用户数据、会话数据、好友关系等；

App通过Token数据与IM Server进行连接，建立数据通道实现消息的实时接收与推送功能；

IM Server维护App的连接状态，在接收实时消息时判断用户是否在线，将消息转发给目标设备或保存为离线消息；

►会话及气泡：

在面对特殊用户会话较多时每次从服务拉取会话信息时将面临较大压力，我们采用本地和服务端结合方案实现，本地缓存一份会话，接收消息对会话气泡进行叠加，本地会话设置发生变更如免打扰，隐藏会话，已读消息等，上报给服务端，服务端在发生好友关系或加入群组等操作时产生会话，或会话信息变更时也会对本地进行同步，服务器和本地之间会话同步包括连接时同步、实时同步、主动同步。

连接时同步：用户每次连接时会向服务器传递会话唯一标识，服务端通过用户传递的标识进行逻辑判断并向用户推送会话数据，包括全部会话和增量会话，SDK接收到会话数据后进行本地的新增、修改、删除操作，并通知给UI层，本地会话“标识”由服务端每次同步会话时提供。

实时同步：本地会话修改会通知给服务端，服务端接收到会话信息变更时，会即时通过IM推送给SDK，其中包括新增、修改、删除会话的操作，SDK接收到会话数据后进行本地的新增、修改、删除操作，并通知给UI层。

主动同步：客户端接收到不存在的会话消息时，会主动向服务器获取此会话信息进行本地保存并通知UI层。

会话设计图：

会话部分字段：

单聊：两个用户之间进行一对一的聊天，聊天消息可以持久化保存至本地进行查看。

群组：两个或两个以上的用户在同一个会话中进行聊天，发送的消息会被群组所有成员接收并可以持久

化保存至本地进行查看。

公众号：企业或官方通过系统账号向单个或多个账号推送消息，消息可以持久化保存至本地进行查看。

聊天室：一个或多个用户在同一个会话中进行聊天，发送的消息会被推送至当前聊天室中所有用户，用户接收端消息不会保存本地。

本地记录每次会话同步时间，连接时服务端根据本地上报最后更新时间对比，增量同步变动过的会话记录，保证本地会话与服务器端保持一致。之家的会话列表体现在个人主页的消息部分，如下：

4.服务器优化

我们系统的设计要求是单机百万连接支持、下行消息QPS一百万。由于一个连接会占用一个文件描述符，首先就要对系统的文件描述符上限做调整，让服务器能够支持百万级连接的建立；

# /etc/security/limits.conf

* soft nporc 1500000

* hard nporc 1500000

* soft nofile 1500000

* hard nofile 1500000

# /etc/sysctl.conf

fs.nr_open = 3000000

fs.file-max = 3000000

我们使用Nginx作为七层负载，并且开启了TLS保障数据的传输安全。当Nginx层作为客户端在与后端应用服务器建立连接的时候，会遇到本地端口瓶颈，可以依据TCP四元组规则，增加后端应用服务器的监听端口，来实现本地端口的复用，从而突破本地端口资源的限制；

在实际压测过车中，客户端接收消息的毛刺问题比较严重，经排查发现nginx服务器有丢包，并且CPU的使用非常不均衡，特别是软中断，只集中在少数CPU上。为解决以上问题前，先了解下网卡收包流程以及相关的一些概念。

网卡收到数据帧后，将数据帧以DMA的方式拷贝到内存的Ring Buffer中，该步骤不需要CPU的参与。当拷贝完成后，网卡便会触发一个网卡硬件中断，CPU必须立即响应硬件中断，CPU根据中断类型，在中断注册表中查找对应的中断处理程序，然后调用网卡注册的中断处理程序(网卡驱动)，此后网卡驱动程序触发一个软中断，自此硬件中断返回，硬中断不会做过多事情，它只负责通知驱动有数据到达，具体的操作由软中断过程来处理。

DMA是Direct Memory Access，直接存储器访问。在DMA出现之前，CPU与外设之间的数据传送方式有程序传送方式、中断传送方式。CPU是通过系统总线与其他部件连接并进行数据传输，DMA就是指外部设备不通过CPU而直接与系统内存交换数据的接口技术。

Ring Buffer网卡环形缓冲区，如果该缓冲区被占满，新到来的数据包将会被丢弃，从而导致丢包。把该缓冲区由原来的512调整到2048后，丢包问题得以解决，方法如下：

查看当前Buffer

ethtool -g em1

Ring parameters for em1:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

ethtool -G em1 rx 2048

ethtool -G em1 tx 2048

修改

ethtool -G em1 rx 4096

ethtool -G em1 tx 4096

4.1 设置网卡队列

对于CPU软中断不均衡，与网卡的设置与CPU的亲和力绑定有直接关系，借用网络一张图先了解下RSS多队列网卡，如下：

当网卡收到报文时，通过Hash包头的SIP、SPort、DIP、DPort四元组信息，将数据投递到相应的网卡队列，同时会触发该队列绑定的中断，通知CPU进一步处理；由此可知CPU使用不均衡，无非就是两个原因，队列收到的数据包不均衡或者CPU与网卡队列绑定不合理导致；

# 设定网卡队列

ethtool -L em1 combined 16

4.2 网卡中断号

Interrupt Request，简称IRQ，中断就是由硬件或软件所发送的中断请求信号。系统上的每个硬件设备都会被分配一个 IRQ 号，通过这个唯一的 IRQ 号就能区是来自哪个硬件了。开启了多队列的网卡，每个队列都会有唯一的中断号。

# 查看网卡队列中断号

cat /proc/interrupts |grep em1 |awk ‘{print $1 $NF}’

4.3 CPU亲和力绑定

把每个网卡队列与CPU一一绑定，均衡CPU的使用

# CPU绑定

echo /proc/irq/107/smp_affinity_list 0

echo /proc/irq/108/smp_affinity_list 1

中断号为107的队列绑定0号CPU，中断号为108的队列绑定1号CPU，依此类推，每个网卡队列都需要绑定到不同的CPU核上，这样我们就完成了网卡队列的设置以及与CPU的绑定。

这里还有个问题是，CPU不紧要处理网路数据，还要处理Nginx应用，这个时候CPU资源的分配要根据具体的压测情况进行调整；

4.4 Intel Flow Director

上面提到投递到网卡队列的数据包是均衡的，如何能做到均衡呢？有个办法是使用Intel以太网FD( Flow Director)技术，自定义数据包投递规则，应用监听多个端口，不同目标端口的数据包按制定的规则投递到相应的网卡队列，从而达到均衡数据包的目的，进而均衡CPU的使用；

# 数据投递规则根据目的端口把数据投递到不同队列

ethtool –features em1 ntuple on

ethtool –config-ntuple em1 flow-type tcp4 dst-port 9500 action 0 loc 1

ethtool –config-ntuple em1 flow-type tcp4 dst-port 9501 action 1 loc 2

至此网卡丢包以及CPU使用率不均衡的问题得到解决，基本就是解决了客户端接收数据毛刺的问题；

4.5 其他优化

对部分需要更高时时性及稳定的用户，如客服、商家号等，可以增加专用服务器来应对，专用服务器通常接入量较小，连接和消息推送都会更稳定快速。

增加备用域名（不同cdn），在连接失败重试过程中使用可有效减少外部网络波动带来的影响，使系统更加稳定可靠。我们之前有一次线上故障，使用的第三方的即时通讯服务，

当时该服务商的一个关键域名被误封，导致整个即时通讯服务不可用，由于处理过程复杂，故障持续了半天的时间才得以恢复。基于此，我们自研的时候，把这部分设计了进去。

为提高连接效率及服务器连接压力SDK增加了token缓存机制，IM连接成功后，会将token进行本地缓存，当设备再次触发连接时，会优先检查本地是否存在token，如存在立刻使用缓存数据进行连接，若不存在或过期会向服务器获取新token数据进行连接，连接成功后将新Token缓存本地。

SDK具备自动重连机制，在整个应用全局只需要调用一次连接即可，连接异常断开后会启动重连机制进行多次重连，在这之后如果仍没有连接成功，还会在当检测到设备网络状态变化时再次进行重连。

心跳保活，为了保持客户端和服务端的实时双向通信，需要确保客户端和服务端之间的TCP通道保持连接不断开，IM连接成功后，SDK每间隔50秒会向服务器发送一个ping包，服务器接收到ping包后立即响应一个pong包，如果服务在120秒内检查没有收到过ping包会立即断开此连接，释放资源。SDK在检测断开后会自动触发重连机制。

发送方->接收方：ping

接收放->发送方：pong

5.总结

本文内容介绍了之家IM即时通信平台部分设计策略，借此机会总结设计方案及技术实践，与大家一起学习提升。目前该项目在之家已经落地两年有余，接入十几条业务线，包含单聊、群聊、聊天室、公众号、通用信令服务等场景，日均服务三端用户在千万级，为之家三端产品提供全双工消息总线基础设施支撑；目前一些个性化产品需求以及相关运营平台仍在不断完善中，如果你对此很有兴趣，欢迎加入我们。

作者简介