凌云的博客

gRPC FAQ[译]

分类：grpc| 发布时间：2025-01-07 08:57:00

概述

原文： gRPC FAQ

什么是 gRPC?

gRPC 是一个现代的开源远程过程调用（RPC）框架，可以在任何地方运行。 它使客户端和服务器应用程序能够透明地进行通信，并简化了构建连接系统的过程。

欲了解更多背景信息以及我们为何创建 gRPC，请阅读更详细的 动机与设计原则 文章。

gRPC 代表什么？

gRPC Remote Procedure Calls 的缩写！

为什么我要使用 gRPC？

主要的使用场景包括：

• 低延迟、高度可扩展的分布式系统。
• 开发与云服务器通信的移动客户端。
• 设计需要高精度、高效率且语言无关的新协议。
• 分层设计以支持扩展，例如身份验证、负载均衡、日志记录和监控等。

谁在使用 gRPC，为什么？

gRPC 是一个云原生计算基金会（CNCF） 项目。

Google 长期以来一直在 gRPC 中使用了许多底层技术和概念。 当前的实现已被广泛应用于 Google 的多个云产品和对外 API。 它也被 Square、Netflix、CoreOS、Docker、CockroachDB、Cisco、Juniper Networks 以及许多其他组织和个人所使用。

支持什么编程语言?

官方支持的语言和平台可以查看: 官方支持

如何开始使用 gRPC？

您可以通过按照 此处 的说明进行 gRPC 安装来开始。 或者，前往 gRPC 的 GitHub 组织页面，选择您感兴趣的运行时或编程语言，并按照 README 文件中的说明进行操作。

gRPC 使用什么许可证？

所有实现都采用 Apache 2.0 许可证。

如何贡献？

我们非常欢迎 贡献者，所有代码库都托管在 GitHub 上。 我们期待社区的反馈、贡献和报告问题。 个人贡献者和企业贡献者都需要签署我们的贡献者许可协议（CLA）。 如果您有关于 gRPC 的项目想法，请阅读指南并在 这里 提交。 我们在 GitHub 上的 gRPC Ecosystem 组织下有一个不断增长的项目列表。

文档在哪里？

请查看 grpc.io 上的 文档。

路线图是什么？

gRPC 项目有一个 RFC（请求评论）流程，通过该流程设计并批准新特性的实现。 相关内容会在这个 代码库 中进行跟踪。

gRPC 的发布版本支持多久？

gRPC 项目不提供长期支持（LTS）版本。 根据上述进行滚动发布，我们支持当前开发版，最新发布版本以及上一个发布版本。 这里的支持包括错误修复和安全修复。

gRPC 的版本管理策略是什么？

请 参阅 gRPC 版本管理策略。

gRPC 的发布何时进行？

gRPC 项目采用一种模型，其中主分支的最新版本始终保持稳定。 该项目（涵盖各种运行时）计划每 6 周发布一次检查点版本，具体时间表按最佳努力原则进行。请参阅 发布计划。

如何报告 gRPC 中的安全漏洞？

要报告 gRPC 中的安全漏洞，请按照 此处 记录的流程进行操作。

我可以在浏览器中使用它吗？

gRPC-Web 项目是普遍可用的。

我可以使用我喜欢的数据格式（JSON、Protobuf、Thrift、XML）与 gRPC 吗？

可以。gRPC 设计上是可扩展的，支持多种内容类型。 初始版本支持 Protobuf，并且通过外部支持其他内容类型（如 FlatBuffers 和 Thrift），这些支持的成熟度不同。

我可以在服务网格中使用 gRPC 吗？

可以。gRPC 应用程序可以像其他应用程序一样部署在服务网格中。 gRPC 还支持 xDS API，使得可以在没有 sidecar 代理的情况下将 gRPC 应用程序部署在服务网格中。 gRPC 支持的无代理服务网格功能列在 此处。

gRPC 如何帮助移动应用开发？

gRPC 和 Protobuf 提供了一种简单的方式来精确地定义服务，并为 iOS、Android 和提供后端的服务器自动生成可靠的客户端库。 客户端可以利用先进的流式传输和连接功能，从而节省带宽、在更少的 TCP 连接上做更多事情，并节省 CPU 使用率和电池寿命。

为什么 gRPC 比 HTTP/2 上的任何二进制数据更好？

这实际上是 gRPC 在网络传输中的表现。 然而，gRPC 也是一组库，提供跨平台的一致性高层功能，这些功能是常见的 HTTP 库通常不提供的。例如，以下功能就是 gRPC 提供的优势：

• 在应用层进行流量控制交互
• 取消级联调用
• 负载均衡与故障转移

为什么 gRPC 比 REST 更好/更差？

gRPC 基本遵循 HTTP/2 上的 HTTP 语义，但我们明确支持全双工流式传输。 我们与典型的 REST 约定有所不同，因为为了性能原因，我们在调用分发时使用静态路径，而不是从路径、查询参数和请求体解析调用参数，这样可以减少延迟和复杂性。 我们还正规化了一组错误代码，我们认为这些错误代码比 HTTP 状态码更适用于 API 使用场景。

gRPC 如何发音？

Jee-Arr-Pee-See.