性能比拼: gRPC vs REST vs GraphQL

本内容是对知名性能评测博主 Anton Putra gRPC vs REST vs GraphQL: Comparison & Performance 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准

在本视频中，我们将比较 REST API、GraphQL 和 gRPC。我们会将这些应用程序部署到 Kubernetes 集群中（在 AWS 上），并通过 吞吐量（Throughput）、延迟（Latency） 以及 资源占用（Saturation） 来衡量它们的性能。

---

开始测试

现在让我们开始测试！整个测试过程花费了大约 2 小时，但我通常会在编辑时将其压缩到几分钟。

对于任何面向客户端的应用程序来说，最重要的指标之一就是 延迟（Latency），我们使用 P90 百分位数（90% Percentile） 来测量它。在测试的前几分钟，你可能会注意到 gRPC 在没有任何负载的情况下比其他应用程序稍慢。这可以用 RPC 消息的序列化和反序列化开销 来解释，但这种情况很快就会发生变化。

当请求量达到 10,000 次/秒 时，你会发现 GraphQL 的性能开始下降。GraphQL 本质上是一个 带有查询引擎的 REST API，因此它的速度比普通的 REST API 要慢是可以预期的。

在右侧的监控面板中，你可以看到 应用程序的 CPU 使用率、内存使用率，以及最重要的---网络使用情况。从 网络流量图 中可以清楚地看到，gRPC 客户端的网络使用量要少得多，这将直接影响你在 AWS 或 Azure 上的账单成本。

---

性能瓶颈

当请求量达到 24,000 次/秒 时，GraphQL 应用开始失败，于是我决定 将其从接下来的图表中移除，直到测试结束。

此时，真正的竞争是在 JSON API 和 gRPC 之间，你会发现它们的性能在几秒钟内发生翻转。让我再运行测试 一分钟，看看情况如何。

---

吞吐量（Throughput）

首先，我们来看 吞吐量，即 每秒可以处理的请求数量：

• GraphQL 只能处理 32,000 次/秒。
• JSON API 能够处理 66,000 次/秒，这个数值与我之前的测试结果非常接近。
• gRPC 达到了 90,000 次/秒，这 是一个非常优秀的结果，可以与 Rust 和高性能 REST API 相媲美。

你可以将这次测试与 之前在虚拟机（VM）和 Kubernetes 上运行相同应用的测试 进行比较，以了解 Kubernetes 为你的工作负载增加了多少额外开销。

---

延迟（Latency）

如预期的那样，由于 GraphQL 需要解析查询，它会增加额外的延迟。而 gRPC 和 REST API 在测试的前半部分表现相当：

• 当 CPU 使用率低于 40% 时，REST API 的延迟更低；
• 但当负载增加时，gRPC 的延迟更加稳定，这正是微服务架构所需要的特性。

---

CPU 使用率

到测试结束时，gRPC 和 REST API 的 CPU 使用率趋于一致。

---

网络使用率

• GraphQL 的网络使用量较低，但这只是因为它 无法处理相同数量的请求。
• REST API 在测试结束时的网络使用量也有所下降，原因同上。
• gRPC 的网络使用效率明显更高，这在高流量情况下会大幅降低你的 云服务成本。

---

内存使用

内存使用在本次测试中 并没有起到决定性作用，但你仍然可以看到 gRPC 的内存占用明显更小。

---

总结：如何选择合适的 API？

• 如果你需要为 Web 应用程序提供 API，REST API 是最佳选择。
• 如果你的应用是移动端，并且可以使用 gRPC，它会 显著提高延迟性能，从而 改善用户体验。
• 如果是微服务之间的通信，强烈建议使用 gRPC，因为它的 稳定性、吞吐量和网络效率都更优秀。