前言
其实不管大厂、小厂,做业务开发的同学都知道,写一个功能,有中台,有架构,有API,有SDK,很多可复用的代码直接调一下RPC接口或者一个注解就搞定了复杂的操作,所以很多螺丝钉们都没法真正接触底层核心组件、功能的设计和编写,更别谈在项目中会有什么技术选型、做决策、落地的操作,长此以往,技术广度、深度、落地能力 一个都没锻炼出来,所以为什么说大厂中P7是个分水岭,这句话不是毫无道理的。
业务场景
先说这一次的业务场景,不讲业务场景空谈选型方案的都是耍流氓。
- 需要实现直播房间内服务端与客户端之间的数据通信
- 需要一个延迟很低/实时的通信方案
- 通信需要支持双向流
- 对用户客户端设弱网抗性要强
- 性能要很强,支持高并发操作,大规模长连接集群
- 服务端与客户端之间接口兼容与版本迭代方便
带着这几个业务场景,我们开始进行选型操作
长连接调研
Http长连接
在 HTTP 协议中,使用 Keep-Alive 或者 Connection: keep-alive 参数来实现长连接。
优势
- 简单易用,不需要额外的协议支持。
- 操作简单,适用于轻量级的网络应用场景。
缺点
- 只能在客户端主动发起请求时才能使用。
- 无法在服务器端主动推送。
TCP 长连接
优势
- 实时性较高,可以实现双向通信。
- 对于大规模并发连接场景,TCP 长连接占用的资源相对较少。
缺点
- 协议级别上不支持心跳检测、消息推送、断线重连等功能,需要业务代码自行实现。
- 难以处理跨网络环境的 NAT 等问题。
Comet
Comet 是一种以 Ajax 技术为基础的服务器推送技术,通过长轮询、短轮询等方式实现服务器向客户端推送数据,适用于消息推送、在线聊天等应用场景。
优势
- 实时性较高,可以实现双向通信。
- 可以通过 HTTP 协议进行通信,在网络环境复杂的情况下更加稳定。
缺点
- 需要对 HTTP 协议进行 hack,增加了很多复杂度,也可能存在安全隐患。
- 需要考虑服务器的负载均衡和可靠性等问题,比较复杂。
MQTT
MQTT 是一种轻量级的发布/订阅协议,可以在低带宽和不稳定网络环境下使用,适用于物联网、移动应用等场景。
优势
- 非常适合物联网场景,支持大量连接和消息推送。
- 对网络带宽的占用相对较小。
- 通信效率高、开销小、支持 QoS2 消息传输。
缺点
- 需要引入 MQTT 协议栈,对客户端和服务器的支持有一定要求。
- 实时性不够高,延迟可能会比较大。
- 需要考虑协议的可靠性和安全性等问题。
Webscoket
HTML5开始提供的一种浏览器与服务器进行全双工通讯的网络技术,属于应用层协议,基于TCP传输协议,并复用HTTP的握手通道。
优势
- 实时性:Websocket可以实现实时双向通信,服务器可以主动向客户端推送消息,避免了传统HTTP协议需要轮询的问题。
- 减少通信量:Websocket采用二进制帧传输,相比传统HTTP协议的文本传输方式,能够大幅减少通信数据量,提高传输效率。
- 跨域支持:Websocket支持跨域通信,可以在不同域名的页面之间进行实时通信。
- 节省服务器资源:由于Websocket需要维持长连接,因此服务器和客户端之间的握手操作只需要进行一次,节省了服务器资源。
缺点
- 兼容性:Websocket不是所有浏览器都支持,特别是旧版本的浏览器不支持Websocket协议。
- 状态维护:Websocket需要维护连接状态,需要服务器端进行连接管理,否则可能出现连接异常或数据丢失等问题。
- 安全性:Websocket协议通过HTTP协议建立连接后,往往会直接升级为Websocket协议,这样就可能存在安全漏洞,例如跨站脚本攻击(XSS)。
- 开销:Websocket长时间维持连接,需要占用服务器资源和带宽,可能导致服务器压力增大,需要进行合理的优化和管理。
gRPC
gRPC是一种高性能、开源的远程过程调用(RPC)框架,提供了跨平台、跨语言的服务通信解决方案,先来看下,它支持很多种开发语言。
![a98c607a7abfdef1d41e4275adf38b06.jpeg](https://i-blog.csdnimg.cn/blog_migrate/d40d6a831292313dd8868db65f5d95e7.jpeg)
优势
- 高效性:gRPC使用HTTP/2协议进行通信,支持多路复用和二进制传输,具有较高的性能和效率。
- 跨平台、跨语言:gRPC支持多种编程语言,可以在不同平台上使用。
- 自动生成代码:gRPC支持基于IDL(接口定义语言)自动生成代码,简化开发流程,减少手写代码的工作量。
- 支持流式处理:gRPC支持流式请求和流式响应,能够满足大部分实时数据处理需求。
- 可扩展性:gRPC支持自定义插件,可以扩展其功能,适应不同的业务场景。
- 安全性:gRPC支持SSL/TLS加密通信,保证通信安全性。
缺点
- 学习成本:gRPC需要对IDL和gRPC的实现细节有一定的了解,对初学者而言可能有一定的学习曲线。
- 部署难度:gRPC需要依赖特定版本的库和工具,需要进行相应的环境配置和部署。
- 兼容性:由于gRPC使用HTTP/2协议通信,不支持低版本浏览器和特定网络环境下的代理服务器。
- 适用场景: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 在性能、效率、可扩展性、开发效率等方面都具有很大的优势,至此,长连接调研与选型最终确定。