Kehaw

gRPC对比RSocket:Part 1


经常有人在询问 gRPC 和 RSocket 到底有什么区别?通常,gRPC 和 RSocket 解决问题的对象是不一样的。在 gRPC 中,采用的是 HTTP/2 的 RPC 框架,而 RSocket 则是更底层的通信协议。所以通常开发人员用基于 RSocket RPC 框架来做底层通信,接下来我们来看一下具体的区别。

OSI 分层

OSI model
Layer Protocol data unit (PDU) Function
Host layers 7 Application Data High-level APIs, including resource sharing, remote file access
6 Presentation Translation of data between a networking service and an application; including character encoding, data compression and encryption/decryption
5 Session Managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes
4 Transport Segment, Datagram Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing
Media layers 3 Network Packet Structuring and managing a multi-node network, including addressing routing and traffic control
2 Data link Frame Reliable transmission of data frames between two nodes connected by a physical layer
1 Physical Symbol Transmission and reception of raw bit streams over a physical medium

参考: OSI 七层模型(Open Systems Interconnection model)

在 OSI 模型中,gRPC 所处的位置在第七层之上 —— 在 HTTP/2 的基础上构建RPC通信。而RSocket则存在于OSI的5/6层,可以在底层网络的基础上对 Reactive Stream 进行封装、建模。

Reactive Streams 对异步流的建模提供了背压。

背压: 计算机语言,交换机在阻止外来数据包发送到堵塞端口的时候可能会发生丢包,而背压就是考验交换机在这个时候避免丢包的能力。

你可以使用RSocket来构建一个gRPC运行在第七层。

协议

gRPC 不是传统意义上的协议。它由 HTTP/2 header、代码和 protobuf 中的约定共同组成。在跨网络传输中,该“协议”没有提供足够的信息来描述当前服务端正在发生的事情。如果在 protobuf 中包含了协议不匹配的项,gRPC 可以通过 unary call 进行调用。gRPC 的实现方式与传统的 Web Service 非常像。

RSocket 是一个有正式定义的5/6层二进制通信协议。你不需要通过生成代码来确定 RSocket 到底做了哪些工作,你只需要关注协议本身即可。

Payloads

gRPC 是基于 protobuf 来形成约定,因此对发送方和接收方都需要明确数据格式,而 RSocket 则不遵守这种约定,你可以向 RSocket 中发送匿名的数据。

RSocket 的优势

发送字节更加灵活,因为您不必定义用于发送数据的协议。 RSocket可用于传输数据库查询,就像传输图片一样容易。

网络传输

gRPC旨在与 HTTP/2 语义一起使用。如果要通过其他传输方式发送数据,则必须模仿 HTTP/2 的语义。在整个网络中,它将 HTTP/2 和 TCP 进行了绑定。

而 RSocket只需要一个双工连接即可发送和接收字节。这可以是TCP,文件,WebSockets等。在RSocket中,很容易通过 WebSockets 从浏览器接收调用,然后使用 TCP 调用服务器。 交互将感觉透明

浏览器支持

gRPC在Web浏览器中是不起作用的。如果想在 Web 浏览器中支持gRPC,需要生成和部署一些额外代码。

但是 RSocket 则可以通过 Websockets 在 Web 浏览器中运行。不需要任何新代码 —— 只需启动一个接受WebSocket连接的RSocket服务器即可。

客户端和服务端的相互调用

gRPC具有传统的客户端/服务器模型,因为它基于HTTP / 2和RPC语义。 在gRPC中,客户端连接到服务器,但是服务器无法调用客户端。 此外,由于gRPC是RPC层,因此您只能进行在protobuf文件中定义的调用。

RSocket在传统HTTP意义上没有客户端服务器交互。 在RSocket中,一旦客户端连接到服务器,它们都可以是请求者和响应者。 这意味着在连接之后,RSocket是全双工的,并且服务器的请求者可以发起对客户端请求者的调用,即服务器一旦连接就可以向Web浏览器进行调用。

流量控制

gRPC的流控制是基于字节的,因为它最终还是基于 HTTP/2 做流控制的。它没有应用程序流控制的概念,因为它不会在参与者之间使用此信息发送消息。

RSocket的流控制是应用程序级流控制。这取决于收件人可以处理多少条消息。RSocket具有一个REQUEST_N frame,该 frame 在多个交互方之间是共享的。处理完这些消息后,它将请求更多消息。这独立于基础传输字节级流控制。这意味着,如果服务速度变慢,它可能会在网络缓冲区已满之前减慢消息数量。

取消通信

在 gRPC 中,通常由客户端来发起取消取消请求,而只有当 protobuf 不匹配的时候,才会由服务端发起终止服务。而 RSocket 是双工通信的,所以任何已发都具备发起取消通信的资格。

负载均衡

gRPC 仅限于 HTTP/2 的负载均衡。 一个 gRPC 调用的负载均衡与流调用的负载平衡不是一样的。但是在 gRPC 中短暂的请求/响应调用将与长时间运行的流相同被同等对待的进行负载平衡。

RSocket 负载平衡可以发生在传输级别和应用程序级别。这是因为在消息中封装了有关正在发生的事情的完整信息(双工)。您可以根据实际情况,来定制化的创建一个负载平衡器,以不同于请求/流的方式对待请求/响应。

空间耦合

gRPC 已耦合到要将请求发送到的URL和服务,在通信的另一端必须有一个【收件人】才能接听到【电话】,因为该消息是直接发送给他们的。如果【收件人】不存在,则通话将失败。

如果你在客户端和服务器之间放置一个代理,虽然看似解决了问题。但是你会尴尬的发现,该代理则必须存在。如果不存在,则请求依然会失败。

而 RSocket 是基于消息传递的,因此对它的 frame 发送没有什么要求。发送消息时,接收方不必在另一侧。另外,由于流中的 frame 是根据 RSocket 协议处理的,因此无论在何处处理或由谁处理都没有关系。

这意味着使用 RSocket 可以对交互进行建模,例如多播和广播。

互动模型

gRPC 作为 HTTP/2 stream 通过网络发送信息。这意味着对于请求/响应和阅后即焚交互,必须通过网络发送更多的信息。

所以,使用gRPC,有关流的一些描述信息也封装在应用程序代码中。这意味着只能通过查看应用程序代码来区分GET和POST之间的区别。

而 RSocket 具有协议内置的交互概念。 这在概念上与HTTP方法类似(但不起作用)。 交互模型为请求-响应(发送一个/接收一个),阅后即焚(发送一个),请求流(发送一个/多处接收)和请求通道(发送/多处接收)。这些包含在协议的框架中,并允许实现针对不同的交互模型进行优化。流通过单个连接发送。

开发人员API

gRPC API仅限于gRPC生成的代码,并且您必须使用RPC的规定进行交互。

而 RSocket 更灵活。如果您喜欢RPC样式的语义,则可以使用RSocket-RPC。如果不喜欢,可以使用Spring Messaging。而且,如果您对底层应用程序编程比较熟练,则可以直接使用RSocket。

Keep Alive 和健康检查

gRPC同时保持活动和运行状况检查。健康检查是可以执行的特殊协议。

而 RSocket 只是保持活动状态。如果保持活动失败,则连接将终止。

恢复

RSocket支持恢复连接。 如果连接失败,RSocket可以自动重新连接,给人以稳定连接的感觉。

Kehaw

👨‍💻Ke Haw 🇨🇳👨‍👩‍👧‍👦

风吹云散去,夜色好观星
Java | 前端 | 大数据

专注于 Spring Cloud 微服务架构与数据处理,研究一切与Java相关的开发技术,包括一部分前端技术。

目前的工作主要是关于B2B大宗商品在线交易领域的数据处理。如果对本站的部分内容感兴趣,请通过邮件、Twitter联系我🤝。

Fork me on Gitee
基于Spring Security + OAuth2 + JWT 的权限认证(一) Java-Stream学习第四步:数据处理 Java-Stream学习第三步:终端操作 Java-Stream学习第二步:处理流 Java-Stream学习第一步:创建流 Electron使用串口通信 Electron下调用DLL文件 国外SaaS服务供应商都是干什么的:Part1 为什么Kafka会丢失消息 Spring Boot中使用JSR380验证框架
Description lists
Kehaw's blog
Site description
人初做事,如鸡伏卵,不舍而生气渐充;如燕营巢,不息而结构渐牢;如滋培之木,不见其长,有时而大;如有本之泉,不舍昼夜,盈科而后进,放乎四海。
Copyright
© 2014 Copyright Kehaw | All rights reserved.