Google Cloud Run托管API server健康检查及最佳实践咨询

你查到的「Cloud Run不支持定期健康检查、无法自动重启不健康实例」的信息是过时的错误结论。
早期Cloud Run确实仅在实例部署启动阶段做连通性校验，没有运行态的持续巡检能力，但当前版本已经原生支持完整的健康检查体系，所有异常实例的终止、替换、流量摘除动作全由托管侧自动完成，不需要用户自行开发巡检逻辑：

• 启动探针：实例部署/重启后，探针会持续探测配置的检查路径，直到返回成功状态前不会给该实例分配任何用户流量，连续探测超过阈值仍未启动成功的实例会被直接销毁重建
• 存活探针：即你关心的定期运行态巡检能力，会按照配置的固定时间间隔向实例发起探测请求，连续多次探测失败的实例会被判定为不健康，自动终止并替换为全新实例
• 就绪探针：实时检测实例是否具备正常处理请求的能力，探测失败时会自动把实例从负载均衡的转发列表里摘除，等实例恢复正常后再重新接入流量，避免异常实例返回错误响应

如果你的现有服务曾出现过不健康实例长期不被替换的情况，基本是因为部署配置中没有显式开启存活探针导致的，补上对应配置后自愈逻辑就会自动生效。

针对长时运行的API服务，按照以下规则配置即可覆盖绝大多数稳定性场景，不需要额外搭建第三方巡检或自愈组件：

• 按需精细化配置三类探针规则：不要直接使用默认配置，根据服务实际启动耗时设置启动探针的超时时间、重试间隔，避免启动慢的实例被误杀；存活探针关联轻量检查接口（比如/healthz），接口逻辑不要包含太重的业务逻辑，只校验进程本身是否正常即可，检查间隔设为10-30秒，连续2-3次失败再触发重启，减少误判；就绪探针可以关联核心下游依赖（比如数据库、缓存）的连通状态，依赖异常时自动摘流避免批量报错
• 合理设置实例参数：根据服务的实际资源占用配置CPU、内存规格，预留至少20%的资源冗余，避免突发流量下资源打满导致进程僵死；配置最小实例数保活时，不用额外做实例轮转逻辑——Cloud Run默认会对连续运行满24小时的实例做主动平滑替换，本身就可以规避长时运行带来的内存泄漏、资源碎片问题
• 用好原生可观测能力：开启服务的请求日志、指标采集，针对5xx错误率、请求延迟、实例重启次数配置告警规则，出现异常时可以第一时间感知；服务本身要做无状态设计，不要在实例本地存储会话、业务缓存类数据，所有持久化数据存在外部独立存储中，实例重启、替换时完全不会影响业务可用性
• 代码层做容错兜底：在业务代码里捕获全局未处理异常，避免单个请求的异常导致整个进程崩溃；如果服务存在已知的缓慢内存泄漏问题，可以在代码里加简单的内存占用阈值判断，超过阈值时主动让存活探针返回失败，触发托管侧平滑重启，比等进程OOM崩溃的影响要小很多
• 发布流程加灰度校验：新版本上线时先切1%_{5%的小流量观察10}15分钟，确认探针通过率、错误率、延迟指标都符合预期后再逐步推全量，避免版本缺陷导致全量服务故障

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