gRPC 生命周期（三）｜青训营笔记这是我参与「第四届青训营」笔记创作活动的第3天 RPC 生命周期在本节中，了

这是我参与「第四届青训营」笔记创作活动的第3天

在本节中，了解当 gRPC 客户端调用 gRPC 服务器方法时会发生什么情况。

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

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

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

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

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

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

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

指定截止时间或超时是特定于语言的：某些语言 API 在超时（持续时间）方面工作，而某些语言 API 在截止时间（固定时间点）方面工作，并且可能有也可能没有默认截止时间。

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

客户端或服务器可以随时取消 RPC。取消会立即终止 RPC，因此不会执行进一步的工作。