Cloud Run服务间特定请求504超时及响应截断问题排查

核心现象 #

Cloud Run上部署的Quarkus Reactive服务A调用服务B时，仅特定revision（如463fc2ce-9140-47f7-8294-240a5640a49b）的/pages接口频繁触发：

• 服务A端返回504错误，提示“请求因达到最大超时时间而终止”
• 服务B日志出现Response body truncated警告
  另一同类revision接口无此问题，技术栈为Quarkus 2.16.12（Reactive）、Java 17、MongoDB，错误发生在服务B向A返回响应阶段。服务配置如下：

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对应的MongoDB pages数据量是否远大于正常revision，或是否包含需要额外计算/聚合的特殊数据（比如大文本、嵌套结构）。Quarkus Reactive若一次性加载全量数据到内存，会导致处理时间过长触发超时。
• 检查查询逻辑：确认该revision的查询是否存在无索引的全表扫描，或包含复杂聚合操作（如$lookup、$group），这类操作会大幅增加处理耗时。

2. 调整Cloud Run超时配置 #

当前配置未显式设置timeout_seconds，Cloud Run Gen2默认请求超时为30秒。若服务B处理异常请求耗时超过此阈值，会直接触发超时截断响应：

• 修改服务B的YAML配置，延长超时时间（最大支持900秒）：

  timeout_seconds: 120
  

• 同步调整服务A的REST客户端超时：在服务A的application.properties中配置对应客户端的超时时间，避免客户端先于Cloud Run触发超时：

  quarkus.rest-client."your.service.b.client.interface".connect-timeout=10s
  quarkus.rest-client."your.service.b.client.interface".read-timeout=120s
  

3. 优化服务B的响应处理逻辑 #

针对Quarkus Reactive特性，优化大响应场景的处理方式：

• 启用流式响应：避免一次性返回全量数据，改用Multi实现流式输出，减少内存占用与处理时间：

  @GET
  @Path("/revisions/{revisionId}/pages")
  public Multi<Page> getPages(@PathParam("revisionId") String revisionId) {
      return mongoCollection.find(eq("revisionId", revisionId)).toMulti();
  }
  

• 优化MongoDB查询：给revisionId字段添加索引，减少查询耗时；使用投影操作仅返回必要字段，降低数据传输量。

4. 排查资源瓶颈 #

当前配置为1核CPU、512M内存，若处理异常请求时资源耗尽，会导致处理延迟：

• 查看Cloud Run监控指标（CPU使用率、内存使用率、请求延迟），确认是否存在资源瓶颈。若有，临时调高资源配置：

  resource_requests:
    cpu: 1
    memory: 1024
  resource_limits:
    cpu: 1
    memory: 1024
  

5. 检查Quarkus Reactive配置细节 #

• 确认使用的是Reactive MongoDB客户端（依赖quarkus-mongodb-client），避免误用同步驱动阻塞事件循环。
• 调整Vert.x事件循环线程池大小，避免线程阻塞导致响应延迟：

  quarkus.vertx.event-loops.pool-size=8
  

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