本内容是对知名性能评测博主 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 ，因为它的 稳定性、吞吐量和网络效率都更优秀。