什么是 gRPC？

原文作者：NGINX

原文链接：什么是 gRPC？

转载来源：NGINX 开源社区

NGINX 唯一中文官方社区，尽在 nginx.org.cn

gRPC（Google Remote Procedure Call，Google 远程过程调用）是一个高性能的开源框架。它通过 HTTP/2 实现 API，旨在帮助开发人员更轻松地构建分布式应用，特别是当代码可能在不同地方运行的时候。

gRPC 最初由 Google 开发，用于实现远程过程调用（RPC）。如今，gRPC 是云原生计算基金会（CNCF）的一个孵化项目，这意味着它已被用于生产环境，并得到了大量贡献者的支持。

为何创建 gRPC？

为了解 Google 开发 gRPC 的原因，我们来大致看一下 API 这一设计的发展过程。

RPC 是设计和构建 API 的最早方法之一，允许您编写代码，就好像它将在本地计算机上运行一样，即使您实际上可能需要调用在其他机器（通常在您的本地网络）上运行的服务。

在实践中，这支持开发人员使用直接操作命令（例如 SendUserMessages、addEntry 等），而不必考虑网络细节。RPC 消息具有轻量化、高效等特征，但却与底层系统紧密耦合，因此难以集成和变更，并很有可能泄露系统的细节。

REST API 架构问世后为使用 GET、POST、PUT 及 DELETE 等通用 HTTP 方法访问数据和资源提供了一种统一的方式，化解了其中一些挑战。尽管 REST 简化了数据访问，但 API 返回的元数据往往多于所需的数量。而且由于 REST API 还需要更多的网络信息（例如，请求发送的目的地），因此不如 RPC 轻量化和高效。

gRPC 有何优势？

通过采用新技术，gRPC 更新了 RPC 旧方法，以实现互操作性并提高效率。如今，它被大量用于为微服务架构开发 API。

gRPC 的一些优势包括：

性能 – gRPC 默认使用 HTTP/2 作为其传输协议和 Protocol Buffers，这使其性能要高于 REST 和 JSON 通信。
流式传输 – gRPC 支持事件驱动型架构的数据流，例如服务器端流式传输、客户端流式传输及用于同时发送客户端请求和服务器响应的双向流式传输。
互操作性 – gRPC 内置代码生成能力，支持广泛的编程语言，包括 C++、Java、Python、PHP、Go、Ruby、C#、Node.js 等。
安全性 – gRPC 提供可插式身份验证、链路追踪、负载均衡及健康检查，可提高安全防护和弹性。
云原生 – gRPC 支持基于容器的部署，并可兼容 Kubernetes 和 Docker 等现代云技术。

总之，gRPC 提供了一个灵活的高性能框架，非常适合高度分布式微服务架构中的服务间通信。

了解 gRPC：基本概念

gRPC 的优势和好处主要源于以下两种技术的采用：

用于信息结构化的 Protocol Buffers
作为传输层的 HTTP/2

用于结构化消息的 Protocol Buffers

gRPC 使用 Protocol Buffers（或“Protobuf”）来定义服务和消息，而非利用 XML 或 JSON。它是一种语言中立的机制，用于对服务将要相互发送的结构化消息进行序列化处理。

类似于 REST API 的 OpenAPI 规范的概念，gRPC 中的 API 契约在 .proto 文本文件中实现。开发人员可在该文件中定义其所需的数据结构化方式。然后，protoc 编译器会自动将 .proto 文本文件编译成支持的语言。在运行时，消息被压缩并以二进制格式发送。

这提供了两大优势：

gRPC 占用的 CPU 较少，因为数据以二进制格式表示，降低了消息的大小。
模式进行了明确定义，可确保消息在客户端和服务器之间顺畅交换，从而减少错误。

作为传输层的 HTTP/2

过去，REST API 使用 HTTP/1.1 作为传输层，虽然也可通过 HTTP/2 传送。然而，gRPC 只使用 HTTP/2，这带来了一些关键优势。其中一个优势是能够使用二进制发送通信。此外，HTTP/2 支持处理多个并行请求，而不是一次处理一个请求。通信也是双向的，这意味着单个连接即可同时发送请求和响应。

总体而言，HTTP/2 有助于提高性能，并降低网络利用率，这在繁忙的微服务架构中尤其重要。然而，它也有一些局限性。现代 Web 浏览器通常不支持 HTTP/2，因此您可能需要使用 NGINX 等反向代理来交付应用。

gRPC 与 REST：比较

如今，REST 是最主要的 API 设计风格，因此可用作与 gRPC 进行对比。REST 和 gRPC 都是为 Web 应用和微服务构建 API 的有效方法，难分优劣。不过，了解二者之间的主要区别对选择最适合作业的工具而言大有裨益。

gRPC 和 REST 之间的一些主要区别包括以下方面：

协议
数据格式
流式传输
API 设计
性能
错误处理
语言支持

协议

虽然 REST API 能够利用 HTTP/2，RESTful 服务通常使用基于文本的 HTTP/1.1 作为传输层，而 gRPC 则完全依靠 HTTP/2 — 这是一种更高效的二进制协议，支持请求头压缩和单个 TCP 连接上多路复用等特性。

数据格式

REST API 通常使用 JSON 作为收发数据的数据格式。JSON 是基于文本的格式，易于读写，并得到了广泛支持。gRPC API 使用 Protobuf，它采用二进制格式，可提供更小的有效载荷并实现更快的交互。但 Protobufs 本身可读性差。

流式传输

REST API 支持“请求-响应”模式，对流式传输的支持有限。相比之下，gRPC API 通过 HTTP/2 进行传送，并支持多种通信模式，包括一元流式传输（请求-响应）、服务器流式传输、客户端流式传输和双向流式传输。

API 设计

REST 是一种以资源为中心的模式，支持 GET、POST、PUT 和 DELETE 等标准 HTTP 方法。每个请求都必须包含处理该请求所需的所有信息。此外，API 契约通常使用 OpenAPI 规范编写而成，客户端和服务器的编码需要单独完成。相比之下，gRPC 是一种以服务为中心的模式，其中消息和服务在 .proto 文件中进行定义。该文件可用于为 API 客户端和服务器生成代码。

性能

REST 可能会慢些，因为它通过 HTTP/1.1 传输基于文本的数据。每个请求都需要进行一次 TCP 握手，这可能会导致一些延迟。而 gRPC 支持通过 HTTP/2 传输多个数据流，因此多个客户端可同时发送多个请求，而无需新建 TCP 连接。它还利用了 HTTP/2 的特性，例如请求头压缩。

错误处理

REST 使用标准 HTTP 状态代码进行错误处理。相比之下，gRPC 支持以更高的细粒度来定义错误状态代码，并确保其保持一致。默认的 gRPC 模型非常有限，通常使用更丰富的错误模型（由 Google 开发）进行扩展。

语言支持

REST 得到了几乎所有语言的广泛支持，但并未提供任何内置代码生成功能。实现完全由开发人员自己解决。而 gRPC 凭借其 protoc 编译器为多种编程语言提供了原生代码生成功能。

应使用 gRPC 而非 REST 吗？

综上所述，在 gRPC 和 REST 之间如何选择取决于您所需完成的项目。gRPC 为分布式应用中的服务提供了一种高效、高性能的通信方式。不过，它无法被 Web 浏览器及其他客户端直接读取，并需要使用 API 网卡或反向代理（如 NGINX）与前端客户端进行交互。对于事件驱动型微服务架构中的内部 API 而言，它是不二之选。

与之相比，REST 已被广泛采用，并得到了几乎所有语言的支持。它具有人类和机器可读性，因为数据使用 JSON 或 XML 进行交换。此外，其入门学习难度要低得多，并得到许多 Web 浏览器的支持，因此非常适合公开暴露的 API。