Cloud Run服务A不同Revision调用服务B偶发504超时问题排查

背景概述 #

我有两个同名的Google Cloud Run服务'A'，均通过REST调用服务'B'从MongoDB获取数据。现象如下：

• 请求https://A/revisions/463fc2ce-9140-47f7-8294-240a5640a49b/pages偶尔返回504错误，提示"请求已终止，因为已达到最大请求超时"
• 另一Revision（如https://A/revisions/543fc2ce-9140-47f7-8294-240a5640a49b/pages）的相同请求无异常，且第一个Revision返回的信息更少
• 服务'B'日志出现警告：Truncated response body（通常意味着请求超时或应用在响应完成前退出）
• 两个服务的CPU、内存均无异常，且CPU始终处于活跃状态
• 服务YAML配置如下：

resource_requests:
  cpu: 1
  memory: 512
resource_limits:
  cpu: 1
  memory: 512
min_scale: 1
max_scale: 100
cloud_run_gen: gen2
ports:
  name: http1
  port: 8080
startup_cpu_boost: true
cpu_always_allocated: true

可能的原因分析 #

1. 两个Revision的业务代码存在差异 #

虽然服务配置完全一致，但不同版本的代码逻辑可能存在隐性区别：

• 第一个Revision的服务'A'在调用服务'B'时，传递的查询参数可能触发了服务'B'中更耗时的MongoDB查询（比如返回数据量少但需要复杂聚合、或未命中索引的查询）
• 代码中存在未正确处理的异步逻辑、不必要的重试机制，或响应处理阻塞，导致请求整体耗时超出Cloud Run的超时阈值
• 可能存在代码bug，比如循环调用服务'B'多次，累积了请求耗时

2. HTTP客户端/连接配置不一致 #

两个版本的服务'A'可能使用了不同的HTTP客户端配置：

• 第一个版本未启用连接复用，每次调用服务'B'都新建TCP连接，握手耗时累积导致请求超时
• 客户端的read_timeout或connect_timeout设置不合理，比如读取超时设得过长，导致Cloud Run的全局超时先触发；或过短导致提前截断响应
• 连接池大小不足，高并发下请求排队等待连接，最终超时

3. 服务'B'的超时配置不匹配 #

• 服务'B'自身的请求超时设置短于服务'A'的Cloud Run超时，导致服务'B'提前终止响应并返回截断的内容，而服务'A'仍在等待完整响应，最终触发504
• 服务'B'处理第一个Revision的请求时，存在未捕获的异常，导致进程提前退出，从而截断响应

4. MongoDB查询性能差异 #

即使返回的数据量更少，对应的MongoDB查询可能效率极低：

• 查询条件未命中索引，触发全集合扫描，耗时远超预期
• 使用了skip进行分页且skip值过大，MongoDB需要遍历大量前置数据才能返回少量结果，导致查询超时
• 集合存在锁竞争、分片集群的路由延迟等问题，恰好影响第一个Revision对应的查询

5. Cloud Run服务超时配置差异 #

虽然YAML配置未体现，但两个Revision的服务超时时间可能被单独修改：

• 第一个Revision的Cloud Run超时设置得更短（比如默认5分钟被改成1分钟），而请求实际耗时超过了该阈值
• 可以通过Cloud Console或gcloud run services describe命令检查两个Revision的超时参数

6. 实例内部资源隐性阻塞 #

虽然CPU和内存指标正常，但可能存在其他资源瓶颈：

• 文件描述符耗尽，导致无法新建网络连接到服务'B'
• 服务'A'的实例存在线程池耗尽问题，请求处理线程被占用，无法及时处理响应

排查建议 #

• 对比两个Revision的代码差异，重点检查服务'B'的调用逻辑、参数传递及响应处理部分
• 在服务'A'和'B'中添加详细的请求耗时日志，定位超时发生的具体阶段（是调用B前、调用B过程中还是响应处理时）
• 检查服务'B'中对应查询的MongoDB执行计划，确认是否存在索引缺失或低效查询
• 验证两个Revision的Cloud Run超时配置是否一致
• 检查服务'A'的HTTP客户端配置，确保连接复用、超时设置合理

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