gRPC 真的比 REST 好吗？我分析了来自 1000 名开发者的真实反馈

本文最初发布于 Konfig 官方博客。

开发人员对于 gRPC 的真实看法是什么？

gRPC 在大型软件公司有着广泛的应用，这已经不是什么秘密了。谷歌最初是在 2010 年开发了 Stubby 作为内部 RPC 协议。2015 年，谷歌决定开源 Stubby，并将其改名为 gRPC。Uber 和 Netflix 都非常重视微服务，都广泛采用了 gRPC。虽然我个人没有用过 gRPC，但我的同事很喜欢它。那么，开发人员对 gRPC 的真实看法是什么？

为了弄清楚这个问题，我访问了开发者的聚集地：Reddit、Twitter、Hacker News 和 YouTube。在这篇文章中，我分析了 1000 个讨论，并进行了总结，尽力只提供一些发人深省的观点。

观点收集漏斗

接下来，我将这些讨论记录在白板上，并把它们分成三类：支持 gRPC、反对 gRPC 或中立，然后将它们聚合成不同的观点。这篇文章的每个部分都介绍了一种观点，并引用了相关的讨论。

观点白板

gRPC 最值得称赞的地方在于其卓越的代码生成工具和高效的数据交换格式，它们显著提高了服务交互开发的体验和性能。

……定义良好的错误代码……更不用说跨平台支持和代码自动生成……（来自 Hacker News）

我喜欢使用 gRPC 进行服务间通信。（来自 Reddit）

……对于内部服务，代码生成是必须的……（来自 Hacker News）

……用你使用的编程语言生成客户端和服务器端代码……对于 API 调用量大的特性，它可以介节省大约 30% 的开发时间……（来自 Hacker News）

gRPC 在跨语言方面要优于许多其他格式……（来自 Reddit）

……其庞大的代码生成生态系统可以为你生成任何东西，从标准的 gRPC 服务器到传统的 JSON API。该生态系统几乎支持所有流行的语言……（来自 Reddit ）

通常，工程团队要负责管理多个服务，同时还要与其他团队管理的服务进行交互。代码生成工具能够帮助开发人员缩短开发过程并使创建的服务更可靠。Protocol Buffers 鼓励工程师重点关注他们向其他团队开放的接口和数据模型，促进不同团体之间工作流的统一。

上面提到的 gRPC 的主要好处如下：

• 客户端和服务器端存根代码生成工具

• 数据治理

• 架构语言无关

• 运行时性能

• 定义良好的错误代码

如果你的组织正在开发大量的内部微服务，那么 gRPC 可能是一个很好的选择。

要正确地构建 REST 应用程序，开发人员需要了解底层协议 HTTP。相比之下，gRPC 将 HTTP 抽象了出来，使其更容易理解，可以加速应用程序的构建。

有谁能告诉我哪里不能用 gRPC 吗？（来自 Twitter）

试过 gRPC 之后，我再也不想回到 REST 了……“我将按照我想的契约编写一个服务器，而你可以按照你想的契约编写一个客户端。”（来自 Reddit）

REST 使开发人员在定义和消费 API 时更容易犯错。

相比之下，gRPC 在设计时就考虑了大型软件系统的复杂性。这使得它一开始就非常注重代码生成和数据治理。而 REST 从根本上说是一种面向 Web 服务的软件架构风格，代码生成和数据治理等方面并不是其主要考虑的因素。OpenAPI（以前称为 Swagger）是 REST API 设计中使用最广泛的标准。它本质上是一个对底层协议没有严格要求的规范。这将导致 API 使用者可能无法接收到预期的数据模型，导致 API 定义和底层协议之间是一种松耦合的关系。这种脱节可能会成为开发人员的混乱和痛苦之源。因此，我们不禁要问：当 gRPC 提供了一个内聚性更好、可靠性更高的替代方案时，为什么还要选择 REST？

一些重要的功能，比如负载平衡、缓存、调试、身份验证和浏览器支持，都被 gRPC 复杂化了。

为什么 gRPC 和 Node.js 如此之难？……（来自 Reddit）

如果你想给浏览器发送响应，那么 gRPC 的工具并不算好……如果你自己构建，那么这个过程无疑是个不小的负担……（来自 Reddit）

……我更喜欢 JSON。在线添加或扩展 JSON 端点，或者是使用基本的 gzip 压缩，从来都不是问题……（来自Hacker News）

表面上看，gRPC 似乎是构建高质量 API 的一个很好的解决方案。但与任何技术一样，当你开始使用它时，问题就开始显现了。特别是，添加 RPC 层会在系统的核心部分引入依赖关系。因此，当期望 API 提供某些功能时，你会受制于 gRPC。

很快，你就会发出下面这些疑问：

• gRPC 服务如何负载均衡？

• gRPC 服务如何缓存？

• gRPC 服务如何调试？

• gRPC 服务如何进行身份验证？

• 如何在浏览器中支持 gRPC？

类似的问题还有很多。很快，你就会产生怀疑：为什么我不构建一个 REST API？

世界构建于标准之上，REST 也不例外。

如果 REST 有效，我看出来为什么还要挖掘其他替代方案。这是一个广泛应用的标准……到目前为止，我参与的项目中还没有哪一个需要一个替代方案……（来自 Reddit）

gRPC 源于错误……最糟糕的是，它不支持 null/undefined……不要充英雄，使用 REST With JSON-Schema/OPEN-API 就对了……（来自 Reddit）

REST 经过了实战检验，坚持下去。（来自 Reddit）

……失去 HTTP 意味着失去一个很大的工具世界……所有人都熟悉 HTTP 和 REST。（来自 Reddit）

不要充英雄，用 REST 就对了。

回想一下，gRPC 之所以诞生是因为谷歌需要构建一个高性能的服务间通信协议。所以实际上，如果你不是谷歌，可能就不需要 gRPC。工程师们在设计系统时经常会因过度设计而导致 复杂性 升高，而 gRPC 似乎就是一个对工程师们很有吸引力的新玩具。但与任何新技术一样，你需要考虑长期维护成本。

你不会希望自己负责引入的新技术给组织带来维护负担。REST 是经过实战检验的，因此，使用 REST，你可以获得标准带来的所有好处，例如工具和基础设施，而无需承担它的维护负担。大多数工程师也熟悉 REST，因此很容易引入新的团队成员。

gRPC 显著增强了内部服务的开发体验和性能。尽管如此，它可能并不是外部服务的理想选择。

gRPC 用于内部服务通信，REST/GraphQL 用于边缘。（来自 Reddit）

……gRPC 适合于内部使用，REST 适合于外部使用……（来自YouTube）

gRPC 在内部服务之间的通信方面非常出色，并且为开发人员提供了出色的代码生成和高效的数据交换工具。忽视 gRPC 为开发人员带来的实际好处可能有些目光短浅，特别是在许多组织从采用 gRPC 中受益匪浅的情况下。

然而，需要注意的是，浏览器支持并不是 gRPC 设计的主要关注点。要实现浏览器端 gRPC 客户端就需要借助一个额外的组件 grpc-web。此外，外部服务通常有特定的需求，如缓存和负载平衡，这些 gRPC 都无法直接满足。采用 gRPC 开发外部服务可能需要自定义的解决方案来支持这些特性。

重要的是要认识到，并非每种技术都适用于所有情况。使用 gRPC 开发外部服务可能类似于试图将方钉塞进圆孔中。为正确的工作选择正确的工具是非常重要的。

gRPC 在 2015 年才开源（当时谷歌决定标准化其内部 RPC 协议），因此仍有许多开源工具需要构建。

……我们需要更多的 gPRC 原生工具。（来自YouTube）

在 Python 中，gRPC 很慢……但 C++ 实现要快 100 倍……（来Hacker News）

从cURL到 Postman，REST API 有各种各样的工具支持。这些工具都非常成熟，而且提供完整的文档。相比之下，gRPC 就相对较年轻。尽管它也有一些可用的工具，但它们并不像 REST 的工具那样成熟或文档完备。

不过，随着 gRPC 生态系统的日益普及，它正在迅速发展。Grpcurl 和 grpcui 等开源工具的开发就是这种增长的证明。此外，像 Buf 这样的公司也通过构建先进的工具来增强 gRPC 的开发体验，积极地为其发展做贡献。

gRPC 无疑是一种两极分化的技术。在开发内部服务间通信时，它的开发体验和性能表现都很出色，但还是有一些开发人员不相信它比 REST 好。

就我们而言，我们将 REST 用于外部 API，将 REST/GraphQL 组合用于内部服务。目前，我们并没有迫切的需求要将 gRPC 集成到我们的工作流中。不过，开发社区的某些部分对它的热情支持还是令人印象非常深刻。在未来几年里，观察 gRPC 生态系统的演变和扩张将是一件非常有趣的事情。

原文链接：

https://konfigthis.com/blog/grpc

声明：本文为 InfoQ 翻译，未经许可禁止转载。