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

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

标签（空格分隔）： go,grpc

官网地址：https://grpc.io/docs/what-is-grpc/core-concepts/

概述

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

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);

使用接口

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

 - 在服务器端，服务器实现服务声明的方法，并运行 gRPC 服务器来处理客户端调用。gRPC
   基础结构解码传入请求、执行服务方法并对服务响应进行编码

 - 在客户端，客户端有一个称为存根的本地对象（对于某些语言，首选术语是客户端），它实现与服务相同的方法。然后，客户端可以在本地对象上调用这些方法，这些方法将调用的参数包装在适当的协议缓冲区消息类型中，将请求发送到服务器，并返回服务器的协议缓冲区响应

RPC 生命周期

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

Unary RPC【一元RPC】

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

• 客户端调用存根方法后，将通知服务器已使用此调用的客户端元数据、方法名称和指定的截止时间（如果适用）调用了 RPC
• 然后，服务器可以立即发回自己的初始元数据（必须在任何响应之前发送），也可以等待客户端的请求消息。首先发生，是特定于应用程序的
• 一旦服务器获得客户端的请求消息，它就会执行创建和填充响应所需的任何工作。然后，响应（如果成功）连同状态详细信息（状态代码和可选状态消息）和可选的尾随元数据一起返回给客户端
• 如果响应状态为“正常”，则客户端将获得响应，从而在客户端完成调用

Server streaming RPC【服务器流RPC】

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

Client streaming RPC【客户端流RPC】

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

Bidirectional streaming RPC【双向流RPC】

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

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

截止时间/超时

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

时间来完成 RPC

RPC 终止

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

取消 RPC

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

一步的工作