123 lines
12 KiB
Markdown
123 lines
12 KiB
Markdown
**gRPC**（Google Remote Procedure Call，Google 远程过程调用）
|
||
是一个高性能的开源框架。它通过 HTTP/2 实现 API，旨在帮助开发人员更轻松地构建分布式应用，特别是当代码可能在不同地方运行的时候。
|
||
|
||
## **为何创建 gRPC？**
|
||
RPC 是设计和构建 API 的最早方法之一，允许您编写代码，就好像它将在本地计算机上运行一样，即使您实际上可能需要调用在其他机器（通常在您的本地网络）上运行的服务。
|
||
在实践中，这支持开发人员使用直接操作命令（例如 `SendUserMessages`、`addEntry` 等），而不必考虑网络细节。RPC 消息具有轻量化、高效等特征，但却与底层系统紧密耦合，因此难以集成和变更，并很有可能泄露系统的细节。
|
||
**[REST API](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/rest-api/)** 架构问世后为使用 `GET`、`POST`、`PUT` 及 `DELETE` 等通用 **[HTTP](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/http/)** 方法访问数据和资源提供了一种统一的方式，化解了其中一些挑战。尽管 REST 简化了数据访问，但 API 返回的元数据往往多于所需的数量。而且由于 REST API 还需要更多的网络信息（例如，请求发送的目的地），因此不如 RPC 轻量化和高效。
|
||
|
||
## **gRPC 有何优势？**
|
||
通过采用新技术，gRPC 更新了 RPC 旧方法，以实现互操作性并提高效率。如今，它被大量用于为**[微服务](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/microservices/)**架构开发 API。
|
||
|
||
gRPC 的一些优势包括：
|
||
|
||
- **性能** – gRPC 默认使用 **[HTTP/2](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/http2/)** 作为其传输协议和 Protocol Buffers，这使其性能要高于 REST 和 JSON 通信。
|
||
- **流式传输** – gRPC 支持**[事件驱动型架构](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/blog/event-driven-data-management-microservices/)**的数据流，例如服务器端流式传输、客户端流式传输及用于同时发送客户端请求和服务器响应的双向流式传输。
|
||
- **互操作性** – gRPC 内置代码生成能力，支持广泛的编程语言，包括 C++、Java、Python、PHP、Go、Ruby、C#、Node.js 等。
|
||
- **安全性** – gRPC 提供可插式身份验证、链路追踪、**[负载均衡](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/load-balancing/)**及**[健康检查](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/blog/active-or-passive-health-checks-which-is-right-for-you/)**，可提高安全防护和弹性。
|
||
- **云原生** – gRPC 支持基于容器的部署，并可兼容 **[Kubernetes](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/kubernetes/)** 和 Docker 等现代云技术。
|
||
|
||
总之，gRPC 提供了一个灵活的高性能框架，非常适合高度分布式微服务架构中的服务间通信。
|
||
|
||
## **了解 gRPC：基本概念**
|
||
|
||
gRPC 的优势和好处主要源于以下两种技术的采用：
|
||
|
||
- 用于信息结构化的 Protocol Buffers
|
||
- 作为传输层的 HTTP/2
|
||
|
||
### **用于结构化消息的 Protocol Buffers**
|
||
|
||
gRPC 使用 **[Protocol Buffers](https://link.zhihu.com/?target=https%3A//protobuf.dev/)**（或“Protobuf”）来定义服务和消息，而非利用 XML 或 JSON。它是一种语言中立的机制，用于对服务将要相互发送的结构化消息进行序列化处理。
|
||
|
||
类似于 REST API 的 **[OpenAPI 规范](https://link.zhihu.com/?target=https%3A//spec.openapis.org/oas/latest.html)**的概念，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 等**[反向代理](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/reverse-proxy-server/)**来交付应用。
|
||
|
||
## **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 开发）](https://link.zhihu.com/?target=https%3A//cloud.google.com/apis/design/errors%23error_model)**进行扩展。
|
||
|
||
### **语言支持**
|
||
|
||
REST 得到了几乎所有语言的广泛支持，但并未提供任何内置代码生成功能。实现完全由开发人员自己解决。而 gRPC 凭借其 protoc 编译器为多种编程语言提供了原生代码生成功能。
|
||
|
||
### **应使用 gRPC 而非 REST 吗？**
|
||
|
||
综上所述，在 gRPC 和 REST 之间如何选择取决于您所需完成的项目。gRPC 为分布式应用中的服务提供了一种高效、高性能的通信方式。不过，它无法被 Web 浏览器及其他客户端直接读取，并需要使用 **[API 网卡](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/resources/glossary/api-gateway/)**或反向代理（如 NGINX）与前端客户端进行交互。对于事件驱动型微服务架构中的内部 API 而言，它是不二之选。
|
||
|
||
与之相比，REST 已被广泛采用，并得到了几乎所有语言的支持。它具有人类和机器可读性，因为数据使用 JSON 或 XML 进行交换。此外，其入门学习难度要低得多，并得到许多 Web 浏览器的支持，因此非常适合公开暴露的 API。
|
||
|
||
## **gRPC 微服务架构**
|
||
|
||
由于性能以及在语言支持方面的灵活性，gRPC 是微服务架构中通信的最佳选择之一。开发人员可以轻松构建并生成以其首选语言运行的 gRPC 客户端和服务器。由于 gRPC 以二进制格式描述了 API 契约，因此微服务可独立于用于构建它们的语言进行通信。
|
||
|
||
最常见的基于 gRPC 的微服务架构之一是将 API 网关部署在微服务的前面，然后通过 gRPC 处理所有内部通信。API 网关处理来自 HTTP/1.1 的传入请求，并通过 HTTP/2 将其作为 gRPC 请求代理到微服务。
|
||
|
||
## **gRPC 安全防护问题**
|
||
|
||
随着 gRPC 日益普及，开发人员和安全运维团队需要确保部署有效的安全防护解决方案。由于 gRPC 消息采用二进制格式，因此对于采用 ASCII 通信的设备和工具而言，可能会遇到问题。
|
||
|
||
gRPC API 也容易受到许多**[最常见的 API 安全威胁](https://link.zhihu.com/?target=https%3A//owasp.org/www-project-api-security/)**。访问控制、加密及运行时防护等标准 API 安全防护实践在基于 gRPC 的架构中同样重要。
|
||
|
||
## **gRPC 安全防护建议**
|
||
|
||
gRPC 应用和 API 需要采用整体安全防护方法。确保 gRPC 安全的一些最佳实践包括：
|
||
|
||
- **模式验证** – 通过验证 gRPC 消息中的每个字段是否具有正确的类型和预期内容来阻止恶意利用。
|
||
- **数据屏蔽** – 屏蔽或阻止敏感数据（如信用卡号码和社会保险号）离开系统。
|
||
- **速率限制** – 严格限制请求的大小和数量，以防止资源耗尽型 DoS 攻击。
|
||
- **访问控制** – 在授予客户端对服务的访问权限之前执行身份认证和授权。
|
||
- **加密** – 使用传输层安全（TLS）保护传输中的消息。
|
||
|
||
最终，您应验证 **[API 网关](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/products/nginx/api-gateway/)**、**[Web 应用防火墙](https://link.zhihu.com/?target=https%3A//www.nginx-cn.net/products/nginx-app-protect/)**（WAF）及其他 API 管理和安全防护工具能否保护您生产环境中的 gRPC 应用和 API。这些工具应能够为每个服务导入 .proto 文件，以用于对 gRPC 应用和 API 实施安全防护。
|
||
|
||
## **总结**
|
||
|
||
gRPC 正被开发人员及 **[Netflix](https://link.zhihu.com/?target=https%3A//www.youtube.com/watch%3Fv%3D6oPj-DW09DU)** 和 **[Lyft](https://link.zhihu.com/?target=https%3A//www.infoq.com/presentations/api-pb-grpc/)** 等大公司大量用于微服务架构中的内部通信。不过，gRPC 既无法替代 REST API，也不是构建 API 的更好方式。只有当您主要为内部微服务环境构建 API 并需要高效、实时通信能力时，gRPC 才是一个可供考虑的备选方案。
|
||
|
||
展望未来，鉴于其性能优势和易开发性，gRPC 可能会在云原生应用中愈加受到青睐。与此同时，需要公开暴露 API 的开发人员将继续在其应用中使用 REST。REST 也将继续存在于云原生环境中，因为它具有向后兼容性并可深度集成现有 API 基础架构和运维环境。
|