AWS EKS Fargate上NodeJS API因AWS SDK超时引发负载均衡超时问题排查

一、AWS SDK版本太老 #

你用的aws-sdk 2.719.0是2020年的版本，存在不少性能和稳定性问题，尤其是S3大文件上传、KMS操作的重试逻辑、网络连接管理这块。旧版本的S3自动分段上传逻辑可能有缺陷，KMS遇到临时限流或网络波动时重试机制也不完善，很容易导致操作耗时飙升。直接升级到aws-sdk-v2的最新稳定版，或者转用v3（模块化设计，性能更优），新版本修了好多超时和重试相关的bug。

二、S3上传优化不到位 #

哪怕是极少出现的350MB大文件，默认单线程上传肯定慢，而且旧版本SDK的自动分段上传可能没起作用或者并发数太低。

• 手动配置分段上传参数，比如设置每段10-30MB，并发数5-10（根据Fargate的CPU/内存调整），示例代码：

  const uploadParams = {
    Bucket: '你的存储桶名',
    Key: '文件键名',
    Body: 文件流,
    PartSize: 10 * 1024 * 1024, // 10MB每段
    QueueSize: 5 // 5个并发上传线程
  };
  const upload = s3.upload(uploadParams);
  upload.send((err, data) => { /* 处理结果 */ });
  

• 如果存储桶和Fargate不在同一区域，开S3传输加速能明显提升上传速度。

三、KMS操作耗时的可能原因 #

• 先确认KMS密钥和EKS Fargate在同一区域，跨区域调用KMS延迟会高很多。
• 旧版本KMS客户端的重试策略不合理，遇到限流时不会正确重试，导致请求挂起。手动配置重试参数试试：

  const kms = new AWS.KMS({
    maxRetries: 3,
    retryDelayOptions: { base: 1000 } // 重试间隔1秒
  });
  

• 检查KMS密钥的权限，确保Fargate的IAM角色能正常调用，有没有密钥轮换等操作导致临时性能波动。

四、负载均衡超时的根本解决：异步化操作 #

LB超时设的5分钟，但部分操作要7分钟，这肯定会超时。把耗时久的S3上传和KMS操作改成异步：

• 接收到请求后，立刻返回一个任务ID，然后把上传和KMS操作扔到异步队列里（比如用SQS+Lambda，或者Fargate上搭个NodeJS队列服务）。
• 客户端用任务ID轮询查询操作状态，这样就不会让LB一直等请求完成。

五、SDK失败日志缺失的问题 #

旧版本SDK在请求超时或进程崩溃时，可能没来得及输出日志就挂了，或者NodeJS进程被LB提前终止了。

• 把SDK日志输出到文件，同时捕获未处理的异常：

  const fs = require('fs');
  AWS.config.logger = fs.createWriteStream('./aws-sdk.log', { flags: 'a' });
  
  process.on('uncaughtException', (err) => {
    console.error('未捕获异常:', err);
    fs.appendFileSync('./error.log', `${new Date()}: 未捕获异常: ${err.stack}\n`);
  });
  
  process.on('unhandledRejection', (reason, promise) => {
    console.error('未处理的Promise拒绝:', promise, '原因:', reason);
    fs.appendFileSync('./error.log', `${new Date()}: 未处理Promise拒绝: ${reason.stack}\n`);
  });
  

• 检查Fargate的CloudWatch日志配置，确保容器的标准输出/错误能被正确收集，别让日志丢了。

六、Fargate资源不够 #

如果Fargate分配的CPU/内存太低（比如0.25vCPU/0.5GB），处理大文件上传时会因为资源瓶颈拖慢速度。根据并发数和文件大小调整配置，比如升到1vCPU/2GB以上试试。

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