Cloud Run上Java 11应用偶发503/504错误求助（附配置）

问题背景 #

我们在Google Cloud Run上运行基于Java 11、Jetty 10的应用，上月处理300万次POST请求时，约1000次出现异常失败：

• 多数为504网关超时，提示已达最大请求超时，但请求从未到达实例（无执行日志）
• 少数为503格式错误响应
• 所有失败请求均指向同一个instanceID，但该实例同时存在成功请求；失败请求未被实例处理，最终在其他实例执行成功

已完成的排查：排除内存/应用级超时/下游瓶颈/API配额，配置了readiness/liveness探针，CPU/内存使用率健康，资源客户端无泄漏。

Cloud Run配置：

CPU allocation: CPU is always allocated.
Startup CPU boost: Enabled
Concurrency: 80
Request timeout: 1800 seconds
Execution environment: Second generation
Autoscaling: Enabled 
Min instances: 12
Max instances: 100
CPU Limit: 4
Memory Limit: 8GB
Session Affinity: Enabled
HTTP2: Disabled

使用VPC连接器仅路由至私有IP，指标均在阈值内。

分析思路 #

1. 目标异常实例的全链路回溯 #

• 提取该实例从启动到终止的完整生命周期日志，重点关注失败请求时间窗口内：
  • 是否存在隐性网络异常（如VPC连接器DNS解析失败、连接池耗尽）
  • 系统级资源指标（磁盘I/O、TCP连接数、文件句柄数）是否超限（常规监控可能未覆盖这些）
• 检查该实例的请求队列状态：虽然整体请求率15次/秒，但瞬时请求突增可能触发Cloud Run的队列阻塞，导致部分请求无法转发到实例
• 对比探针检测时间与失败请求时间：若探针周期过长（如默认30秒），实例出现问题后，负载均衡可能仍会持续路由请求，直到探针检测到异常并终止实例

2. Cloud Run负载均衡与请求校验层面 #

• 针对503格式错误：查看Cloud Run的访问日志（而非应用日志），确认是否是负载均衡层直接拦截了格式不合法的请求（如HTTP头部不符合规范），这类请求不会转发到实例
• 针对504超时：验证请求超时的端到端一致性，检查VPC连接器的超时设置是否与Cloud Run的1800秒请求超时匹配，避免中间层超时截断请求
• 排查负载均衡的路由逻辑：是否该实例在异常时段被标记为“可路由”但实际无法接收请求？比如探针接口与业务接口依赖的资源不一致（探针用本地接口，业务依赖私有网络），导致探针误判实例健康

3. Jetty容器内部资源与配置排查 #

• 检查Jetty的线程池配置：确认acceptors、selectors、worker线程数是否能支撑并发80的请求量，若线程池耗尽，新请求会堆积在负载均衡层最终超时（而探针接口因轻量仍能正常响应）
• 排查Jetty的连接复用机制：是否存在HTTP连接泄漏（如客户端未正确关闭连接、keep-alive配置不合理），导致实例TCP连接数耗尽，无法接收新请求
• 检查应用的异步处理逻辑：若部分请求触发异步操作但未正确回调，会占用请求资源，导致后续请求无法被处理

4. 会话亲和性与实例调度关联排查 #

• 由于开启了Session Affinity，验证会话路由规则：是否存在特定请求的会话标识（如Cookie）导致被持续路由到异常实例，即使实例出现问题，负载均衡仍按亲和性规则转发请求
• 检查Autoscaling的实例调度策略：是否该异常实例被调度到了底层资源受限的节点？比如节点网络带宽不足、IO瓶颈，导致请求转发延迟或失败

5. VPC连接器隐性问题排查 #

• 确认VPC连接器的连接池大小：若应用频繁访问GCS、Redis等私有资源，连接池耗尽会导致实例无法发起下游请求，但探针不依赖私有网络，实例仍被标记为健康
• 检查VPC连接器的路由规则：是否部分请求的目标地址未被正确路由，导致请求在VPC层被丢弃，最终触发超时

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