世界速读:GRPC核心概念、架构和生命周期
2023-06-07
博客园 2023-06-07 11:41:24
(资料图片仅供参考)
标签(空格分隔): go,grpc
官网地址:https://grpc.io/docs/what-is-grpc/core-concepts/
与许多 RPC 系统一样,gRPC 基于定义服务的思想,指定可以使用其参数和返回类型远程调用的方法。默认情况下,gRPC 使用协议缓冲区作为接口定义语言 (IDL) 来描述服务接口和有效负载消息的结构。如果需要,可以使用其他替代方案
rpc SayHello(HelloRequest) returns (HelloResponse);
rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);
从 .proto 文件中的服务定义开始,gRPC 提供了生成客户端和服务器端代码的协议缓冲区编译器插件。gRPC 用户通常在客户端调用这些 API,并在服务器端实现相应的 API - 在服务器端,服务器实现服务声明的方法,并运行 gRPC 服务器来处理客户端调用。gRPC 基础结构解码传入请求、执行服务方法并对服务响应进行编码 - 在客户端,客户端有一个称为存根的本地对象(对于某些语言,首选术语是客户端),它实现与服务相同的方法。然后,客户端可以在本地对象上调用这些方法,这些方法将调用的参数包装在适当的协议缓冲区消息类型中,将请求发送到服务器,并返回服务器的协议缓冲区响应
在本部分中,你将详细了解当 gRPC 客户端调用 gRPC 服务器方法时会发生什么情况。有关完整的实现详细信息,请参阅特定于语言的页面
首先考虑最简单的 RPC 类型,其中客户端发送单个请求并返回单个响应
服务器流式处理 RPC 类似于一元 RPC,不同之处在于服务器返回消息流以响应客户端的请求。发送所有消息后,服务器的状态详细信息(状态代码和可选状态消息)和可选的尾随元数据将发送到客户端。这样就完成了服务器端的处理。客户端在拥有服务器的所有消息后完成
客户端流式处理 RPC 类似于一元 RPC,不同之处在于客户端向服务器发送消息流而不是单个消息。服务器使用单个消息(以及其状态详细信息和可选的尾随元数据)进行响应,通常但不一定要在收到所有客户端的消息之后
在双向流式处理 RPC 中,调用由调用该方法的客户端和接收客户端元数据、方法名称和截止时间的服务器发起。服务器可以选择发回其初始元数据或等待客户端开始流式传输消息 客户端和服务器端流处理是特定于应用程序的。由于这两个流是独立的,因此客户端和服务器可以按任意顺序读取和写入消息。例如,服务器可以等到它收到客户端的所有消息后再写入其消息,或者服务器和客户端可以玩“乒乓球”——服务器收到请求,然后发回响应,然后客户端根据响应发送另一个请求,依此类推
gRPC 允许客户端指定在 RPC因DEADLINE_EXCEEDED错误终止之前,他们愿意等待 RPC 完成的时间。在服务器端,服务器可以查询特定 RPC 是否已超时, 或者还剩下多少
时间来完成 RPC
在 gRPC 中,客户端和服务器都对调用是否成功做出独立的本地确定,它们的结论可能不匹配。这意味着,例如,您可能有一个在服务器端成功完成的 RPC(“我已经发送了我所有的响应!”),但在客户端失败(“响应在我的截止日期之后到达!”)。服务器也可以在客户端发送所有请求之前决定完成
客户端或服务器可以随时取消 RPC。取消会立即终止 RPC,以便不再执行任何进
一步的工作