构建通用WebSocket推送网关的设计与实践

HTTP协议是一种无状态的、基于TCP的请求/响应模式的协议，请求只能由客户端发起、服务端进行响应。在大多数场景，这种请求/响应的Pull模式已经可以满足需求。但在某些情形，例如消息推送、通知等应用场景，需要实时将数据同步到客户端，这就要求服务端支持主动Push数据。

服务端推送技术历史悠久，经历了短轮询、长轮询的发展，一定程度上能够解决问题，但也存在着不足，例如时效性、资源浪费等。HTML5标准带来的WebSocket规范基本结束了这一局面，成为目前服务端推送技术的主流方案。

在系统中集成WebSocket十分简单，相关讨论与资料很丰富。但如何实现一个通用的WebSocket推送网关尚未有成熟的方案。目前的云服务厂商主要关注iOS和安卓等移动端推送，也缺少对WebSocket的支持。本文介绍了我们基于Netty实现WebSocket长连接网关时的一些思考和经验。

1 爱奇艺号WebSocket使用现状

爱奇艺号是爱奇艺内容创作、分发和变现的平台，涵盖自媒体、网大、网剧、儿童、知识、纪录片等多个业务，是爱奇艺内容生态的重要组成。爱奇艺号作为前台系统，对用户体验有较高要求，直接影响着创作者的创作热情。目前，爱奇艺号有多个业务场景中用到了WebSocket推送技术，包括：

• 用户评论。实时的将评论消息推送到浏览器。

• 实名认证。合同签署前需要对用户进行实名认证，用户扫描二维码后进入第三方的认证页面，认证完成后异步通知浏览器认证的状态。

• 活体识别。类似实名认证，当活体识别完成后，异步将结果通知浏览器。

在实际的业务开发中，我们发现，WebSocket推送技术在使用中存在以下问题：首先，WebSocket技术栈不统一，既有基于Netty实现的，也有基于Web容器实现的，给开发和维护带来困难；其次，WebSocket实现分散在在各个工程中，与业务系统强耦合，如果有其他业务需要集成WebSocket，面临着重复开发的窘境，浪费成本、效率低下；第三，WebSocket是有状态协议的，客户端连接服务器时只和集群中一个节点连接，数据传输过程中也只与这一节点通信。

因此，WebSocket集群需要解决会话共享的问题。如果只采用单节点部署，虽然可以避免这一问题，但无法水平扩展支撑更高负载，有单点的风险；最后，缺乏监控与报警，虽然可以通过Linux的Socket连接数大致评估WebSocket长连接数，但数字并不准确，也无法得知用户数等具有业务含义的指标数据；无法与现有的微服务监控整合，实现统一监控和报警。

2 长连接网关的设计与实现

为了解决以上问题，我们实现了统一的WebSocket长连接网关，具备如下特点：

1. 集中实现长连接管理和推送能力。统一技术栈，将长连接作为基础能力沉淀，便于功能迭代和升级维护。

2. 与业务解耦。将业务逻辑与长连接通信分离，使业务系统不再关心通信细节，也避免了重复开发，浪费研发成本。