Google Cloud Run实例中PATCH API无法正常运行故障排查问询

场景说明 #

在Cloud Run服务上部署了实现gRPC的Go OSB应用，通过grpc-gateway对外暴露HTTP REST API，使用Cloud SQL（MySQL）作为数据库。所有CRUD API响应均正常，仅PATCH API出现异常，返回HTTP 503响应码。

报错日志 #

{
  "textPayload": "The request failed because either the HTTP response was malformed or connection to the instance had an error.",
  "insertId": "6141e984000c63529e7b7afd",
  "httpRequest": {
    "requestMethod": "PATCH",
    "requestUrl": "https://********-********-mr336-qv7hk7cx3a-uc.a.run.app/v2/service_instances/237e80fd-b22e-4df0-b9ed-23c91a4d7f51",
    "requestSize": "1102",
    "status": 503,
    "responseSize": "976",
    "userAgent": "PostmanRuntime/7.28.4",
    "remoteIp": "********",
    "serverIp": "********",
    "latency": "0.410343680s",
    "protocol": "HTTP/1.1"
  },
  "resource": {
    "type": "cloud_run_revision",
    "labels": {
      "location": "us-central1",
      "revision_name": "********-********-mr336-00001-hop",
      "project_id": "********-********-l-app-us-01",
      "configuration_name": "********-********-mr336",
      "service_name": "********-********-mr336"
    }
  },
  "timestamp": "2021-09-15T12:39:32.811858Z",
  "severity": "ERROR",
  "labels": {
    "instanceId": "00bf4bf02dff6d5f53cff1f1828cafbca265606a996eddff5cb44e3fff674efb77ca51eca7087fb8b8e7acba227b2a3e3e913bdfcc0a487640a2e028"
  },
  "logName": "projects/********/logs/run.googleapis.com%2Frequests",
  "trace": "projects/********/traces/e29e5add9452d171e9eebd26817bb667",
  "receiveTimestamp": "2021-09-15T12:39:32.817171397Z"
}

已知现象 #

• 每次发送PATCH请求后都能观测到实例启动日志，即上述报错日志出现后，每次都会生成容器入口点（服务端）的冷启动类启动日志
• 服务端启动完成后，日志中会再次抛出相同报错
• 关键现象为未采集到任何应用侧日志，说明PATCH API请求未抵达Cloud Run服务后端运行的容器实例
• 冷启动后的活跃实例闲置后会在最后一次请求结束后1分钟内缩容到0，该配置对其他API无影响，符合设计预期

排查方案 #

问题核心是请求未到应用层就被Cloud Run前端代理截断，按优先级排查以下点：

1. 检查grpc-gateway的PATCH方法路由配置
   确认proto定义中对应PATCH接口的google.api.http注解是否正确，是否存在路径冲突、方法匹配错误。grpc-gateway生成的路由规则对PATCH的请求体绑定规则和其他方法不同，错误的配置会导致网关侧直接返回异常，请求不会转发到后端gRPC服务。
2. 检查Cloud Run服务的HTTP/2配置
   如果Cloud Run服务配置为仅接收HTTP/2请求，而PATCH请求走的是HTTP/1.1（报错日志中protocol字段也明确为HTTP/1.1），会导致代理层握手失败直接返回503。确认Cloud Run服务的--use-http2参数配置，无特殊要求建议关闭强制HTTP/2，或者在请求侧适配HTTP/2协议。
3. 检查请求体大小限制
   报错日志中PATCH请求大小是1102字节，默认Cloud Run的请求大小限制远大于该值，但如果手动调整过服务的请求大小阈值刚好低于该值，也会被代理层直接拦截。
4. 检查gRPC服务的端口监听配置
   确认Go应用监听的是0.0.0.0而非127.0.0.1，且端口和Cloud Run配置的PORT环境变量一致。
5. 临时关闭缩容到0的配置测试
   先将Cloud Run的最小实例数设置为1，排除冷启动时序问题：如果冷启动过程中第一个请求超时被代理层截断，也会返回503。如果固定实例数后PATCH请求正常，说明是冷启动超时阈值设置过短，调整--timeout参数到合适值即可。

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