gRPC DEADLINE_EXCEEDED异常求助：服务存活却请求超时

我之前在AWS ECS上部署Node.js gRPC微服务时，碰到过几乎一模一样的Deadline Exceeded问题，折腾了好一阵才梳理出几个核心排查方向，给你参考：

1. 优先排查ELB TCP空闲超时与gRPC Keepalive不匹配 #

传统ELB（非ALB）的TCP监听器默认空闲超时是60秒，而Node.js gRPC客户端默认不会主动发送心跳维持长连接。当ELB因为空闲超时悄悄断开底层TCP连接后，gRPC客户端可能还在复用这个失效的连接——这就是为什么telnet能通（它会新建连接），但gRPC请求会超时（依赖连接池里的旧连接）。

解决方法：

• 调整ELB的TCP空闲超时（建议设为120秒以上），确保时长比gRPC客户端的心跳间隔更长；
• 在gRPC客户端显式配置keepalive参数，强制定期发送心跳维持连接：

  const grpc = require('grpc');
  const yourServiceProto = grpc.load('your-service.proto').yourpackage;
  
  const client = new yourServiceProto.YourService('your-elb-endpoint:50051', 
    grpc.credentials.createInsecure(),
    {
      'grpc.keepalive_time_ms': 30000, // 每30秒发送一次心跳
      'grpc.keepalive_timeout_ms': 5000, // 心跳超时时间
      'grpc.keepalive_permit_without_calls': 1, // 即使没有业务请求也发心跳
      'grpc.http2.max_pings_without_data': 0, // 禁用无数据的ping限制
      'grpc.http2.min_time_between_pings_ms': 10000, // 最小ping间隔
    }
  );
  

2. 开启gRPC连接重试机制 #

Node.js gRPC客户端默认不会自动重试失效的连接，搭配上面的keepalive配置后，再开启重试可以进一步避免失效连接导致的超时：

const client = new yourServiceProto.YourService('your-elb-endpoint:50051', 
  grpc.credentials.createInsecure(),
  {
    // ... 保留上面的keepalive参数
    'grpc.enable_retries': 1,
    'grpc.max_retry_attempts': 2,
    'grpc.retry_buffer_size': 1024 * 1024, // 重试缓冲区大小
  }
);

3. 检查ECS任务的网络模式与连接数限制 #

如果你的ECS任务用的是awsvpc网络模式，偶尔会出现ENI端口耗尽或者TCP连接数过高的情况（虽然telnet能通，但连接池里的旧连接可能已失效）。可以通过CloudWatch监控ECS任务的TCPConnections指标，或者在容器内执行netstat -an | grep ESTABLISHED查看连接数是否异常。如果连接数过高，可调整gRPC客户端的连接池大小：

const client = new yourServiceProto.YourService('your-elb-endpoint:50051', 
  grpc.credentials.createInsecure(),
  {
    'grpc.max_concurrent_streams': 100, // 根据业务调整最大并发流
    'grpc.max_receive_message_length': 1024 * 1024 * 10, // 调整消息大小限制
  }
);

4. 排查Node.js事件循环阻塞 #

有时候A服务的Node.js事件循环被阻塞（比如同步IO、大计算量操作、内存泄漏导致GC频繁），会导致gRPC请求无法及时被处理，最终触发超时。可以用以下方法排查：

• 使用clinic bubbleprof工具分析事件循环阻塞点；
• 启动Node.js时添加--trace-event-categories v8,node.async_hooks,node.scheduler参数，生成trace文件后用Chrome DevTools分析。

5. 验证ELB健康检查配置 #

虽然telnet能通，但要确认ELB对B服务的健康检查是否正常。如果B服务的健康检查偶尔失败，ELB会将实例从目标组移除，但gRPC客户端的连接池可能还持有指向这些实例的连接。建议确保ELB的TCP健康检查间隔和阈值设置合理（比如间隔10秒，2次失败就移除、2次成功就恢复），同时确保B服务的监听端口始终正常响应。

我当时就是通过调整ELB超时和gRPC keepalive参数解决了问题，你可以先从这个方向入手试试。

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