搭建舞台
RSocket
RSocket 在应用网络上实现反应式语义。它是一种端到端强制执行背压和其他反应流概念的网络协议。
远程过程调用
gRPC 旨在解决多语言 RPC 的问题。它有两部分：protobuf IDL 和 HTTP/2 网络协议。
苹果到苹果？
从设计和组件来看，我们知道苹果之间的比较应该是 RSocket 与 HTTP/2。
然而，如何有效地比较两种协议呢？一种方法是使用相同的应用程序对它们进行基准测试。为了让应用程序在协议上运行，我们需要一个RPC SDK。
RSocket 对编码器非常不可知。支持JSON、protobuf等定义。在此基准测试中，我们将使用带有 protobuf、Java RPC 和 Messagepack 的 RSocket。对于 gRPC，我们将仅使用 protobuf，因为它已被证明是 gRPC 性能最佳的编码器。
语境
在进行基准测试之前，我们先来比较一下两种协议的用例。基本上，RSocket 是为应用程序通信而设计的，HTTP/2 仍然是为处理 Web 流量而设计的。
但“旨在处理网络流量”是什么意思？嗯，这意味着客户端和服务器之间有明显的区别。会话方式多为请求/响应，也有流的可能性。请记住，TCP 并不强调客户端/服务器的区别。当我们使用 HTTP/2 协议时，服务器很难向客户端发出反向请求，更不用说使用相同的套接字连接来做到这一点了。
另一方面，应用程序到应用程序的通信则完全不同。应用程序是进行对话的对等体。谁是服务器、谁是客户端之间没有硬性界限，尤其是在微服务架构中。
为了覆盖大多数对话场景，RSocket 实现了四种类型的通信模型：
请求/响应（1 流）
请求/流（有限的许多流）
一劳永逸（无响应）
通道（双向流）
RSocket 不仅是多路复用的，而且发送者和接收者可以在保留相同套接字连接的同时切换角色。
基准测试
设置
两台服务器，每台均配备 4 核 Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz + 8G
JVM配置
-Xmx2g -Xms2g -XX:+AlwaysPreTouch -XX:+UseStringDeduplication
中央处理器
我们还针对 10,000,000-request_512-concurrency_16-conns_16bytes-repsonse测试测试了 CPU 使用情况。使用Java分析工具，我们得到以下结果：
图片标题
结论
很明显，在 Java 版本中，RSocket SDK 轻松击败了 gRPC。从QPS、延迟、CPU消耗和可扩展性来看，RSocket在各个方面都比gRPC表现更好。
反应式 gRPC？
我们应该问的最后一个问题是：“当 gRPC 变得响应式时会发生什么？” 为了回答这个问题，我推荐Oleh Dokuka 和 Igor Lozynskyi 写的《Hands-On Reactive Programming in Spring 5》一书。Oleh Dokuka 是反应式gRPC 项目的主要贡献者之一。书中有一章比较了反应式 gRPC 与 RSocket。我引用：“唯一的区别是它支持更高粒度的流量控制。由于 gRPC 构建在 HTTP/2 之上，因此该框架采用 HTTP/2 流控制作为提供细粒度背压控制的构建块。然而，流量控制仍然依赖于以字节为单位的滑动窗口大小，因此对逻辑元素级别粒度的反压控制未被覆盖。”