RSocket 与 gRPC 基准测试
搭建舞台
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 流控制作为提供细粒度背压控制的构建块。然而,流量控制仍然依赖于以字节为单位的滑动窗口大小,因此对逻辑元素级别粒度的反压控制未被覆盖。”