实战经验分享：打造千万级直播项目，如何选择适合的长连接技术，告别CRUD开发

前言

其实不管大厂、小厂，做业务开发的同学都知道，写一个功能，有中台，有架构，有API，有SDK，很多可复用的代码直接调一下RPC接口或者一个注解就搞定了复杂的操作，所以很多螺丝钉们都没法真正接触底层核心组件、功能的设计和编写，更别谈在项目中会有什么技术选型、做决策、落地的操作，长此以往，技术广度、深度、落地能力 一个都没锻炼出来，所以为什么说大厂中P7是个分水岭，这句话不是毫无道理的。

业务场景

先说这一次的业务场景，不讲业务场景空谈选型方案的都是耍流氓。

1. 需要实现直播房间内服务端与客户端之间的数据通信
2. 需要一个延迟很低/实时的通信方案
3. 通信需要支持双向流
4. 对用户客户端设弱网抗性要强
5. 性能要很强，支持高并发操作，大规模长连接集群
6. 服务端与客户端之间接口兼容与版本迭代方便

带着这几个业务场景，我们开始进行选型操作

长连接调研

Http长连接

在 HTTP 协议中，使用 Keep-Alive 或者 Connection: keep-alive 参数来实现长连接。

优势

1. 简单易用，不需要额外的协议支持。
2. 操作简单，适用于轻量级的网络应用场景。

缺点

1. 只能在客户端主动发起请求时才能使用。
2. 无法在服务器端主动推送。

TCP 长连接

优势

1. 实时性较高，可以实现双向通信。
2. 对于大规模并发连接场景，TCP 长连接占用的资源相对较少。

缺点

1. 协议级别上不支持心跳检测、消息推送、断线重连等功能，需要业务代码自行实现。
2. 难以处理跨网络环境的 NAT 等问题。

Comet

Comet 是一种以 Ajax 技术为基础的服务器推送技术，通过长轮询、短轮询等方式实现服务器向客户端推送数据，适用于消息推送、在线聊天等应用场景。

优势

1. 实时性较高，可以实现双向通信。
2. 可以通过 HTTP 协议进行通信，在网络环境复杂的情况下更加稳定。

缺点

1. 需要对 HTTP 协议进行 hack，增加了很多复杂度，也可能存在安全隐患。
2. 需要考虑服务器的负载均衡和可靠性等问题，比较复杂。

MQTT

MQTT 是一种轻量级的发布/订阅协议，可以在低带宽和不稳定网络环境下使用，适用于物联网、移动应用等场景。

优势

1. 非常适合物联网场景，支持大量连接和消息推送。
2. 对网络带宽的占用相对较小。
3. 通信效率高、开销小、支持 QoS2 消息传输。

缺点

1. 需要引入 MQTT 协议栈，对客户端和服务器的支持有一定要求。
2. 实时性不够高，延迟可能会比较大。
3. 需要考虑协议的可靠性和安全性等问题。

Webscoket

HTML5开始提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议,基于TCP传输协议，并复用HTTP的握手通道。

优势

1. 实时性：Websocket可以实现实时双向通信，服务器可以主动向客户端推送消息，避免了传统HTTP协议需要轮询的问题。
2. 减少通信量：Websocket采用二进制帧传输，相比传统HTTP协议的文本传输方式，能够大幅减少通信数据量，提高传输效率。
3. 跨域支持：Websocket支持跨域通信，可以在不同域名的页面之间进行实时通信。
4. 节省服务器资源：由于Websocket需要维持长连接，因此服务器和客户端之间的握手操作只需要进行一次，节省了服务器资源。

缺点

1. 兼容性：Websocket不是所有浏览器都支持，特别是旧版本的浏览器不支持Websocket协议。
2. 状态维护：Websocket需要维护连接状态，需要服务器端进行连接管理，否则可能出现连接异常或数据丢失等问题。
3. 安全性：Websocket协议通过HTTP协议建立连接后，往往会直接升级为Websocket协议，这样就可能存在安全漏洞，例如跨站脚本攻击（XSS）。
4. 开销：Websocket长时间维持连接，需要占用服务器资源和带宽，可能导致服务器压力增大，需要进行合理的优化和管理。

gRPC

gRPC是一种高性能、开源的远程过程调用（RPC）框架，提供了跨平台、跨语言的服务通信解决方案,先来看下，它支持很多种开发语言。

优势

1. 高效性：gRPC使用HTTP/2协议进行通信，支持多路复用和二进制传输，具有较高的性能和效率。
2. 跨平台、跨语言：gRPC支持多种编程语言，可以在不同平台上使用。
3. 自动生成代码：gRPC支持基于IDL（接口定义语言）自动生成代码，简化开发流程，减少手写代码的工作量。
4. 支持流式处理：gRPC支持流式请求和流式响应，能够满足大部分实时数据处理需求。
5. 可扩展性：gRPC支持自定义插件，可以扩展其功能，适应不同的业务场景。
6. 安全性：gRPC支持SSL/TLS加密通信，保证通信安全性。

缺点

1. 学习成本：gRPC需要对IDL和gRPC的实现细节有一定的了解，对初学者而言可能有一定的学习曲线。
2. 部署难度：gRPC需要依赖特定版本的库和工具，需要进行相应的环境配置和部署。
3. 兼容性：由于gRPC使用HTTP/2协议通信，不支持低版本浏览器和特定网络环境下的代理服务器。
4. 适用场景：gRPC适用于高并发、分布式、跨语言的服务通信，但在一些简单的场景下可能会造成过度设计。

选型分析

下面将用一个表格，从多个维度去分析它们的硬核实力与落地难度。

从上表可以看出，不同类型的长连接在各方面的表现有所不同。

• Http长连接适用于轻量级web应用场景，具有跨平台性和兼容性优势，但性能和延迟较低。
• Tcp长连接在性能和可扩展性方面表现出较大优势，但安全性相对较低，适用于数据库连接、消息队列等场景。
• gRpc长连接适用于实时通信、微服务、云计算等场景，具有高性能和可扩展性，使用成本较高。
• Websocket长连接适用于实时通信、游戏、在线聊天等应用场景，具有高效率和实时性，但需要浏览器和服务器端支持WebSocket协议。
• Mqtt长连接适用于物联网、移动应用等场景，具有较好的安全性和兼容性，但性能和延迟一般。
• Comet长连接适用于消息推送、在线聊天等场景，具有兼容性和使用成本的优势，但性能和延迟较低。

综合以上分析，在我们的业务中选择Websocket/gRpc长连接作为通信协议都是可行的，因为它们都具有较好的通信效率和实时性，适用于实时语音、视频通信等应用场景。但是需要注意，为了避免产生大量的长连接导致服务器压力过大，需要限制长连接数量。此外，还要加强网络安全保护，防止信息泄露和攻击。

最终方案确认

gRPC 和 WebSocket 的最终抉择

先说结论，根据我们的业务场景和一些考虑，选择了gRpc，原因：

• 明确的数据格式：gRPC 使用 Protocol Buffers 作为数据格式，可以更好地定义数据结构、方法等，并自动生成客户端和服务端的代码。而 WebSocket 没有明确的数据格式标准，需要在应用层进行约定。
• 更高效的序列化和反序列化：Protocol Buffers 是一种轻量级的二进制序列化协议，在序列化和反序列化方面比 JSON、XML 等文本格式更高效，能够更快地传输数据。
• 更快的速度和更低的延迟：gRPC 基于 HTTP/2 协议，支持多路复用、流控等特性，能够更快地传输数据，并提供更低的延迟。而 WebSocket 也使用 TCP 连接，但需要额外的应用层协议支持，不能像 gRPC 一样直接使用 HTTP/2。
• 更好的可扩展性：gRPC 支持多种负载均衡策略、服务发现机制等特性，可以更好地处理大规模集群环境下的网络请求。同时，gRPC 还提供了基于拦截器的中间件机制，可以方便地实现日志记录、身份验证等功能。

综合以上优势，可以看出 gRPC 在性能、效率、可扩展性、开发效率等方面都具有很大的优势，至此，长连接调研与选型最终确定。