目录
100W级连接，爱奇艺WebSocket推送网关架构
HTTP 协议属于一种无状态、基于 TCP 的请求/响应模式的协议，
HTTP 协议中，只有客户端能发起请求，由服务端进行回应。
虽然，在许多情况下，这种请求/响应的拉取模式能够满足需求。
然而，在特定情况下，例如实时通知（如 IM 中的离线消息推送最为典型）和消息推送等应用场景，需要将数据实时推到客户端，这就要求服务端具备主动推送数据的能力。
如何推呢？
传统的 Web 服务端推送技术，包括短轮询、长轮询等，虽然能在一定程度上解决问题，但也存在如时效性、资源浪费等问题。
HTML5 标准推出的 WebSocket 规范基本改变了这种状况，已经成为当前服务端消息推送技术的主流。
本文将分享爱奇艺在基于 Netty 实现 WebSocket 长连接实时推送网关过程中的实践经验和总结。
1、旧方案存在的技术痛点
爱奇艺号作为我们内容生态的关键部分，作为前端系统，对用户体验有着较高的要求，这直接影响着创作者的创作热情。
当前，爱奇艺号在多个业务场景中应用了 WebSocket 实时推送技术，包括：
1）用户评论：实时地将评论消息推送至浏览器；
2）实名认证：在合同签署前，需要对用户进行实名认证，用户扫描二维码后进入第三方的认证页面，认证完成后异步通知浏览器认证状态；
3）活体识别：类似于实名认证，当活体识别完成后，异步将结果通知浏览器。
在实际业务开发中，我们发现 WebSocket 实时推送技术在使用过程中存在一些问题。
这些问题是：
1）首先：WebSocket 技术栈不统一，既有基于 Netty 实现的，也有基于 Web 容器实现的，给开发和维护带来困难；
2）其次：WebSocket 实现分散在各个工程中，与业务系统紧密耦合，如果有其他业务需要集成 WebSocket，将面临重复开发的困境，浪费成本、效率低下；
3）第三：WebSocket 是有状态协议，客户端连接服务器时只与集群中一个节点连接，数据传输过程中也只与这一节点通信。WebSocket 集群需要解决会话共享的问题。如果只采用单节点部署，虽然可以避免这一问题，但无法水平扩展以支持更高的负载，存在单点故障风险；
4）最后：最后：缺乏监控与报警，虽然可以通过 Linux 的 Socket 连接数大致评估 WebSocket 长连接数，但数字并不准确，也无法得知用户数等具有业务含义的指标数据；无法与现有的微服务监控整合，实现统一监控和报警。
2、新方案的技术目标
如上所述，为了解决旧方案中存在的问题，我们需要实现统一的 WebSocket 长连接实时推送网关。
这套新的网关需要具备以下特点：
1）集中实现长连接管理和推送能力：采用统一的技术栈，将长连接作为基础功能进行沉淀，以便于功能的迭代和维护；
2）与业务解耦：将业务逻辑与长连接通信分离，使得业务系统无需关心通信细节，避免了重复开发，节约了研发成本；
3）使用简单：提供 HTTP 推送通道，便于各种开发语言的接入。业务系统只需进行简单的调用，便可实现数据推送，从而提高研发效率；
4）分布式架构：构建多节点的集群，支持水平扩展以应对业务增长带来的挑战；节点故障不会影响服务的整体可用性，确保高可靠性；
5）多端消息同步：允许用户使用多个浏览器或标签页同时登录在线，确保消息同步发送；
6）多维度监控与报警：将自定义监控指标与现有的微服务监控系统连接，当出现问题时可以及时报警，保证服务的稳定性。
3、新方案的技术选型
在众多的 WebSocket 实现中，经过对性能、扩展性、社区支持等各方面的权衡，我们最终确定了 Netty。
Netty 是一个高性能、事件驱动、异步非阻塞的网络通信框架，已在许多知名的开源项目中得到广泛应用。
WebSocket 具有状态特性，这与 HTTP 的无状态特性不同，因此无法像 HTTP 一样通过集群方式实现负载均衡。在长连接建立后，它会与服务端的某个节点保持会话，所以在集群环境下，要确定会话属于哪个节点会有些困难。
解决以上问题一般有两种技术方案：
1）一种是使用类似于微服务注册中心的技术来维护全局的会话映射关系；
2）另一种是使用事件广播，由各节点自行判断是否持有会话。这两种方案的对比如下表所示。
WebSocket集群方案：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 注册中心 | 会话映射关系清晰，集群规模较大时更合适 | 实现复杂，强依赖注册中心，有额外运维成本 |
| 事件广播 | 实现简单更加轻量 | 节点较多时，所有节点均被广播，资源浪费 |
考虑到实现成本和集群规模，我们选择了轻量级的事件广播方案。
实现广播的方法有多种，如基于 RocketMQ 的消息广播、基于 Redis 的 Publish/Subscribe、基于 ZooKeeper 的通知等。
这些方案的优缺点对比如下表所示。在考虑到吞吐量、实时性、持久化和实现难易程度等因素后，我们最终选择了 RocketMQ。
广播的实现方案对比：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 基于RocketMQ | 吞吐量高、高可用、保证可靠 | 实时性不如Redis |
| 基于Redis | 实时性高、实现简单 | 不保证可靠 |
| 基于ZooKeeper | 实现简单 | 写入性能较差，不适合频繁写入场景 |
4、新方案的实现思路
4.1 系统架构
网关的整体架构如下图所示：
网关的整体流程如下：
1）客户端与网关的任何一个节点建立长连接，节点会将其加入到内存中的长连接队列。客户端会定期向服务端发送心跳消息，若超过设定时间还未收到心跳，则认为客户端与服务端的长连接已断开，服务端会关闭连接，清理内存中的会话。
2）当业务系统需要向客户端推送数据时，通过网关提供的HTTP接口将数据发送至网关。
3）在收到推送请求后，网关会将消息写入RocketMQ。
4）网关作为消费者，以广播模式消费消息，所有节点都能收到消息。
5）节点在收到消息后会判断推送的消息目标是否在其内存中维护的长连接队列里，如果存在则通过长连接推送数据，否则直接忽略。
网关通过多节点构成集群，每个节点负责一部分长连接，实现负载均衡。当面临大量连接时，也可以通过增加节点来分散压力，实现水平扩展。
同时，当节点出现故障时，客户端会尝试与其他节点重新建立长连接，确保服务的整体可用性。
4.2 会话管理
在 WebSocket 长连接建立后，会话信息会保存在各个节点的内存中。
SessionManager 组件负责管理会话，它内部使用哈希表来维护 UID 与 UserSession 的关联。
UserSession 表示用户层面的会话，一个用户可能同时拥有多个长连接，因此 UserSession 内部同样使用哈希表来维护 Channel 与 ChannelSession 的关联。
为了防止用户无休止地创建长连接，当 UserSession 内部的 ChannelSession 超过一定数量时，它会关闭最早建立的 ChannelSession，以减少服务器资源的占用。
SessionManager、UserSession、ChannelSession 的关系如下图所示。
SessionManager组件：
4.3 监控与报警
为了掌握集群中建立的长连接数量和包含的用户数量，网关提供了基本的监控和报警功能。
网关接入了 Micrometer (https://www.oschina.net/p/micrometer?hmsr=aladdin1e1)，将连接数和用户数作为自定义指标暴露，供 Prometheus (https://prometheus.io/)进行采集，从而实现了与现有的微服务监控系统打通。
在Grafana (https://grafana.com/)中，可以方便地查看连接数、用户数、JVM、CPU、内存等指标数据，了解网关当前的服务能力和压力。报警规则也可以在 Grafana 中配置，当数据异常时触发奇信（内部报警平台）报警。
5、新方案的性能压测
压测准备：
-
1）选择两台配置为 4 核 16G 的虚拟机，分别作为服务器和客户端；
-
2）在压力测试时，为网关开放 20 个端口，同时启动 20 个客户端；
-
3）每个客户端使用一个服务器端口建立 5 万个连接，从而可以同时创建百万个连接。
连接数（百万级）与内存使用情况如下图所示：
[root@sy-dev-1de4f0c2a target]# ss -s ; free -h
Total: 1002168 (kernel 1002250)
TCP: 1002047 (estab 1002015, closed 4, orphaned 0, synrecv 0, timewait 4/0), ports 0
Transport Total IP IPv6
* 1002250 - -
RAW 0 0 0
UDP 4 2 2
TCP 1002043 1002041 2
INET 1002047 1002043 4
FRAG 0 0 0
total used free shared buff/cache available
Mem: 15G 4.5G 4.5G 232K 6.5G 8.2G
Swap: 4.0G 14M 4.0G
给百万个长连接同时发送一条消息，采用单线程发送，服务器发送完成的平均耗时在10s左右，如下图所示。
服务器推送耗时：
2021-01-25 20:51:02.614 INFO [mp-tcp-gateway,54d52e7e4240b65a,54d52e7e4240b65a,false]
[600ebeb62@2559f4507adee3b316c571/507adee3b316c571] 89558 --- [nio-8080-exec-6]
c.i.m.t.g.controller.NotifyController: [] [UID:] send message ...
2021-01-25 20:51:11.973 INF0 [mp-tcp-gateway,54d52e7e4240b65a,54d52e7e4240b65a,false]
[1600ebeb62@2559f4507adee3b316c571/507adee3b316c571] 89558 --- [nio-8080-exec-6]
c.i.m.t.g.controller.NotifyController: [] [UID:] send message to 1001174 channels
一般同一用户同时建立的长连接都在个位数。
以10个长连接为例，在并发数600、持续时间120s条件下压测，推送接口的TPS大约在1600+，如下图所示。
长连接10、并发600、持续时间120s的压测数据：
当前的性能指标已满足我们的实际业务场景，可支持未来的业务增长。
6、新方案的实际应用案例
为了更形象地展示优化效果，文章最后，我们以封面图添加滤镜效果为例，介绍了一个爱奇艺号采用新 WebSocket 网关方案的实例。
爱奇艺号自媒体在发布视频时，可以选择为封面图添加滤镜效果，引导用户提供更高质量的封面。
当用户选择封面图后，会提交一个异步的后台处理任务。
一旦异步任务完成，通过 WebSocket 将不同滤镜效果处理后的图片返回给浏览器，业务场景如下图所示。
从研发效率的角度来看，如果在业务系统中集成 WebSocket，至少需要 1-2 天的开发时间。
而直接使用新的 WebSocket 网关的推送功能，只需简单的接口调用就能实现数据推送，将开发时间降低到分钟级别，大幅提高研发效率。
从运维成本的角度来看，业务系统不再包含与业务逻辑无关的通信细节，代码的可维护性更强，系统架构变得更简单，运维成本大幅降低。
7、总结
WebSocket 是实现服务端推送的主流技术，适当使用可以有效提升系统响应能力，增强用户体验。
通过 WebSocket 长连接网关，可以迅速为系统增加数据推送能力，有效降低运维成本，提高开发效率。
长连接网关的价值在于：
-
1）它封装了 WebSocket 通信细节，与业务系统解耦，使得长连接网关与业务系统可独立优化迭代，避免重复开发，便于开发与维护；
-
2）网关提供了简单易用的 HTTP 推送通道，支持多种开发语言接入，便于系统集成和使用；
-
3）网关采用了分布式架构，可以实现服务的水平扩容、负载均衡与高可用；
-
4）网关集成了监控与报警，当系统异常时能及时预警，确保服务的健康和稳定。
目前，新的 WebSocket 长连接实时网关已在爱奇艺号图片滤镜结果通知、MCN 电子签章等多个业务场景中得到应用。
未来还有许多方面需要探索，例如消息的重发与 ACK、WebSocket 二进制数据的支持、多租户的支持等。
400
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
