我阅读了 gRPC 的核心概念、架构和生命周期,但它没有深入探讨我想看到的内容。其中包括RPC 调用、gRPC 通道、gRPC 连接(文章中未描述)以及 HTTP/2 连接(文章中未描述)。
我想知道这些内容是如何结合在一起的。例如,当 RPC 抛出异常时,通道会发生什么?当通道关闭时,gRPC 连接会发生什么?通道何时关闭?gRPC 连接何时关闭?心跳?如果超过截止时间怎么办?
有人可以回答这些问题,或者指导我可以查看哪些资源吗?
我阅读了 gRPC 的核心概念、架构和生命周期,但它没有深入探讨我想看到的内容。其中包括RPC 调用、gRPC 通道、gRPC 连接(文章中未描述)以及 HTTP/2 连接(文章中未描述)。
我想知道这些内容是如何结合在一起的。例如,当 RPC 抛出异常时,通道会发生什么?当通道关闭时,gRPC 连接会发生什么?通道何时关闭?gRPC 连接何时关闭?心跳?如果超过截止时间怎么办?
有人可以回答这些问题,或者指导我可以查看哪些资源吗?
当一个RPC抛出异常时,通道会发生什么?
通道和连接不会受到失败的RPC的影响。请注意,连接级别的故障通常会导致RPC失败。但是,例如重试可以允许在新连接上重新发送RPC。
当通道关闭时,gRPC连接会发生什么?
连接最终会被关闭。通道关闭并非瞬间完成,因为现有的RPC可能会继续执行,并且连接关闭也不是瞬间完成。但是,一旦所有RPC完成,连接就会关闭。尽管C-core不会关闭连接,直到没有通道再使用它为止。
什么时候会关闭通道?
仅当用户关闭它时。
什么时候会关闭gRPC连接?
很多时候。客户端可能在不再需要时关闭连接。例如,假设服务器IP地址发生更改,客户端需要连接到1.1.1.2而不是1.1.1.1。将创建一个新的连接,并且新的RPC将转到新的IP地址。客户端还可以关闭其认为已经死亡的连接(例如,通过keepalive超时)。
服务器有很多决定何时关闭连接的方式。他们可能会简单地关闭它们,因为它们过时了,或者因为它们已经闲置,或者因为服务器过载了。但这些只是使用案例;服务器可以随时关闭连接。
如果超过了截止日期会怎样?
截止日期仅适用于RPC,不影响通道或连接。
基础连接随时可能因任何原因而关闭。例如:远程服务器定期进行计划维护,或连接长时间处于空闲状态。在这种情况下,服务器可以向客户端发送GOAWAY信号,客户端可能会断开并重新连接到其他服务器,或者服务器可能因OOM错误而崩溃。在这种情况下,通道将检测到连接失败,并为其他服务器重试新的连接等。
通道可以持续向服务器发送PING帧以保持连接活动状态。所有这些都可以通过通道构建器进行配置。
根据上述信息,如果我们看一下你的问题:
当RPC引发异常时,通道会发生什么? 通道不会发生任何变化。服务器上未处理的异常可能会使客户端的RPC失败。但通道仍可用于任何RPC调用。
当通道关闭时,gRPC连接会发生什么? 通道是连接的抽象层,因此它将关闭。(再次说明,没有所谓的gRPC连接,正如Eric所提到的那样。它将是一个HTTP2连接)
何时关闭通道? 您可以随时关闭,但通常在应用程序关闭时关闭。
gRPC连接何时关闭? 这不是我们的问题。通道会处理这个问题。
心跳? 通道会定期发送PING帧以保持连接活动状态。
如果超过截止日期怎么办? 这类似于客户端的超时。当截止日期超过时,客户端可能会取消请求。再次强调,通道没有任何变化。(但这可能会在服务器端触发异常,我曾经注意到几次。 收到未知流的数据帧。https://github.com/grpc/grpc-java/issues/3548)。现在看来已经解决了。
Channel
的连接状态可以是ready,即使subchannel状态仍然是idle。Channel
状态和subchannel状态之间有什么关系?或者说,即使唯一的subchannel仍处于空闲状态,Channel
状态如何能够准备就绪? - CMCDragonkai