本文由转转技术李帅分享，原题“转转客服IM的WebSocket集群部署方案”，下文有修订和重新排版。

1、引言

转转作为国内头部的二手闲置交易平台，拥有上亿的用户。用户在使用转转app遇到问题时，一般可以通过在线客服、热线电话等方式联系转转客服并解决问题。

客服IM系统是转转自研的在线客服系统，是用户和转转客服沟通的重要工具，主要包括机器人客服、人工客服、会话分配、技能组管理等功能。在这套系统中，我们使用了很多开源框架和中间件，今天讲一下客服IM系统中WebSocket集群的的实践和应用。

2、快速认识WebSocket

2.1 WebSocket 诞生背景

早期，很多网站为了实现推送技术，所用的技术都是轮询（也叫短轮询）。轮询是指由浏览器每隔一段时间向服务器发出 HTTP 请求，然后服务器返回最新的数据给客户端。

常见的轮询方式分为轮询与长轮询，它们的区别如下图所示：

为了更加直观感受轮询与长轮询之间的区别，我们来看一下具体的代码：

PS：关于短轮询、长轮询技术的前世今身，可以详细读这两篇：《新手入门贴：史上最全Web端即时通讯技术原理详解》、《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》。

比较新的轮询技术是 Comet。这种技术虽然可以实现双向通信，但仍然需要反复发出请求。而且在 Comet 中普遍采用的 HTTP 长连接也会消耗服务器资源。

在这种情况下，HTML5 定义了 WebSocket 协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯。

Websocket 使用 ws 或 wss 的统一资源标志符（URI），其中 wss 表示使用了 TLS 的 Websocket。

如：

ws://echo.websocket.org

wss://echo.websocket.org

WebSocket 与 HTTP 和 HTTPS 使用相同的 TCP 端口，可以绕过大多数防火墙的限制。

默认情况下：

• 1）WebSocket 协议使用 80 端口；
• 2）若运行在 TLS 之上时，默认使用 443 端口。

2.2 WebSocket 简介

WebSocket 是一种网络传输协议，可在单个 TCP 连接上进行全双工通信，位于 OSI 模型的应用层。WebSocket 协议在 2011 年由 IETF 标准化为 RFC 6455，后由 RFC 7936 补充规范。

WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就可以创建持久性的连接，并进行双向数据传输。

介绍完轮询和 WebSocket 的相关内容之后，接下来用一张图看一下 XHR Polling（短轮询） 与 WebSocket 之间的区别。

XHR Polling与 WebSocket 之间的区别如下图所示：

2.3 WebSocket 优点

普遍认为，WebSocket的优点有如下几点：

• 1）较少的控制开销：在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小；
• 2）更强的实时性：由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于 HTTP 请求需要等待客户端发起请求服务端才能响应，延迟明显更少；
• 3）保持连接状态：与 HTTP 不同的是，WebSocket 需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息；
• 4）更好的二进制支持：WebSocket 定义了二进制帧，相对 HTTP，可以更轻松地处理二进制内容；
• 5）可以支持扩展：WebSocket 定义了扩展，用户可以扩展协议、实现部分自定义的子协议。

由于 WebSocket 拥有上述的优点，所以它被广泛地应用在即时通讯/IM、实时音视频、在线教育和游戏等领域。

对于前端开发者来说，要想使用 WebSocket 提供的强大能力，就必须先掌握 WebSocket API，下面带大家一起来认识一下 WebSocket API。

PS：如果你想要更浅显的WebSocket入门教程，可以先读这篇《新手快速入门：WebSocket简明教程》后，再回来继续学习。

3、WebSocket的易错常识

3.1 WebSocket 与 HTTP 有什么关系？

WebSocket 是一种与 HTTP 不同的协议。两者都位于 OSI 模型的应用层，并且都依赖于传输层的 TCP 协议。

虽然它们不同，但是 RFC 6455 中规定：WebSocket 被设计为在 HTTP 80 和 443 端口上工作，并支持 HTTP 代理和中介，从而使其与 HTTP 协议兼容。 为了实现兼容性，WebSocket 握手使用 HTTP Upgrade 头，从 HTTP 协议更改为 WebSocket 协议。

既然已经提到了 OSI（Open System Interconnection Model）模型，这里分享一张很生动、很形象描述 OSI 模型的示意图（如下图所示）。

（图片引用自：
https://www.networkingsphere.com/2019/07/what-is-osi-model.html）

当然，WebSocket与HTTP的关系显然不是这三两句话可以说的清，有兴趣的读者可以详读下面这两篇：

1. 《WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇)》
2. 《WebSocket详解（五）：刨根问底HTTP与WebSocket的关系(下篇)》

3.2 WebSocket 与长轮询有什么区别？

长轮询就是：客户端发起一个请求，服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断请求的数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则等待一定的时间后才返回。

长轮询的本质还是基于 HTTP 协议，它仍然是一个一问一答（请求 — 响应）的模式。而 WebSocket 在握手成功后，就是全双工的 TCP 通道，数据可以主动从服务端发送到客户端。

要理解WebSocket 与长轮询的区别，需要深刻理解长轮询的技术原理，以下3篇中有关长轮询的技术介绍建议深入阅读：

1. 《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
2. 《新手入门贴：史上最全Web端即时通讯技术原理详解》
3. 《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
4. 《网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket》

3.3 什么是 WebSocket 心跳？

网络中的接收和发送数据都是使用 Socket 进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。

可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。

所谓 “心跳” 就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己 “在线”，以确保链接的有效性。

而所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息，如果服务端几分钟内没有收到客户端信息则视客户端断开。

在 WebSocket 协议中定义了 心跳 Ping 和 心跳 Pong 的控制帧：

• 1）心跳 Ping 帧包含的操作码是 0x9：如果收到了一个心跳 Ping 帧，那么终端必须发送一个心跳 Pong 帧作为回应，除非已经收到了一个关闭帧。否则终端应该尽快回复 Pong 帧；
• 2）心跳 Pong 帧包含的操作码是 0xA：作为回应发送的 Pong 帧必须完整携带 Ping 帧中传递过来的 “应用数据” 字段。

针对第2）点：如果终端收到一个 Ping 帧但是没有发送 Pong 帧来回应之前的 Ping 帧，那么终端可以选择仅为最近处理的 Ping 帧发送 Pong 帧。此外，可以自动发送一个 Pong 帧，这用作单向心跳。

PS：这里有篇WebSocket心跳方面的IM实战总结文章，有兴趣可以阅读《Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？》。

3.4 Socket 是什么？

网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个 Socket（套接字），因此建立网络通信连接至少要一对端口号。

Socket 本质：是对 TCP/IP 协议栈的封装，它提供了一个针对 TCP 或者 UDP 编程的接口，并不是另一种协议。通过 Socket，你可以使用 TCP/IP 协议。

百度百科上关于Socket的描述是这样：

Socket 的英文原义是“孔”或“插座”：作为 BSD UNIX 的进程通信机制，取后一种意思。通常也称作”套接字“，用于描述IP地址和端口，是一个通信链的句柄，可以用来实现不同虚拟机或不同计算机之间的通信。

在Internet 上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个Socket，并绑定到一个端口上，不同的端口对应于不同的服务。Socket 正如其英文原义那样，像一个多孔插座。一台主机犹如布满各种插座的房间，每个插座有一个编号，有的插座提供 220 伏交流电， 有的提供 110 伏交流电，有的则提供有线电视节目。 客户软件将插头插到不同编号的插座，就可以得到不同的服务。

关于 Socket，可以总结以下几点：

• 1）它可以实现底层通信，几乎所有的应用层都是通过 socket 进行通信的；
• 2）对 TCP/IP 协议进行封装，便于应用层协议调用，属于二者之间的中间抽象层；
• 3）TCP/IP 协议族中，传输层存在两种通用协议: TCP、UDP，两种协议不同，因为不同参数的 socket 实现过程也不一样。

下图说明了面向连接的协议的套接字 API 的客户端/服务器关系：

PS：要说WebSocket和Socket的关系，这篇《WebSocket详解（六）：刨根问底WebSocket与Socket的关系》有专门进行详细分享，建议阅读。

4、选择WebSocket协议

IM是实时通信（Instant Messaging）的简称，实时是IM系统的基本要求（详见《什么是IM系统的实时性？》）。在客服系统中，用户和客服实时收发消息，是最基础、最重要的功能。

WebSocket（以下简称ws）是一种在单个TCP连接上进行全双工通信的协议，允许服务端主动向客户端推送数据。能够以较小的开销，实现更强的实时性。因此客服IM系统采用了ws协议，实现了服务端同时接收与发送数据的能力。

5、WebSocket服务的集群式部署

在实际生产环境中，我们不可能使用单台服务器做ws服务，一旦出现问题就是毁灭性的，所以我们会使用集群式部署ws服务。

ws协议是全双工通信协议，可以双向通信的，部署多台机器后，如下图所示，不同用户会分别和不同的机器连接，A如何向C发送消息呢？

具体是：

• 1）我们在nginx配置中，将ws服务的负载均衡策略设置为ip_hash，保证用户在IP不变的情况，一直分配在一个固定服务器上；
• 2）用户与ws服务建立连接后，获取当前机器hostname，将用户uid与机器hostname关系存储在redis中；
• 3）每个ws服务都维护了一个独立的consumer，采用广播消费模式，仅消费属于自己tag的消息，tag即为当前机器hostname。

6、IM消息在集群架构下发送流程

IM消息在当前集群架构下的发送流程是这样的。

1）用户A在向用户C发送消息时，用户A将消息发送给ws-1服务器，ws-1服务接收消息后，从redis中获取用户C的连接信息。

2）ws-1服务器拿到用户C和ws-2的关系后，设置mq消息tag="ws-2"，直接将用户消息通过mq发送出去。

3）ws-2服务器的consumer接收到对应mq消息后，即可通过ws连接将消息推送用户C 至此，我们就完成了一条消息的发送与接收。

关于集群架构下IM实例间的消息可靠投递，也可以详细参考下面的资料：

1. 闲鱼亿级IM消息系统的可靠投递优化实践
2. 融云技术分享：全面揭秘亿级IM消息的可靠投递机制
3. 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等
4. 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

7、集群架构下的断线重连逻辑

网络环境错综复杂，难免会有网络掉线、网络环境切换的情况，都会导致用户和ws服务的连接发生变化。

一个比较典型的场景就是C端用户网络在4G和wifi之间进行切换，会导致ip变化，从而可能到导致用户和另外的ws服务再次建立连接。这种情况可能会导致消息重复发送、以及额外的资源消耗，所以要尽量避免。

处理方式如下：

• 1）即时清理：用户与ws服务建立连接时，当前ws服务查询redis中存储的用户连接信息。当连接信息与当前ws服务不一致时，当前ws服务更新redis存储信息、并发出广播mq消息，通知其他ws服务关闭与当前用户的连接通道。
• 2）定时清理：除此之外，还需要前端同学配合，定时向连接的ws服务发送心跳消息，ws服务定时检测用户连接的心跳情况，关闭废弃的用户连接。

关于WebSocket的断线快速重连，这里还有篇文章可一并阅读：《Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？》。

8、本文小结

以上就是我们在客服IM系统中使用WebSocket协议实现的消息收发的主要流程。要实现一个完整的IM系统，不仅要保证消息的实时性，消息的一致性、顺序性也很重要，还有网络异常等情况下的重连、用户心跳检测等，这些功能需要客户端同学一起协作才能完成。

9、参考资料

[1] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket

[2] 搞懂现代Web端即时通讯技术一文就够：WebSocket、socket.io、SSE

[3] 万字长文，一篇吃透WebSocket：概念、原理、易错常识、动手实践

[4] WebSocket从入门到精通，半小时就够！

[5] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？

[6] 为何基于TCP协议的移动端IM仍然需要心跳保活机制？

[7] 一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等

[8] 阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践

[9] 万字长文：手把手教你实现一套高效的IM长连接自适应心跳保活机制

[10] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[11] 一套原创分布式即时通讯(IM)系统理论架构方案

[12] 转转平台IM系统架构设计与实践(一)：整体架构设计

[13] 转转平台IM系统架构设计与实践(二)：详细设计与实现

[14] 支持百万人超大群聊的Web端IM架构设计与实践

[15] 一套分布式IM即时通讯系统的技术选型和架构设计

[16] 一套十万级TPS的IM综合消息系统的架构实践与思考

[17] 得物从0到1自研客服IM系统的技术实践之路

[18] 闲鱼亿级IM消息系统的可靠投递优化实践

[19] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[20] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[21] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[22] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[23] 什么是IM系统的实时性？

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：
https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：
http://www.52im.net/thread-4860-1-1.html）