100万级连接，爱奇艺WebSocket网关如何架构

说在前面

在40岁老架构师尼恩的读者社区(50+)中，很多小伙伴拿到一线互联网企业如阿里、网易、有赞、希音、百度、滴滴的面试资格。

最近，尼恩指导一个小伙伴简历，写了一个《高并发网关项目》，此项目帮这个小伙拿到 字节/阿里/微博/汽车之家 面邀，所以说，这是一个牛逼的项目。

为了帮助大家拿到更多面试机会，拿到更多大厂offer，

尼恩决定：9月份给大家出一章视频介绍这个项目的架构和实操，《33章：10Wqps 高并发 Netty网关架构与实操》，预计月底发布。然后，提供一对一的简历指导，这里简历金光闪闪、脱胎换骨。

《33章：10Wqps 高并发 Netty网关架构与实操》海报如下：

配合《33章：10Wqps 高并发 Netty网关架构与实操》，尼恩会梳理几个工业级、生产级网关案例，作为架构素材、设计的素材。

前面梳理了

《日流量200亿，携程网关的架构设计》
《千万级连接，知乎如何架构长连接网关？》
《日200亿次调用，喜马拉雅网关的架构设计》

除了以上的三个案例，这里，尼恩又找到一个漂亮的生产级案例：

《爱奇艺WebSocket实时推送网关技术实践》，

注意，这又一个非常牛逼的工业级、生产级网关案例。

这些案例，并不是尼恩的原创。这些案例，仅仅是尼恩在《33章：10Wqps 高并发 Netty网关架构与实操》备课的过程中，在互联网查找资料的时候，收集起来的，供大家学习和交流使用。

《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公号【技术自由圈】获取

文章目录

- 说在前面
- 100W级连接，爱奇艺WebSocket推送网关架构
- 1、旧方案存在的技术痛点
- 2、新方案的技术目标
- 3、新方案的技术选型
- 4、新方案的实现思路
- - 4.1 系统架构
  - 4.2 会话管理
  - 4.3 监控与报警
- 5、新方案的性能压测
- 6、新方案的实际应用案例
- 7、总结
- 说在最后：有问题可以找老架构取经
- 推荐阅读

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，将连接数和用户数作为自定义指标暴露，供Prometheus进行采集，从而实现了与现有的微服务监控系统打通。

在Grafana中，可以方便地查看连接数、用户数、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