您的位置：首页>教程>正文

教程正文

gRPC RPC生命周期

现在让我们更仔细地看看当gRPC客户端调用gRPC服务器方法时会发生什么。我们不看实现细节，您可以在我们的语言特定页面中找到更多关于这些细节的信息。

首先，让我们看一下最简单的RPC类型，其中客户端发送单个请求服务求返回单个响应。

一旦客户端调用stub/client对象上的方法，服务器就会被通知RPC已经被调用，调用时带有客户端的metadata、方法名称以及指定的截止日期(如果可用)。

然后，服务器可以立即返回自己的初始metadata(必须在任何响应之前发送)，或者等待客户端的请求消息-首先发生的消息是特定于应用程序的。

一旦服务器收到客户端的请求消息，它就会做必要的工作来创建和填充其响应。然后，响应连同状态详细信息(状态代码和可选的状态消息)和可选的尾随metadata一起返回给客户端(如果成功)。

如果状态为OK，客户端会得到响应，从而在客户端完成调用。

服务器流式RPC类似于上面的一元RPC，只是服务器在收到客户端的请求消息后会返回一个响应流。返回所有响应后，服务器的状态详细信息(状态代码和可选状态消息)和可选的尾随metadata将被发回服务器端完成。一旦客户端收到服务器的所有响应，它就会完成全部调用。

客户端流式RPC也类似于一元RPC，只是客户端向服务器发送请求流，而不是单个请求。服务器发送回一个响应，通常但不一定是在收到所有客户端请求后，连同其状态详细信息和可选的尾随metadata。

在双向流式RPC中，调用再次由调用方法的客户端发起，服务器接收客户端metadata,、方法名称和截止日期。同样，服务器可以选择发回其初始metadata,，或者等待客户端开始发送请求。

接下来会发生什么取决于应用程序，因为客户端和服务器可以按任何顺序读写-这些流完全独立运行。例如，服务器可以等到收到所有客户端的消息后再写响应，或者服务器和客户端可以实现“ping-pong”:服务器收到请求，然后发回响应，然后客户端根据响应发送另一个请求，依此类推。

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

截止日期或超时的指定方式因语言而异-例如，并非所有语言都有默认截止日期，有些语言API根据截止日期(固定时间点)工作，有些语言API根据超时(持续时间)工作。

在gRPC中，客户端和服务器都独立地自行确定调用是否成功，他们的结果可能不一致。这意味着，例如，您可以在服务器端成功完成RPC (“我已经发送了我的所有回复！”)但是在客户端失败了(“回复在我的截止日期之后到达！”)中。服务器也可以在客户端发送所有请求之前决定完成。

客户端或服务器可以随时取消RPC,取消会立即终止RPC，这样就不会做进一步的工作。注意这不是“undo”:取消之前所做的更改不会回滚。

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

元数据的访问依赖于语言。

gRPC信道提供到指定主机和端口上的gRPC服务器的连接，并在创建客户端存根(或某些语言中的“客户端”)时使用。客户端可以指定信道参数来修改gRPC的默认行为，例如打开和关闭消息压缩。信道有状态，包括连接和空闲。

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