【从0-1 千万级直播项目实战】长连接选型 | 助你摆脱CRUD头衔

曾经终败给现在 2023-09-26 21:02 47阅读 0赞

## To CRUD Boys ##

你的身边是不是总有人吐槽你只会CRUD编程？你是不是整天都在做一些CRUD的编程操作，比如普通业务的CRUD、后台管理的CRUD、高并发应用的CRUD，如果是，那恭喜你，确实没说错，你就是个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）框架，提供了跨平台、跨语言的服务通信解决方案,先来看下，它支持很多种开发语言。

![format_png][]

**优势**

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适用于高并发、分布式、跨语言的服务通信，但在一些简单的场景下可能会造成过度设计。

### 选型分析 ###

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

<table> 
 <thead> 
  <tr> 
   <th>长连接类型</th> 
   <th>性能</th> 
   <th>延迟</th> 
   <th>跨平台</th> 
   <th>扩展性</th> 
   <th>安全性</th> 
   <th>兼容性</th> 
   <th>使用成本</th> 
   <th>适用场景</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Http</td> 
   <td>低</td> 
   <td>高</td> 
   <td>高</td> 
   <td>高</td> 
   <td>低</td> 
   <td>高</td> 
   <td>低</td> 
   <td>轻量级web应用</td> 
  </tr> 
  <tr> 
   <td>Tcp</td> 
   <td>高</td> 
   <td>低</td> 
   <td>中</td> 
   <td>高</td> 
   <td>高</td> 
   <td>低</td> 
   <td>中</td> 
   <td>数据库连接、消息队列</td> 
  </tr> 
  <tr> 
   <td>gRpc</td> 
   <td>高</td> 
   <td>低</td> 
   <td>高</td> 
   <td>高</td> 
   <td>高</td> 
   <td>中</td> 
   <td>高</td> 
   <td>实时通信、微服务、云计算</td> 
  </tr> 
  <tr> 
   <td>Websocket</td> 
   <td>高</td> 
   <td>低</td> 
   <td>高</td> 
   <td>高</td> 
   <td>中</td> 
   <td>中</td> 
   <td>中</td> 
   <td>实时通信、游戏、在线聊天应用</td> 
  </tr> 
  <tr> 
   <td>Mqtt</td> 
   <td>中</td> 
   <td>中</td> 
   <td>中</td> 
   <td>高</td> 
   <td>高</td> 
   <td>中</td> 
   <td>中</td> 
   <td>物联网、移动应用</td> 
  </tr> 
  <tr> 
   <td>Comet</td> 
   <td>中</td> 
   <td>中</td> 
   <td>高</td> 
   <td>中</td> 
   <td>高</td> 
   <td>高</td> 
   <td>低</td> 
   <td>消息推送、在线聊天应用</td> 
  </tr> 
 </tbody> 
</table>

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

*  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 在性能、效率、可扩展性、开发效率等方面都具有很大的优势，至此，长连接调研与选型最终确定，接下来就要开始实战操作了。

[format_png]: https://img-blog.csdnimg.cn/img_convert/9215b1bd340da4f8b5e025da4d1fe2d7.webp?x-oss-process=image/format,png