早期之家在C端产品的即时通信功能是直接使用第三方商业软件服务（SaaS），功能扩展性上存在很大制约，某些定制化业务需求很难实现，考虑到后续业务发展需要、数据安全、内容实时审核及性能、自主可控高可用架构等因素，决定自主开发IM即时通信平台并逐步迭代替换。
2.1网络通信框架
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端接入
3.很多框架包括Netty都自带实现了websocket协议解码器。
客户端：用户收发消息终端
接入层：为客户端连接、收发消息、关系建立提供入口
数据层：负责各类业务逻辑数据及消息数据缓存或持久化存储，及消息指令的分发渠道。
3.1消息设置
聊天场景常见的消息类型通常有：文本、图片、表情、语音，视频。我们把消息分为消息类型，及消息内容两部分，客户端通过识别消息类型去解析消息内容并展示，像图片视频等消息，并不需要通过消息即时传递其内容，而是先将图片或视频上传到文件服务器，消息中只需要把uri带过去，并且带上base64编码的缩略图即可，如下示例：
msgType:msg_image
消息下发流程如下图：
如图，整体思路是将上行消息通过webapi写入消息队列，socket服务器通过消息队列或离线消息库进行增量消息分发同步。
socket服务承载连接着所有在线用户，发生部署上线将会导致所有在线用户断开重连，瞬间大量增加其它服务器的连接压力，且对部分用户行为可能会有短暂的影响，上行消息通过webAPI实现，统一了消息入口，方便各类渠道消息的接入，并且使得socket服务的职责变得简单单一，仅用于保持连接和推送消息，上行消息业务逻辑频繁变动时仅需要重新部署webAPI，对用户基本无感知。
还有一些建议是，对消息进行合并，压缩能极大提升消息推送吞吐能力，减少带宽占用，经测试十条以上消息压缩率能达到80%左右；细分消息队列，按不同维度拆分消息队列可以分散压力防止某类消息高峰期对其它业务消息造成延迟推送，保证其它消息的时效性，比如可以按场景用户消息，系统指令等各自使用独立的消息队列。
3.2消息扩散
消息扩散分发是im设计的重点，尤其是一对多的场景，如群聊。简单的说就是每条消息需要扩散给群里所有人收到，通常有两种方式，读扩散，写扩散。什么是读扩散？什么是写扩散？
读扩散：
描述：每条消息只存一份，群组所有成员读取这一份数据。
优点：节省存储空间，无写入压力。
缺点：
1.获取离线增量消息逻辑复杂，需要根据用户所有会话关系去遍历获取，且并未知道会话是否有增量消息，会造成大量无效空读，效率极慢。
2.针对消息做单个用户个性化操作时设计会变的麻烦，比如其中一个用户删除消息，已读回执等操作时，不能去影响其它用户的视角。
写扩散：
描述：每个用户有独立的消息列表，每条消息给所有消息关联人同步一份副本。
优点：读取逻辑简单，效率极快，通过用户自身消息列表一次性获取所有离线增量消息即可，用户个性化操作实现简单，不会影响其它用户的视角。
缺点：存储空间增加，写入压力较大。
两种方案如图所示：
对比两种消息扩散方案优缺点都比较明确，同时也都面临无法接受的极端情况，比如读扩散，如果某用户拥有巨量会话，那他每次上线时读取消息就是灾难，再如写扩散，如遇到万人群，每条消息都会产生一万分副本，作为设计者必须根据实际情况从逻辑上去结合两种方案来平衡读写压力。
3.3IMSDK架构构图
IMSDK架构按模块分工可以分为中间件层、核心层、协议层。
中间件层
负责请求连接时需要的Token，以及对Token的缓存、Token过期更新等逻辑。当App启动之后平台层会设置用户信息到中间件，中间件根据设置的用户信息判断本地是否缓存该用户的Token，如果有则直接用该Token进行连接；如果没有则会请求接口获取Token。获取到之后使用获取到的Token进行连接，连接成功之后将该Token本地缓存，方便下次使用。如果连接过程中服务器端返回Token过期的错误，客户端会删除掉本地缓存的Token，并重新请求Token进行再次连接。
核心层
包含连接模块、监听模块、API封装模块、日志模块、本地数据库模块。连接模块负责Socket的连接、保活、断线重连、断开、收发消息等操作，连接模块每隔50秒发送一次ping来保活，连接模块重连机制是2秒、4秒、8秒、16秒等2的n次方逐渐增加，当重试次数到10次后会认为当前网络有问题，不再重试，等待监听网络变化或者前后台切换之后再次重试；监听模块当收到会话变更、消息变更、连接状态变更时将变更内容通知到所有注册监听的业务层，业务层根据收到的通知做出相应处理。
协议层
主要负责跟服务端通讯内容的编解码工作，包括消息的编解码、会话的编解码、命令的编解码等工作，协议层将收到的数据进行解析，区分出诸如收到新消息、删除消息、撤回消息、增加会话、删除会话、会话更新等行为，同时将收到的数据解码成消息或者会话Model传递到上层，通知到业务层。
3.4连接流程图
App需要同AppServer进行数据交互，获取IM连接需要的Token数据，并且AppServer负责维护业务数据，如用户数据、会话数据、好友关系等；
App通过Token数据与IMServer进行连接，建立数据通道实现消息的实时接收与推送功能；
IMServer维护App的连接状态，在接收实时消息时判断用户是否在线，将消息转发给目标设备或保存为离线消息；
会话及气泡：
在面对特殊用户会话较多时每次从服务拉取会话信息时将面临较大压力，我们采用本地和服务端结合方案实现，本地缓存一份会话，接收消息对会话气泡进行叠加，本地会话设置发生变更如免打扰，隐藏会话，已读消息等，上报给服务端，服务端在发生好友关系或加入群组等操作时产生会话，或会话信息变更时也会对本地进行同步，服务器和本地之间会话同步包括连接时同步、实时同步、主动同步。
连接时同步：用户每次连接时会向服务器传递会话唯一标识，服务端通过用户传递的标识进行逻辑判断并向用户推送会话数据，包括全部会话和增量会话，SDK接收到会话数据后进行本地的新增、修改、删除操作，并通知给UI层，本地会话“标识”由服务端每次同步会话时提供。
实时同步：本地会话修改会通知给服务端，服务端接收到会话信息变更时，会即时通过IM推送给SDK，其中包括新增、修改、删除会话的操作，SDK接收到会话数据后进行本地的新增、修改、删除操作，并通知给UI层。
主动同步：客户端接收到不存在的会话消息时，会主动向服务器获取此会话信息进行本地保存并通知UI层。
会话部分字段：
单聊：两个用户之间进行一对一的聊天，聊天消息可以持久化保存至本地进行查看。
群组：两个或两个以上的用户在同一个会话中进行聊天，发送的消息会被群组所有成员接收并可以持久
化保存至本地进行查看。
公众号：企业或官方通过系统账号向单个或多个账号推送消息，消息可以持久化保存至本地进行查看。
聊天室：一个或多个用户在同一个会话中进行聊天，发送的消息会被推送至当前聊天室中所有用户，用户接收端消息不会保存本地。
4.服务器优化
我们系统的设计要求是单机百万连接支持、下行消息QPS一百万。由于一个连接会占用一个文件描述符，首先就要对系统的文件描述符上限做调整，让服务器能够支持百万级连接的建立；
#/etc/security/limits.conf
*softnporc1500000
*hardnporc1500000
*softnofile1500000
*hardnofile1500000
#/etc/sysctl.conf
fs.nr_open=3000000
fs.file-max=3000000
网卡收到数据帧后，将数据帧以DMA的方式拷贝到内存的RingBuffer中，该步骤不需要CPU的参与。当拷贝完成后，网卡便会触发一个网卡硬件中断，CPU必须立即响应硬件中断，CPU根据中断类型，在中断注册表中查找对应的中断处理程序，然后调用网卡注册的中断处理程序(网卡驱动)，此后网卡驱动程序触发一个软中断，自此硬件中断返回，硬中断不会做过多事情，它只负责通知驱动有数据到达，具体的操作由软中断过程来处理。
DMA是DirectMemoryAccess，直接存储器访问。在DMA出现之前，CPU与外设之间的数据传送方式有程序传送方式、中断传送方式。CPU是通过系统总线与其他部件连接并进行数据传输，DMA就是指外部设备不通过CPU而直接与系统内存交换数据的接口技术。
RingBuffer网卡环形缓冲区，如果该缓冲区被占满，新到来的数据包将会被丢弃，从而导致丢包。把该缓冲区由原来的512调整到2048后，丢包问题得以解决，方法如下：
查看当前Buffer
ethtool-gem1
Ringparametersforem1:
Pre-setmaximums:
RX:4096
RXMini:0
RXJumbo:0
TX:4096
Currenthardwaresettings:
ethtool-Gem1rx2048
ethtool-Gem1tx2048
修改
ethtool-Gem1rx4096
ethtool-Gem1tx4096
4.1设置网卡队列
当网卡收到报文时，通过Hash包头的SIP、SPort、DIP、DPort四元组信息，将数据投递到相应的网卡队列，同时会触发该队列绑定的中断，通知CPU进一步处理；由此可知CPU使用不均衡，无非就是两个原因，队列收到的数据包不均衡或者CPU与网卡队列绑定不合理导致；
#设定网卡队列
ethtool-Lem1combined16
4.2网卡中断号
InterruptRequest，简称IRQ，中断就是由硬件或软件所发送的中断请求信号。系统上的每个硬件设备都会被分配一个IRQ号，通过这个唯一的IRQ号就能区是来自哪个硬件了。开启了多队列的网卡，每个队列都会有唯一的中断号。
#查看网卡队列中断号
4.3CPU亲和力绑定
把每个网卡队列与CPU一一绑定，均衡CPU的使用
#CPU绑定
echo/proc/irq/107/smp_affinity_list0
echo/proc/irq/108/smp_affinity_list1
中断号为107的队列绑定0号CPU，中断号为108的队列绑定1号CPU，依此类推，每个网卡队列都需要绑定到不同的CPU核上，这样我们就完成了网卡队列的设置以及与CPU的绑定。
这里还有个问题是，CPU不紧要处理网路数据，还要处理Nginx应用，这个时候CPU资源的分配要根据具体的压测情况进行调整；
4.4IntelFlowDirector
上面提到投递到网卡队列的数据包是均衡的，如何能做到均衡呢？有个办法是使用Intel以太网FD(FlowDirector)技术，自定义数据包投递规则，应用监听多个端口，不同目标端口的数据包按制定的规则投递到相应的网卡队列，从而达到均衡数据包的目的，进而均衡CPU的使用；
#数据投递规则根据目的端口把数据投递到不同队列
至此网卡丢包以及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.总结
作者简介
林道辉
■C端及中台产研中心-看选技术团队
■2012年加入汽车之家，目前主要负责参与热聊业务及之家im通信平台架构及研发工作。