使用 gRPC 的 TCP 会话

Question

对不起，如果这个问题很幼稚。（gRPC 新手在这里）。但是，我想了解这一点。

假设我有一个像这样的 gRPC 服务定义：

service ABC {
  // Update one or more entities.
  rpc Write(WriteRequest) returns (WriteResponse) {
  }
  // Read one or more entities.
  rpc Read(ReadRequest) returns (stream ReadResponse) 
  {
  }
  // Represents the bidirectional stream 
  rpc StreamChannel(stream StreamMessageRequest)
      returns (stream StreamMessageResponse) {
  }
}

我们的潜在用例是使用 C++ 构建的服务器和使用 Java 构建的客户端。（不确定这是否重要）。

我想了解如何管理 TCP 会话。Stream Channel 将用于客户端和服务器之间的持续遥测数据流。（不断的数据传输，但从服务器到客户端的批量）。

StreamChannel 是否有单独的 TCP 会话，而对于每次写入和读取，都会在调用完成后建立和终止新会话？

或者是否有一个单独的 TCP 会话来进行所有通信？

再次，如果这很幼稚，请原谅。

谢谢你的时间。

Answer 1

由于 gRPC 使用 HTTP/2，因此它可以在同一个 TCP 连接上复用多个 RPC。gRPC 中的通道抽象让 gRPC 做出连接决策，而无需应用程序具有很强的感知能力。

默认情况下，gRPC 使用“pick first”负载平衡策略，它将使用到后端的单个连接。所有新的RPC 都将通过该连接。

连接可能会死（由于 I/O 故障）或需要关闭（各种原因），因此 gRPC 会自动处理重新连接。因为关闭连接可能需要很长时间（因为 gRPC 等待该连接上的 RPC 完成），所以 gRPC 仍有可能有 2 个或更多连接到同一后端。

因此，对于您的情况，所有 RPC 最初都存在于同一个连接上。随着时间的推移，新的 RPC 可能会使用更新的连接，而旧的、长期存在的 StreamChannel RPC 可能会使初始 TCP 连接保持活动状态。如果该长期存在的 StreamChannel 已关闭并由应用程序重新创建，则它可以再次共享较新的连接。