基于grpc 的客户端通信协议 grpc 使用场景

转载

jack 2024-05-07 14:54:51

文章标签 基于grpc 的客户端通信协议 gRPC grpc rpc 网络协议 文章分类 云原生云计算

gRPC是什么？

gRPC 是一种现代开源高性能远程过程调用 (RPC) 框架，可以在任何环境中运行。它可以通过对负载平衡、跟踪、健康检查和身份验证的可插拔支持，有效地连接数据中心内和数据中心之间的服务。它还适用于分布式计算的最后一英里，将设备、移动应用程序和浏览器连接到后端服务。

gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.

主要使用场景（The main usage scenarios）

在微服务风格架构中高效连接多语言服务
将移动设备、浏览器客户端连接到后端服务
生成高效的客户端库

Efficiently connecting polyglot services in microservices style architecture
Connecting mobile devices, browser clients to backend services
Generating efficient client libraries

核心功能让它很棒（Core features that make it awesome）

11 种语言的惯用客户端库
在线上高效且具有简单的服务定义框架
使用基于 http/2 的传输进行双向流传输
可插拔身份验证、跟踪、负载平衡和健康检查

Idiomatic client libraries in 11 languages
Highly efficient on wire and with a simple service definition framework
Bi-directional streaming with http/2 based transport
Pluggable auth, tracing, load balancing and health checking

概述

在 gRPC 中，客户端应用程序可以直接调用不同机器上的服务器应用程序上的方法，就像它是本地对象一样，使您更容易创建分布式应用程序和服务。与许多 RPC 系统一样，gRPC 基于定义服务的思想，指定可以通过参数和返回类型远程调用的方法。在服务端，服务端实现了这个接口并运行了一个 gRPC 服务端来处理客户端调用。在客户端，客户端有一个存根（在某些语言中简称为客户端），它提供与服务器相同的方法。

In gRPC, a client application can directly call a method on a server application on a different machine as if it were a local object, making it easier for you to create distributed applications and services. As in many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. On the server side, the server implements this interface and runs a gRPC server to handle client calls. On the client side, the client has a stub (referred to as just a client in some languages) that provides the same methods as the server.

基于grpc 的客户端通信协议 grpc 使用场景_grpc

RPC 客户端和服务器可以在各种环境中运行和相互通信——从 Google 内部的服务器到你自己的桌面——并且可以用任何 gRPC 支持的语言编写。因此，例如，您可以使用 Go、Python 或 Ruby 中的客户端轻松地使用 Java 创建 gRPC 服务器。此外，最新的 Google API 将具有其接口的 gRPC 版本，让您可以轻松地将 Google 功能构建到您的应用程序中。

gRPC clients and servers can run and talk to each other in a variety of environments - from servers inside Google to your own desktop - and can be written in any of gRPC’s supported languages. So, for example, you can easily create a gRPC server in Java with clients in Go, Python, or Ruby. In addition, the latest Google APIs will have gRPC versions of their interfaces, letting you easily build Google functionality into your applications.

使用协议缓冲区（Protocol Buffers）

默认情况下，gRPC 使用协议缓冲区（Protocol Buffers），谷歌成熟的开源机制，用于序列化结构化数据（虽然它可以与其他数据格式如JSON一起使用）。这是它如何工作的快速介绍。如果您已经熟悉协议缓冲区，请随时跳到下一部分。

By default, gRPC uses Protocol Buffers, Google’s mature open source mechanism for serializing structured data (although it can be used with other data formats such as JSON). Here’s a quick intro to how it works. If you’re already familiar with protocol buffers, feel free to skip ahead to the next section.

使用协议缓冲区的第一步是定义要在proto 文件中序列化的数据的结构：这是一个带有.proto扩展名的普通文本文件。协议缓冲区数据被构造为消息，其中每条消息都是一个小的逻辑信息记录，包含一系列称为字段的名称-值对。这是一个简单的例子：

The first step when working with protocol buffers is to define the structure for the data you want to serialize in a proto file: this is an ordinary text file with a .proto extension. Protocol buffer data is structured as messages, where each message is a small logical record of information containing a series of name-value pairs called fields. Here’s a simple example:

message Person {
  string name = 1;
  int32 id = 2;
  bool has_ponycopter = 3;
}

然后，一旦指定了数据结构，就可以使用协议缓冲区编译器protoc从原型定义中生成首选语言的数据访问类。这些为每个字段提供了简单的访问器，例如name()和set_name()，以及将整个结构序列化/解析为原始字节/从原始字节序列化/解析整个结构的方法。因此，例如，如果您选择的语言是 C++，则在上面的示例上运行编译器将生成一个名为Person. 然后，您可以在应用程序中使用此类来填充、序列化和检索Person协议缓冲区消息。

Then, once you’ve specified your data structures, you use the protocol buffer compiler protoc to generate data access classes in your preferred language(s) from your proto definition. These provide simple accessors for each field, like name() and set_name(), as well as methods to serialize/parse the whole structure to/from raw bytes. So, for instance, if your chosen language is C++, running the compiler on the example above will generate a class called Person. You can then use this class in your application to populate, serialize, and retrieve Person protocol buffer messages.

您在普通的 proto 文件中定义 gRPC 服务，将 RPC 方法参数和返回类型指定为协议缓冲区消息：

You define gRPC services in ordinary proto files, with RPC method parameters and return types specified as protocol buffer messages:

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

gRPC 使用protoc特殊的 gRPC 插件从您的 proto 文件生成代码：您将获得生成的 gRPC 客户端和服务器代码，以及用于填充、序列化和检索消息类型的常规协议缓冲区代码。您将在下面看到一个示例。

gRPC uses protoc with a special gRPC plugin to generate code from your proto file: you get generated gRPC client and server code, as well as the regular protocol buffer code for populating, serializing, and retrieving your message types. You’ll see an example of this below.

要了解有关协议缓冲区的更多信息，包括如何protoc使用您选择的语言安装gRPC 插件，请参阅协议缓冲区（）文档Protocol buffer协议缓冲区（）文档.

To learn more about protocol buffers, including how to install protoc with the gRPC plugin in your chosen language, see the protocol buffers documentation.

协议缓冲区版本(Protocol buffer versions)

虽然协议缓冲区(Protocol buffer) 开源用户已经可以使用一段时间了，该站点的大多数示例使用协议缓冲区版本 3 (proto3)，它具有稍微简化的语法、一些有用的新功能并支持更多语言。Proto3 目前可用于 Java、C++、Dart、Python、Objective-C、C#、精简版运行时（Android Java）、Ruby 和来自协议缓冲区 GitHub 存储库的JavaScript ，以及来自golang/protobuf 官方包的 Go 语言生成器，更多的语言正在开发中。您可以在proto3 语言指南中找到更多信息和参考文档可用于每种语言。参考文档还包括正式的规范对于.proto文件格式。

While protocol buffers have been available to open source users for some time, most examples from this site use protocol buffers version 3 (proto3), which has a slightly simplified syntax, some useful new features, and supports more languages. Proto3 is currently available in Java, C++, Dart, Python, Objective-C, C#, a lite-runtime (Android Java), Ruby, and JavaScript from the protocol buffers GitHub repo, as well as a Go language generator from the golang/protobuf official package, with more languages in development. You can find out more in the proto3 language guide and the reference documentation available for each language. The reference documentation also includes a formal specification for the .proto file format.

一般来说，虽然您可以使用 proto2（当前的默认协议缓冲区版本），但我们建议您将 proto3 与 gRPC 一起使用，因为它可以让您使用所有 gRPC 支持的语言，并避免与 proto2 客户端通信的兼容性问题proto3 服务器，反之亦然。

In general, while you can use proto2 (the current default protocol buffers version), we recommend that you use proto3 with gRPC as it lets you use the full range of gRPC-supported languages, as well as avoiding compatibility issues with proto2 clients talking to proto3 servers and vice versa.

核心概念、架构和生命周期

对关键 gRPC 概念的介绍，以及 gRPC 架构和 RPC 生命周期的概述。

概述

服务定义(Service definition)

与许多 RPC 系统一样，gRPC 基于定义服务的思想，指定可以使用参数和返回类型远程调用的方法。默认情况下，gRPC 使用协议缓冲区作为接口定义语言 (IDL)，用于描述服务接口和有效负载消息的结构。如果需要，可以使用其他替代方案。

Like many RPC systems, gRPC is based around the idea of defining a service, specifying the methods that can be called remotely with their parameters and return types. By default, gRPC uses protocol buffers as the Interface Definition Language (IDL) for describing both the service interface and the structure of the payload messages. It is possible to use other alternatives if desired.

service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

gRPC 允许您定义四种服务方法：

gRPC lets you define four kinds of service method:

一元 RPC，客户端向服务器发送单个请求并返回单个响应，就像普通的函数调用一样。

Unary RPCs where the client sends a single request to the server and gets a single response back, just like a normal function call.

rpc SayHello(HelloRequest) returns (HelloResponse);

服务器流式 RPC，客户端向服务器发送请求并获取流以读取一系列消息。客户端从返回的流中读取，直到没有更多消息。gRPC 保证单个 RPC 调用中的消息排序。

Server streaming RPCs where the client sends a request to the server and gets a stream to read a sequence of messages back. The client reads from the returned stream until there are no more messages. gRPC guarantees message ordering within an individual RPC call.

rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);

客户端流式 RPC，其中客户端写入一系列消息并将它们发送到服务器，再次使用提供的流。一旦客户端完成写入消息，它等待服务器读取它们并返回其响应。gRPC 再次保证单个 RPC 调用中的消息排序。

Client streaming RPCs where the client writes a sequence of messages and sends them to the server, again using a provided stream. Once the client has finished writing the messages, it waits for the server to read them and return its response. Again gRPC guarantees message ordering within an individual RPC call.

rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);

双向流式 RPC，其中双方使用读写流发送一系列消息。这两个流独立运行，因此客户端和服务器可以按照他们喜欢的任何顺序进行读写：例如，服务器可以在写入响应之前等待接收所有客户端消息，或者它可以交替读取消息然后写入消息，或其他一些读取和写入的组合。保留每个流中消息的顺序。

Bidirectional streaming RPCs where both sides send a sequence of messages using a read-write stream. The two streams operate independently, so clients and servers can read and write in whatever order they like: for example, the server could wait to receive all the client messages before writing its responses, or it could alternately read a message then write a message, or some other combination of reads and writes. The order of messages in each stream is preserved.

rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);

您将在下面的RPC 生命周期部分中了解有关不同类型 RPC 的更多信息。

You’ll learn more about the different types of RPC in the RPC life cycle section below.

使用 API (Using the API)

从.proto文件中的服务定义开始，gRPC 提供了生成客户端和服务器端代码的协议缓冲区编译器插件。gRPC 用户通常在客户端调用这些 API，并在服务器端实现相应的 API。

Starting from a service definition in a .proto file, gRPC provides protocol buffer compiler plugins that generate client- and server-side code. gRPC users typically call these APIs on the client side and implement the corresponding API on the server side.

在服务器端，服务器实现服务声明的方法并运行 gRPC 服务器来处理客户端调用。gRPC 基础架构解码传入请求、执行服务方法并编码服务响应。
在客户端，客户端有一个称为stub（对于某些语言，首选术语是client）的本地对象，它实现与服务相同的方法。然后客户端可以在本地对象上调用这些方法，将调用的参数包装在适当的协议缓冲区消息类型中 - gRPC 负责将请求发送到服务器并返回服务器的协议缓冲区响应。

On the server side, the server implements the methods declared by the service and runs a gRPC server to handle client calls. The gRPC infrastructure decodes incoming requests, executes service methods, and encodes service responses.
On the client side, the client has a local object known as stub (for some languages, the preferred term is client) that implements the same methods as the service. The client can then just call those methods on the local object, wrapping the parameters for the call in the appropriate protocol buffer message type - gRPC looks after sending the request(s) to the server and returning the server’s protocol buffer response(s).

同步与异步(Synchronous vs. asynchronous)

在响应从服务器到达之前阻塞的同步 RPC 调用最接近于 RPC 所追求的过程调用的抽象。另一方面，网络本质上是异步的，在许多情况下，能够在不阻塞当前线程的情况下启动 RPC 很有用。

Synchronous RPC calls that block until a response arrives from the server are the closest approximation to the abstraction of a procedure call that RPC aspires to. On the other hand, networks are inherently asynchronous and in many scenarios it’s useful to be able to start RPCs without blocking the current thread.

大多数语言中的 gRPC 编程 API 都有同步和异步两种风格。您可以在每种语言的教程和参考文档中找到更多信息（完整的参考文档即将推出）。

The gRPC programming API in most languages comes in both synchronous and asynchronous flavors. You can find out more in each language’s tutorial and reference documentation (complete reference docs are coming soon).

RPC 生命周期 (RPC life cycle)

在本节中，您将仔细了解当 gRPC 客户端调用 gRPC 服务器方法时会发生什么。有关完整的实现详细信息，请参阅特定于语言的页面。

In this section, you’ll take a closer look at what happens when a gRPC client calls a gRPC server method. For complete implementation details, see the language-specific pages.

一元RPC (Unary RPC)

首先考虑客户端发送单个请求并返回单个响应的最简单的 RPC 类型。

First consider the simplest type of RPC where the client sends a single request and gets back a single response.

一旦客户端调用了存根方法，服务器就会收到通知：RPC 已经被调用，同时包含客户端的元数据、方法名称和指定的截止日期（如果适用）。
然后服务器可以立即发送回它自己的初始元数据（必须在任何响应之前发送），或者等待客户端的请求消息。首先发生的是特定于应用程序的。
一旦服务器收到客户端的请求消息，它就会做任何必要的工作来创建和填充响应。然后将响应连同状态详细信息（状态代码和可选状态消息）和可选的尾随元数据一起返回（如果成功）到客户端。
如果响应状态为OK，则客户端得到响应，在客户端完成调用。

Once the client calls a stub method, the server is notified that the RPC has been invoked with the client’s metadata for this call, the method name, and the specified deadline if applicable.
The server can then either send back its own initial metadata (which must be sent before any response) straight away, or wait for the client’s request message. Which happens first, is application-specific.
Once the server has the client’s request message, it does whatever work is necessary to create and populate a response. The response is then returned (if successful) to the client together with status details (status code and optional status message) and optional trailing metadata.
If the response status is OK, then the client gets the response, which completes the call on the client side.

服务器流式RPC (Server streaming RPC)

服务器流式 RPC 类似于一元 RPC，不同之处在于服务器返回消息流以响应客户端的请求。发送完所有消息后，服务器的状态详细信息（状态代码和可选状态消息）和可选的尾随元数据将发送到客户端。这样就完成了服务器端的处理。一旦客户端拥有服务器的所有消息，它就完成了。

A server-streaming RPC is similar to a unary RPC, except that the server returns a stream of messages in response to a client’s request. After sending all its messages, the server’s status details (status code and optional status message) and optional trailing metadata are sent to the client. This completes processing on the server side. The client completes once it has all the server’s messages.

客户端流式 RPC (Client streaming RPC)

客户端流式 RPC 类似于一元 RPC，不同之处在于客户端向服务器发送消息流而不是单个消息。服务器用一条消息（连同它的状态详细信息和可选的尾随元数据）进行响应，通常但不一定是在它收到所有客户端的消息之后。

A client-streaming RPC is similar to a unary RPC, except that the client sends a stream of messages to the server instead of a single message. The server responds with a single message (along with its status details and optional trailing metadata), typically but not necessarily after it has received all the client’s messages.

双向流式RPC (Bidirectional streaming RPC)

在双向流式 RPC 中，调用由调用方法的客户端和接收客户端元数据、方法名称和截止日期的服务器发起。服务器可以选择发回其初始元数据或等待客户端开始流式传输消息。

In a bidirectional streaming RPC, the call is initiated by the client invoking the method and the server receiving the client metadata, method name, and deadline. The server can choose to send back its initial metadata or wait for the client to start streaming messages.

客户端和服务器端流处理是特定于应用程序的。由于两个流是独立的，客户端和服务器可以按任意顺序读写消息。例如，服务器可以等到收到所有客户端的消息后再写入消息，或者服务器和客户端可以玩“乒乓”——服务器收到请求，然后发回响应，然后客户端发送基于响应的另一个请求，依此类推。

Client- and server-side stream processing is application specific. Since the two streams are independent, the client and server can read and write messages in any order. For example, a server can wait until it has received all of a client’s messages before writing its messages, or the server and client can play “ping-pong” – the server gets a request, then sends back a response, then the client sends another request based on the response, and so on.

截止日期/超时 (Deadlines/Timeouts)

gRPC 允许客户端指定在 RPC 因DEADLINE_EXCEEDED错误终止之前他们愿意等待 RPC 完成多长时间。在服务器端，服务器可以查询特定的 RPC 是否超时，或者还剩下多少时间来完成 RPC。

gRPC allows clients to specify how long they are willing to wait for an RPC to complete before the RPC is terminated with a DEADLINE_EXCEEDED error. On the server side, the server can query to see if a particular RPC has timed out, or how much time is left to complete the RPC.

指定截止日期或超时是特定于语言的：一些语言 API 根据超时（持续时间）工作，而某些语言 API 根据截止日期（固定时间点）工作，可能有也可能没有默认截止日期。

Specifying a deadline or timeout is language specific: some language APIs work in terms of timeouts (durations of time), and some language APIs work in terms of a deadline (a fixed point in time) and may or may not have a default deadline.

RPC 终止 (RPC termination)

在 gRPC 中，客户端和服务器都对调用的成功做出独立和本地的判断，它们的结论可能不一致。这意味着，例如，您可能有一个 RPC 在服务器端成功完成（“我已经发送了我所有的响应！”）但在客户端失败（“响应在我的截止日期之后到达！”）。服务器也有可能在客户端发送所有请求之前决定完成。

In gRPC, both the client and server make independent and local determinations of the success of the call, and their conclusions may not match. This means that, for example, you could have an RPC that finishes successfully on the server side (“I have sent all my responses!") but fails on the client side (“The responses arrived after my deadline!"). It’s also possible for a server to decide to complete before a client has sent all its requests.

取消 RPC (Cancelling an RPC)

客户端或服务器都可以随时取消 RPC。取消会立即终止 RPC，以便不再进行任何工作。

Either the client or the server can cancel an RPC at any time. A cancellation terminates the RPC immediately so that no further work is done.

警告

取消之前所做的更改不会回滚。

Warning
Changes made before a cancellation are not rolled back.

元数据 (Metadata)

元数据是有关特定 RPC 调用（例如身份验证详细信息）的信息，其形式为键值对列表，其中键是字符串，值通常是字符串，但也可以是二进制数据。元数据对 gRPC 本身是不透明的——它允许客户端提供与服务器调用相关的信息，反之亦然。

Metadata is information about a particular RPC call (such as authentication details) in the form of a list of key-value pairs, where the keys are strings and the values are typically strings, but can be binary data. Metadata is opaque to gRPC itself - it lets the client provide information associated with the call to the server and vice versa.

对元数据的访问取决于语言。

Access to metadata is language dependent.

频道 (Channels)

gRPC 通道提供到指定主机和端口上的 gRPC 服务器的连接。它在创建客户端存根时使用。客户端可以指定通道参数来修改 gRPC 的默认行为，例如打开或关闭消息压缩。通道具有状态，包括connected和idle。

A gRPC channel provides a connection to a gRPC server on a specified host and port. It is used when creating a client stub. Clients can specify channel arguments to modify gRPC’s default behavior, such as switching message compression on or off. A channel has state, including connected and idle.

gRPC 如何处理关闭通道取决于语言。某些语言还允许查询通道状态。

How gRPC deals with closing a channel is language dependent. Some languages also permit querying channel state.

常问问题

什么是 gRPC？

gRPC 是一种现代的开源远程过程调用 (RPC) 框架，可以在任何地方运行。它使客户端和服务器应用程序能够透明地通信，并使构建连接系统变得更加容易。

阅读较长的动机和设计原则文章，了解我们为什么创建 gRPC 的背景。

gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems.
Read the longer Motivation & Design Principles post for background on why we created gRPC.

gRPC 代表什么？

gRPC Remote Procedure Calls, of course!

我为什么要使用 gRPC？ (Why would I want to use gRPC?)

主要使用场景：

低延迟、高度可扩展的分布式系统。
开发与云服务器通信的移动客户端。
设计一个需要准确、高效且独立于语言的新协议。
分层设计以启用扩展，例如。身份验证、负载平衡、日志记录和监控等。

The main usage scenarios:
Low latency, highly scalable, distributed systems.
Developing mobile clients which are communicating to a cloud server.
Designing a new protocol that needs to be accurate, efficient and language independent.
Layered design to enable extension eg. authentication, load balancing, logging and monitoring etc.

谁在使用它，为什么？(Who’s using this and why?)

gRPC 是一个云原生计算基础 (CNCF) 项目。

长期以来，Google 一直在使用 gRPC 中的许多底层技术和概念。当前的实现正在 Google 的多个云产品和 Google 面向外部的 API 中使用。它也被Square 使用, 网飞, 核心操作系统,码头工人,蟑螂数据库,思科,瞻博网络以及许多其他组织和个人。

gRPC is a Cloud Native Computing Foundation (CNCF) project.
Google has been using a lot of the underlying technologies and concepts in gRPC for a long time. The current implementation is being used in several of Google’s cloud products and Google externally facing APIs. It is also being used by Square, Netflix, CoreOS, Docker, CockroachDB, Cisco, Juniper Networks and many other organizations and individuals.

支持哪些编程语言？(Which programming languages are supported?)

请参阅官方支持的语言和平台。

See Officially supported languages and platforms.

如何开始使用 gRPC？(How do I get started using gRPC?)

您可以按照此处的说明开始安装 gRPC 。或者前往gRPC GitHub 组织页面，选择您感兴趣的运行时或语言，然后按照自述文件说明进行操作。

You can start with installation of gRPC by following instructions here. Or head over to the gRPC GitHub org page, pick the runtime or language you are interested in, and follow the README instructions.

gRPC 在哪个许可证下？ (Which license is gRPC under?)

所有实现均在Apache 2.0下获得许可.

All implementations are licensed under Apache 2.0.

我怎样才能做出贡献？ (How can I contribute?)

非常欢迎贡献者，并且存储库托管在 GitHub 上。我们期待社区反馈、添加和错误。个人贡献者和企业贡献者都需要签署我们的 CLA。如果您对围绕 gRPC 的项目有想法，请阅读指南并在此处提交. 我们在gRPC 生态系统下有越来越多的项目 GitHub 上的组织。

Contributors are highly welcome and the repositories are hosted on GitHub. We look forward to community feedback, additions and bugs. Both individual contributors and corporate contributors need to sign our CLA. If you have ideas for a project around gRPC, read guidelines and submit here. We have a growing list of projects under the gRPC Ecosystem organization on GitHub.

文档在哪里？ (Where is the documentation?)

查看grpc.io 上的文档。

Check out the documentation right here on grpc.io.

路线图是什么？(What is the road map?)

gRPC 项目有一个 RFC 流程，通过该流程设计新功能并批准实施。他们在这个存储库中被跟踪.

The gRPC project has an RFC process, through which new features are designed and approved for implementation. They are tracked in this repository.

gRPC 版本支持多长时间？ (How long are gRPC releases supported for?)

gRPC 项目不做 LTS 版本。鉴于上述滚动发布模型，我们支持当前、最新版本和之前的版本。此处的支持意味着错误修复和安全修复。

The gRPC project does not do LTS releases. Given the rolling release model above, we support the current, latest release and the release prior to that. Support here means bug fixes and security fixes.

什么是 gRPC 版本控制策略？(What is the gRPC versioning policy?)

在此处查看 gRPC 版本控制政策.

See the gRPC versioning policy here.

最新的 gRPC 版本是什么？(What is the latest gRPC Version?)

最新的发布标签是 v1.41.0。

The latest release tag is v1.41.0.

gRPC 何时发布？(When do gRPC releases happen?)

gRPC 项目在主分支尖端始终稳定的模型中工作。该项目（跨各种运行时）旨在尽最大努力每 6 周发布一次检查点版本。在此处查看发布时间表.

The gRPC project works in a model where the tip of the master branch is stable at all times. The project (across the various runtimes) targets to ship checkpoint releases every 6 weeks on a best effort basis. See the release schedule here.

如何报告 gRPC 中的安全漏洞？(How can I report a security vulnerability in gRPC?)

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

To report a security vulnerability in gRPC, please follow the process documented here.

我可以在浏览器中使用它吗？(Can I use it in the browser?)

该GRPC的Web 项目普遍可用。

The gRPC-Web project is Generally Available.

我可以将 gRPC 与我最喜欢的数据格式（JSON、Protobuf、Thrift、XML）一起使用吗？(Can I use gRPC with my favorite data format (JSON, Protobuf, Thrift, XML) ?)

是的。gRPC 旨在可扩展以支持多种内容类型。初始版本包含对 Protobuf 的支持以及对其他成熟度不同的内容类型（如 FlatBuffers 和 Thrift）的外部支持。

Yes. gRPC is designed to be extensible to support multiple content types. The initial release contains support for Protobuf and with external support for other content types such as FlatBuffers and Thrift, at varying levels of maturity.

我可以在服务网格中使用 gRPC 吗？(Can I use gRPC in a service mesh?)

是的。gRPC 应用程序可以像任何其他应用程序一样部署在服务网格(service mesh)中。gRPC 还支持xDS API这使得在没有 sidecar 代理的服务网格中部署 gRPC 应用程序成为可能。此处列出了gRPC 中支持的无代理服务网格功能.

Yes. gRPC applications can be deployed in a service mesh like any other application. gRPC also supports xDS APIs which enables deploying gRPC applications in a service mesh without sidecar proxies. The proxyless service mesh features supported in gRPC are listed here.

gRPC 如何帮助移动应用程序开发？(How does gRPC help in mobile application development?)

gRPC 和 Protobuf 提供了一种简单的方法来精确定义服务，并为 iOS、Android 和提供后端的服务器自动生成可靠的客户端库。客户端可以利用先进的流媒体和连接功能，这有助于节省带宽、通过更少的 TCP 连接做更多的事情并节省 CPU 使用率和电池寿命。

gRPC and Protobuf provide an easy way to precisely define a service and auto generate reliable client libraries for iOS, Android and the servers providing the back end. The clients can take advantage of advanced streaming and connection features which help save bandwidth, do more over fewer TCP connections and save CPU usage and battery life.

为什么 gRPC 比 HTTP/2 上的任何二进制 blob 都好？(Why is gRPC better than any binary blob over HTTP/2?)

这主要是 gRPC 在线上的内容。然而，gRPC 也是一组库，它们将跨平台一致地提供更高级别的功能，而通用 HTTP 库通常不会提供这些功能。此类功能的示例包括：

与应用层流控交互
级联呼叫取消
负载平衡和故障转移

This is largely what gRPC is on the wire. However gRPC is also a set of libraries that will provide higher-level features consistently across platforms that common HTTP libraries typically do not. Examples of such features include:
interaction with flow-control at the application layer
cascading call-cancellation
load balancing & failover

为什么 gRPC 比 REST 好/差？(Why is gRPC better/worse than REST?)

gRPC 在很大程度上遵循 HTTP/2 上的 HTTP 语义，但我们明确允许全双工流。我们与典型的 REST 约定不同，因为我们在调用调度期间出于性能原因使用静态路径，因为解析来自路径、查询参数和有效负载主体的调用参数会增加延迟和复杂性。我们还对一组错误进行了形式化，我们认为这些错误比 HTTP 状态代码更直接适用于 API 用例。

gRPC largely follows HTTP semantics over HTTP/2 but we explicitly allow for full-duplex streaming. We diverge from typical REST conventions as we use static paths for performance reasons during call dispatch as parsing call parameters from paths, query parameters and payload body adds latency and complexity. We have also formalized a set of errors that we believe are more directly applicable to API use cases than the HTTP status codes.