NodeJS gRPC客户端遇UNAVAILABLE无重试问题咨询

首先明确回答：是的，Node.js官方的gRPC客户端（当前推荐使用@grpc/grpc-js包，旧版grpc包已停止维护）完全内置了重试功能，不需要你从零开始实现重试逻辑。针对你遇到的UNAVAILABLE连接状态和TCP Socket写入错误场景，内置重试可以很好地处理这类问题。

下面分两种常用方式来启用和配置重试策略：

1. 通过服务配置（Service Config）设置重试 #

这是最灵活的方式，支持针对不同服务方法配置不同的重试规则，也可以全局生效。你可以在创建客户端时直接传入该配置，或者通过环境变量全局设置。

代码示例：客户端构造时传入服务配置 #

const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

// 加载proto文件
const packageDefinition = protoLoader.loadSync('your_service.proto');
const serviceProto = grpc.loadPackageDefinition(packageDefinition).your_service;

// 定义重试策略的服务配置
const serviceConfig = {
  retryPolicy: {
    // 触发重试的gRPC状态码列表，UNAVAILABLE对应状态码14
    retryableStatusCodes: [grpc.status.UNAVAILABLE],
    // 最大重试次数（包含第一次请求）
    maxAttempts: 5,
    // 退避策略：指数退避，初始间隔100ms，最大间隔1s，每次间隔乘以2
    backoffMultiplier: 2,
    initialBackoff: '0.1s',
    maxBackoff: '1s'
  }
};

// 创建单例客户端，传入服务配置
const client = new serviceProto.YourService(
  'aws-lb-endpoint:port',
  grpc.credentials.createInsecure(),
  { serviceConfig }
);

全局配置：通过环境变量 #

如果你想让所有gRPC客户端都应用同一重试策略，可以设置环境变量：

export GRPC_DEFAULT_SERVICE_CONFIG='{"retryPolicy": {"retryableStatusCodes": [14], "maxAttempts": 5, "initialBackoff": "0.1s", "maxBackoff": "1s", "backoffMultiplier": 2}}'

2. 通过客户端构造参数设置基础重试 #

除了服务配置，也可以在创建客户端时直接设置retryPolicy选项（本质上是服务配置的简化版）：

const client = new serviceProto.YourService(
  'aws-lb-endpoint:port',
  grpc.credentials.createInsecure(),
  {
    retryPolicy: {
      retryableStatusCodes: [grpc.status.UNAVAILABLE],
      maxAttempts: 3,
      initialBackoff: '0.2s',
      maxBackoff: '1.5s',
      backoffMultiplier: 1.5
    }
  }
);

关键注意事项 #

• 确保使用@grpc/grpc-js：旧版grpc包（即grpc npm包）没有内置重试功能，务必迁移到@grpc/grpc-js（这是gRPC官方现在主推的Node.js实现）。
• 负载均衡配合：因为你是通过AWS Load Balancer连接后端，建议同时配置客户端的负载均衡策略为round_robin，这样客户端会自动在后端实例间分发请求，配合重试效果更好：

  const client = new serviceProto.YourService(
    'aws-lb-endpoint:port',
    grpc.credentials.createInsecure(),
    {
      serviceConfig: {
        loadBalancingConfig: [{ round_robin: {} }],
        retryPolicy: { /* 你的重试配置 */ }
      }
    }
  );
  

• 幂等性检查：重试会导致同一请求被多次发送，所以要确保你的gRPC服务方法是幂等的（比如GET类操作，或者有唯一请求ID去重的写操作），避免重复执行带来的业务问题。
• 连接状态管理：单例客户端的情况下，gRPC会自动管理连接池，当连接变为UNAVAILABLE时，内置重试会触发重新连接和请求重试，不需要你手动处理连接重建。

自定义重试的补充 #

如果内置重试策略无法满足你的特殊业务需求（比如复杂的重试条件、业务层面的重试逻辑），你也可以在应用层实现自己的重试封装，比如用async/await配合循环和延迟，但优先推荐使用内置重试，因为它是针对gRPC协议层面的错误做了优化的。

内容的提问来源于stack exchange，提问作者Martin Kunc