我们一直被问到这个问题。 通常，gRPC和RSocket尝试解决不同的问题。 gRPC是使用HTTP / 2的RPC框架。 RSocket是较低级别的消息传递网络层。 因此，开发人员将直接使用RSocket进行低级交互，并可以选择使用RSocket-RPC作为位于RSocket之上的易于使用的RPC层。

现在，让我们更具体地看一下gRPC和RSocket之间的区别。

OSI层

gRPC和RSocket位于堆栈的不同层。 gRPC位于OSI层7上-在HTTP / 2之上构建的RPC层。 RSocket是OSI 5/6层，可通过网络对响应流语义进行建模。 反应性流提供了一种使用反压对异步流进行建模的方法。 在10,000英尺的视野中，您将使用RSocket来构建gRPC之类的东西（例如RSocket-RPC），该东西将位于OSI（应用程序）层7。

协议

gRPC不是传统意义上的协议。 它由HTTP / 2标头，生成的代码和protobuf中的约定组成。 跨网络传输的内容中没有足够的信息来确定正在发生的事情。 例如，如果protobuf中存在不匹配项，则gRPC可以通过一元调用来调用流。 gRPC设计类似于Web服务。

RSocket是具有正式定义的5/6层二进制协议。 您无需生成代码来确定RSocket发生了什么—您只需了解协议即可。

有效载荷

对于您要发送的有效载荷，gRPC持谨慎态度-出于所有意图和目的，它都是protobuf。

RSocket不自觉，允许您发送不透明字节。

优点

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

网络传输

gRPC旨在与HTTP / 2语义一起使用。 如果要通过其他传输方式发送它，则必须模仿HTTP / 2语义。 在整个网络中，它有效地绑定到HTTP / 2和TCP。

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

浏览器支持

gRPC在Web浏览器中不起作用。 Web浏览器的支持要求生成和部署其他代码。

RSocket通过Websockets在Web浏览器中工作。 不需要任何新代码-只需启动一个接受WebSocket连接的RSocket服务器即可。

客户端/服务器交互

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

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

流量控制

gRPC的流控制是基于字节的，因为它最终是HTTP / 2流控制。 它没有应用程序流控制的概念，因为它不会在参与者之间使用此信息发送消息。 HTTP / 2流控制具有有限的价值，因为TCP还提供字节级流控制。

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

取消订单

在gRPC中，取消通常只从客户端到服务器。 仅当序列不完整时，服务器才应发送取消消息。

RSocket取消在请求者和响应者之间发送。 哪一方是客户端还是服务器都没有关系。 另外，由于反应流语义，它们在服务之间自动传播。

负载均衡

gRPC仅限于HTTP / 2负载平衡。 一元gRPC调用的负载平衡与流调用的负载平衡不能相同。 这意味着短暂的请求/回复调用将与长时间运行的流相同地进行负载平衡。

RSocket负载平衡可以发生在传输级别和应用程序级别。 这是因为在消息中封装了有关正在发生的事情的完整信息。 您可以创建一个负载平衡器，以不同于请求/流的方式对待请求/响应。

空间耦合

gRPC已耦合到要将请求发送到的URL和服务。 另一端必须有一个收件人才能接听电话，因为该消息是直接发送给他们的。 如果接收者不存在，通话将失败。 如果您在客户端和服务器之间放置一个代理，这仍然是正确的。 然后，该代理必须存在。 如果不存在，则请求将失败。 如果没有任何要调用的代理，那么它的请求也会失败。

RSocket是基于消息传递的，因此对它的帧发送位置没有意见。 发送消息时，接收方不必在另一侧，因为消息是通过流发送的-流中的帧仅需要处理。 另外，由于流中的帧是根据RSocket协议处理的，因此无论在何处或由谁处理它们都无关紧要。

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

互动模型

gRPC作为HTTP / 2流通过网络发送信息。 这意味着对于请求/答复和触发/忘记交互，必须通过网络发送更多帧。 同样，使用gRPC，有关流的信息封装在应用程序代码中。 这意味着只能通过查看应用程序代码来区分GET和POST之间的区别。

RSocket具有协议内置的交互概念。 这在概念上与HTTP方法类似（但不起作用）。 交互模型是请求-答复（发送一个/接收一个），解雇（发送一个），请求流（发送一个/接收很多）和请求通道（发送/接收很多）。 这些包含在协议的框架中，并允许实现针对不同的交互模型进行优化。 流通过单个连接发送。

开发人员API

gRPC API仅限于gRPC生成的代码，并且您必须使用RPC样式的交互。

RSocket更灵活。 如果您喜欢RPC样式的语义，则可以使用RSocket-RPC。 如果不喜欢，可以使用Spring Messaging。 而且，如果您对底层应用程序编程感到满意，则可以直接使用RSocket。

时间耦合

gRPC和RSocket都提供了非阻塞API。

保持健康和健康检查

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

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

恢复

RSocket支持恢复连接。 如果连接失败，RSocket可以自动重新连接，给人以稳定连接的印象。

RSocket Java特定差异

零拷贝

RSocket Java提供了一个API，使开发人员可以管理Netty ByteBuf生命周期，从而实现零拷贝。

自动请求批处理

RSocket Java利用响应流语义来通过网络批量处理请求。 使用此信息，RSocket可以确定在网络缓冲区已满或是否需要基于有关流的信息进行刷新时刷新数据。 结果是RSocket将根据其观察到的内容通过网络发送最佳数据量，而无需用户进行调整。

基于Flyweight的帧

RSocket Java使用flyweight模式对帧进行编码和解码。 这些flyweight不分配任何数据。 取而代之的是，它们充当ByteBuf上的镜头来读取，而没有解码帧的开销。

RSocket编程API

RSocket是OSI 5/6层协议，虽然可以根据用例直接使用，但使用第7层协议开发应用程序要容易得多。 当前有RPC，IPC，不久便增加了GraphQL支持。 现在最成熟的是RSocket RPC，它是一个Protobuf自动编组层，位于RSocket之上，以使消息传递更加方便。 从本质上讲，它不是RPC，而是一个消息传递层，它生成样板方法并自动封送消息。 它使用protobuf编译器执行此操作。 与gRPC不同，后者创建带有标题信息的HTTP / 2消息，而RSocket RPC生成二进制编码的帧。 框架已标准化为RSocket扩展框架。

RSocket RPC与RSocket共享请求者和响应者的概念。 这意味着客户端可以连接到服务器，并且该服务器可以调用客户端所托管的服务。

有关交互的所有信息都封装在请求者和响应者之间发送的帧中。 您不需要生成的代码来确定如何处理消息。 这意味着您不需要生成代码即可了解RSocket RPC调用。 如果您不喜欢RPC生成的代码，则可以改用IPC样式的代码来处理消息。 IPC代码还允许您指定要使用的串行器，并允许使用protobuf以外的发送方法。

添加了GraphQL支持以使用IPC样式的代码。 这将支持使用GraphQL进行查询，变异和订阅。

(本文翻译自Robert B Roeser的文章《Differences between gRPC and RSocket》，参考：https://medium.com/netifi/differences-between-grpc-and-rsocket-e736c954e60)