时间戳

首页 > 解决方案 > gRPC 调用、通道、连接和​​ HTTP/2 生命周期

grpc - gRPC 调用、通道、连接和​​ HTTP/2 生命周期

问题描述

我阅读了 gRPC Core 概念、架构和生命周期，但没有深入到我希望看到的深度。有RPC 调用、gRPC 通道、gRPC 连接（本文未描述）和 HTTP/2 连接（本文未描述）。

我有兴趣知道这些是如何结合在一起的。例如，当 RPC 抛出异常时，通道会发生什么？当通道关闭时 gRPC 连接会发生什么？通道什么时候关闭？gRPC 连接何时关闭？心跳？如果超过期限怎么办？

任何人都可以回答这些问题，或者向我指出可以的资源吗？

标签： grpcgrpc-java

解决方案

连接不是 gRPC 概念。它不是普通 API 的一部分，而是一个实现细节。这应该被视为相当正常，就像 HTTP 库提供有关 HTTP 交换的详细信息但不公开连接。

最好将 RPC 和连接视为两个大部分独立的系统。

对于“托管”的不同定义，唯一真正的保证是“连接由通道管理”。如果您希望释放连接和其他资源，则必须在不再使用时关闭通道。其他细节要么是实现细节，要么是高级 API 细节。

没有“gRPC 连接”。“gRPC 连接”只是一个标准的“HTTP/2 连接”。除了这甚至是许多 gRPC 实现中传输的实现细节。这允许使用替代的“连接”类型，如“进程内”或 QUIC（通过 Cronet，根本没有经典的“连接”）。

保持所有连接并在必要时重新连接是通道的工作。它将部分责任委托给负载均衡器，并且负载均衡 API 确实具有连接（子通道）的概念。通过不向应用程序公开连接，负载均衡器有很大的操作自由度。

我会注意到基于 gRPC C-core 的实现跨通道共享连接。

当 RPC 抛出异常时，通道会发生什么？

通道和连接不受 RPC 失败的影响。请注意，连接级故障通常会导致 RPC 失败。但是重试之类的事情可能允许在新连接上重新发送 RPC。

当通道关闭时 gRPC 连接会发生什么？

连接最终关闭。通道关闭不是即时的，因为现有的 RPC 可以继续，并且连接关闭也不是即时的。但是一旦所有 RPC 完成，连接就会关闭。尽管 C-core 在没有通道使用它之前不会关闭连接。

通道什么时候关闭？

只有当用户关闭它时。

gRPC 连接何时关闭？

很多次。客户端可以在不再需要时关闭它。例如，假设服务器 IP 地址发生变化，客户端需要连接到 1.1.1.2 而不是 1.1.1.1。将创建一个新连接，并且新的 RPC 将转到新的 IP 地址。客户端也可以关闭它认为已死的连接（例如，通过保活超时）。

服务器对何时关闭连接有很多发言权。他们可能会仅仅因为它们太旧，或者因为它们一直处于空闲状态，或者因为服务器超载而关闭它们。但这些只是用例；服务器可以随意关闭连接。

如果超过期限怎么办？

截止日期仅适用于 RPC，不会影响通道或连接。

推荐阅读