转转客服 IM 系统的 WebSocket 集群架构设计和部署方案
本文由转转技术李帅分享，原题“转转客服 IM 的 WebSocket 集群部署方案”，下文有修订和重新排版。
1、引言
转转作为国内头部的二手闲置交易平台，拥有上亿的用户。用户在使用转转 app 遇到问题时，一般可以通过在线客服、热线电话等方式联系转转客服并解决问题。
客服 IM 系统是转转自研的在线客服系统，是用户和转转客服沟通的重要工具，主要包括机器人客服、人工客服、会话分配、技能组管理等功能。在这套系统中，我们使用了很多开源框架和中间件，今天讲一下客服 IM 系统中 WebSocket 集群的的实践和应用。
2、快速认识 WebSocket
2.1 WebSocket 诞生背景
早期，很多网站为了实现推送技术，所用的技术都是轮询（也叫短轮询）。轮询是指由浏览器每隔一段时间向服务器发出 HTTP 请求，然后服务器返回最新的数据给客户端。
常见的轮询方式分为轮询与长轮询，它们的区别如下图所示：
为了更加直观感受轮询与长轮询之间的区别，我们来看一下具体的代码：
这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而 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 的关系显然不是这三两句话可以说的清，有兴趣的读者可以详读下面这两篇：
《WebSocket 详解（四）：刨根问底 HTTP 与 WebSocket 的关系(上篇)》
《WebSocket 详解（五）：刨根问底 HTTP 与 WebSocket 的关系(下篇)》
3.2 WebSocket 与长轮询有什么区别？
长轮询就是：客户端发起一个请求，服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断请求的数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则等待一定的时间后才返回。
长轮询的本质还是基于 HTTP 协议，它仍然是一个一问一答（请求 — 响应）的模式。而 WebSocket 在握手成功后，就是全双工的 TCP 通道，数据可以主动从服务端发送到客户端。
要理解 WebSocket 与长轮询的区别，需要深刻理解长轮询的技术原理，以下 3 篇中有关长轮询的技术介绍建议深入阅读：
《Comet 技术详解：基于 HTTP 长连接的 Web 端实时通信技术》
《新手入门贴：史上最全 Web 端即时通讯技术原理详解》
《Web 端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《网页端 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 实例间的消息可靠投递，也可以详细参考下面的资料：
闲鱼亿级 IM 消息系统的可靠投递优化实践
融云技术分享：全面揭秘亿级 IM 消息的可靠投递机制
一套亿级用户的 IM 架构技术干货(上篇)：整体架构、服务拆分等
一套亿级用户的 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 系统，不仅要保证消息的实时性，消息的一致性、顺序性也很重要，还有网络异常等情况下的重连、用户心跳检测等，这些功能需要客户端同学一起协作才能完成。（本文已同步发布于：http://www.52im.net/thread-4860-1-1.html）
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 系统的实时性？
还未添加个人签名 2019-08-26 加入
开源IM框架MobileIMSDK、BeautyEye的作者。
评论