如何在 Kubernetes 集群中使用 grpc-java 让 GRPC 的重试机制发挥作用？

Question

我一直在尝试让 GRPC 的负载平衡在部署到 Kubernetes 集群的 Java 应用程序中工作，但并没有取得太大成功。似乎没有太多关于此的文档，但从在线示例中我可以看到，我现在应该能够在设置 ManagedChannel 时使用 '.defaultLoadBalancingPolicy("round_robin")' （在更高版本的 GRPC Java lib 中） 。

更具体地说，我使用的是 GRPC Java 库的 1.34.1 版本。我创建了两个 Spring Boot (v2.3.4) 应用程序，一个名为 grpc-sender，另一个名为 grpc-receiver。

grpc-sender 充当 GRPC 客户端，并将 (Netty) ManagedChannel 定义为：

@Bean
public ManagedChannel greetingServiceManagedChannel() {
  String host = "grpc-receiver";
  int port = 6565;
  return NettyChannelBuilder.forAddress(host, port)
      .defaultLoadBalancingPolicy("round_robin")
      .usePlaintext().build();
}

然后grpc-receiver充当GRPC服务器：

Server server = ServerBuilder.forPort(6565)
        .addService(new GreetingServiceImpl()).build();

我正在将这些应用程序部署到 Kubernetes 集群（暂时在 minikube 本地运行），并且我为 grpc-receiver 应用程序创建了一个 Service 作为无头服务，这样就可以实现 GRPC 负载均衡。

为了测试失败的请求，我做了两件事：

• 在执行测试运行期间杀死 grpc-receiver pod 之一 - 例如，当我请求 grpc-sender 向 grpc-receiver 发送 5000 个请求时。Grpc-sender 确实检测到 pod 已被终止，并刷新其接收器 pod 列表，并将未来的请求路由到新的 pod。正如预期的那样，在 pod 终止期间正在进行的一些请求失败，并显示 GRPC 状态为 UNAVAILABLE。
• grpc-receiver 中有一些简单的逻辑，可以生成一个随机数，如果该随机数低于（例如 0.2），则返回 Grpc Status INTERNAL 而不是 OK。

通过上述两种方法，我可以在测试运行期间让一部分请求失败。现在我正在尝试让 GRPC 的重试机制发挥作用。通过阅读稀疏的文档，我正在执行以下操作：

return NettyChannelBuilder.forAddress(host, port)
        .defaultLoadBalancingPolicy("round_robin")
        .enableRetry()
        .maxRetryAttempts(10)
        .usePlaintext().build();

然而，这似乎没有效果，我根本看不到重试失败的请求。

我看到这仍然被标记为 @ExperimentalApi 功能，那么它是否应该按预期工作并且是否已实现？

如果是这样，我是否遗漏了一些明显的东西？我还需要做些什么才能重试工作吗？

有任何文档可以更详细地解释如何执行此操作吗？

首先十分感谢...

Answer 1

ManagedChannelBuilder.enableRetry().maxRetryAttempts(10) 不足以使重试发生。重试需要定义了 RetryPolicy 的服务配置。一种方法是使用 RetryPolicy 设置默认服务配置，请参阅https://github.com/grpc/grpc-java/tree/v1.35.0/examples中的重试示例

maxRetryAttempts() 的 javadoc 存在一些混乱，在https://github.com/grpc/grpc-java/pull/7803中得到了澄清