gRPC(官方文档翻译)

gRPC(官方文档翻译)

官方原文:
https://grpc.io/docs/what-is-grpc/introduction/
https://grpc.io/docs/what-is-grpc/core-concepts/

1. 概述

ProtoBuf 作为gRPC的接口定义语言(IDL)和底层消息交换格式。在gRPC中客户端应用程序可以志杰调用不同机器上的服务器应用程序上的方法，就像它是本地对象一样，使我们更容易创建分布式应用程序和服务。与许多 RPC 系统一样，gRPC 基于定义服务的思想，指定可以远程调用的方法及其参数和返回类型。 在服务端，服务端实现这个接口并运行一个gRPC服务器来处理客户端调用。 在客户端，客户端有一个存根(某些语言中称为客户机)，它提供与服务器相同的方法。

gRPC 客户端和服务器可以在各种环境中运行和相互通信——从 Google 内部服务器到您自己的桌面——并且可以用任何 gRPC 支持的语言编写。甚至能够将 Google API提供的功能构建到自己的应用程序中。

1.1 服务定义

gRPC基于定义服务的思想，默认情况下，gRPC使用protobuf作为接口定义语言(IDL),用于描述接口和有效负载消息的结构，如果有需要，可以使用其他替代方案。

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

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}

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

• 一元RPC，其中客户端向服务器发送单个请求并获得单个响应，就想正常的函数调用一样

  rpc SayHello(HelloRequest) returns (HelloResponse);
  

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

  rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
  

• 客户端流式RPC，其中客户端发起流并向流中写入一系列消息将它们发送给服务器。一旦客户端完成了消息的写入，它就等待服务器读取流中的数据并返回它的响应。gRPC再次保证了单个RPC调用中的消息顺序。

  rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
  

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

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

1.3 使用 API

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

• 在服务端，服务端实现服务声明的方法，并运行一个 gRPC 服务器来处理客户端调用。gRPC 基础架构解码传入请求、执行服务方法并编码服务响应。
• 在客户端，客户端有一个名为stub的本地对象，它实现了与服务器相同的方法(由gRPC实现)。然后客户端可以在本地上调用这些方法，将调用的参数包装在适当的协议缓冲区消息类型中 gRPC 会将请求发送到服务器并返回服务器的协议缓冲响应后进行处理。

1.3 同步与异步

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

gRPC 为大多数编程语言提供的 API 有同步和异步两种风格。可以在每种语言的教程和参考文档中找到更多信息。在gRPC-GO中，RPC以阻塞/同步

1.4 RPC 生命周期

下文介绍普遍意义上 gRPC客户端调用gRPC服务器方法时会发生什么。有关完整实施细节，需参考特定语言。在GO中GRPC的生命周期？

1.4.1 一元 RPC

最简单的RPC类型，其中客户端发送单个请求并返回单个响应。

1. 一旦客户端调用了一个存根方法，服务器就会被通知该RPC已被调用，其中包含该调用的客户端元数据、方法名称和指定的截止日期(如果适用)。
2. 然后，服务器可以立即发回自己的初始元素据(必须在任何响应之前发送)，或等待客户端的请求消息。首先发生的是特定于应用程序的。
3. 一旦服务器收到客户端的请求消息，它就会执行任何必要的工作来创建和填充响应。然后将响应联通状态详细信息(状态码和可选状态信息)和可选的尾随元数据一起返回给客户端。
4. 如果响应状态为OK，则客户端得到响应，从而完成客户端的调用。

1.4.2 服务器流式 RPC

服务器流式 RPC类似于一元 RPC，不同的是服务器返回消息流以响应客户端的请求。发送所有消息后，服务器的状态详细信息(状态码和可选状态消息)和可选的后续元数据将发送给客户端。这就完成了服务端的处理。客户端在收到服务器的所有消息后完成。

1.4.3 客户端流式 RPC

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

1.4.4 双向流式RPC

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

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

1.4.5 截止日期/超时

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

指定期限或超时是特定于语言的：一些语言 API 根据超时(持续时间)工作，而一些语言API根据期限(固定时间点)工作，可能有也可能没有默认期限。

1.4.6 RPC终止

在 gRPC中，客户端和服务器都对可以对调用的成功与否做出独立的决定，并且它们的结论可能不匹配。这意味着，例如，一个请求在服务器端成功完成RPC**(“我已经发送了所有响应！”)但在客户端失败了(“响应在我的截止日期之后到达！”)**。 服务器也可以在客户端发送的所有请求到达之前决定终止此次请求。

1.4.7 取消RPC

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

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

1.5 元数据

元数据是有关特定 RPC 调用的信息( 例如身份验证详细信息)，采用键值对列表的形式，其中键是字符串，值通常是字符串，但也可以是二进制数据。

键不区分大小写，由ASCII字符、数字和特殊字符-, _, .组成，并且不能以grpc-开头(这是为grpc本身保留的)。二进制值的键以-bin结尾，而ASCII值的键不以-bin结束。

元数据对 gRPC 本身是不透明的-它允许客户端提供与对服务器的调用相关联的信息，反之亦然。

访问元数据取决于语言

1.6 Channel

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

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