Google Cloud在2026年9月29日宣布，Cloud Run自定义扩缩容控制正式商用。服务不再只能接受平台默认的CPU与并发利用率目标，运维人员可以分别设置两类阈值，也可以停用其中一个信号，让实例数量更贴合工作负载特点。
Cloud Run默认以60%的CPU利用率和60%的并发利用率作为扩缩容目标。新能力让团队能够在响应速度、实例数量与成本之间做更精细的取舍，但阈值越低并不代表配置越好，过早扩容会直接增加空闲容量和费用。
CPU与并发目标可以独立调整
CPU目标可配置范围为10%至90%，并发目标可配置范围为10%至95%。较低目标会让Cloud Run更早增加实例，给突发流量保留更大余量；较高目标则让单个实例承担更多负载，可能减少实例数量。
这两项信号适合的工作负载并不相同。CPU密集型推理、压缩或计算服务更关注处理器利用率，等待外部接口或数据库的I/O服务则可能更容易先触及并发上限。
可以停用一个信号但不能全部关闭
服务可以只按CPU扩缩容，也可以只按并发扩缩容，但至少要保留一个有效驱动。全部关闭并不会形成可用配置；希望恢复平台行为时，应把目标重置为默认值，而不是尝试同时停用两项。
关闭某项信号前要确认另一项能够准确反映服务压力。只看CPU可能忽略大量等待中的请求，只看并发也可能让少量高计算请求把实例压满。
每次配置变化都会生成新的修订版本
自定义目标可通过控制台、gcloud CLI、YAML或Terraform配置。任何调整都会创建新的Cloud Run修订版本，后续修订默认继承这些设置，除非部署时明确修改或重置。
这意味着扩缩容参数应与应用版本一样纳入变更管理。上线前记录旧值，并使用流量拆分让少量请求进入新修订，能够在延迟或错误率恶化时快速回退。
ACT保护机制仍可能影响并发
即便自定义并发目标或停用CPU扩缩容，Adaptive Concurrency Tuning仍保持工作。当单个实例的一秒CPU利用率超过90%时，ACT可能动态降低可接受的并发量，保护服务不被持续过载。
因此，实例数量变化不一定完全由手动设置的两个目标触发。可以查看recommended_instances指标并按扩缩容驱动拆分，确认究竟是CPU、并发还是ACT在决定实例规模。
阈值应通过真实流量逐步校准
官方建议小幅调整目标，并等待数分钟观察性能变化。把阈值降到10%能够更早扩容并提高突发流量缓冲，但也会运行更多实例、增加扩缩容决策频率，并可能明显提高账单。
生产环境应同时观察高分位延迟、冷启动、错误率、实例数与成本。先用独立修订承接少量真实流量，再扩大配置范围，比一次性修改整个服务更容易判断收益与副作用。
