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

【问题标题】：How to get GRPC's retry mechanism to work using grpc-java in Kubernetes cluster?如何让 GRPC 的重试机制在 Kubernetes 集群中使用 grpc-java 工作？
【发布时间】：2021-04-18 09:59:32
【问题描述】：

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

更具体地说，我使用的是 1.34.1 版的 GRPC Java 库。我创建了两个 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 功能，那么它是否应该按预期工作并且已经实现了？

如果是这样，我有什么明显的遗漏吗？我还需要做什么才能使重试工作正常吗？

是否有任何文档更详细地解释了如何执行此操作？

提前非常感谢...

【问题讨论】：

标签： java kubernetes grpc grpc-java

【解决方案1】：

非常感谢@user675693！效果很好:)

maxRetryAttempts() 的工作确实有点混乱。

从文档中我可以看到：

“必须指定 maxAttempts 并且必须是大于 1 的 JSON 整数值。大于 5 的值被视为 5，而不被视为验证错误。”

参考服务配置中的 maxAttempts。如果我们想要超过 5 次尝试，我可以将其设置为 maxRetryAttempts(10)，例如在我的 ManagedChannel 设置中：

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

但要正确使用该设置，我需要在服务配置和 ManagedChannel 设置代码中将其设置为 10，否则只执行 5 次重试。从 Javadoc 或文档中并不清楚，但这似乎是我的测试所发生的。

此外，此重试功能被标记为@ExperimentalApi。它有多成熟，是否适合在生产中使用？是否会发生巨大变化？

【讨论】：

【解决方案2】：

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 对此进行了澄清

【讨论】：