Cloud Run自定义扩缩容正式可用：CPU与并发目标可分别设定
2026年9月29日，Google Cloud宣布，Cloud Run服务自定义CPU或并发利用率目标的扩缩容控制已正式可用（GA）。这项变化把一部分容量策略交给应用团队：在默认自动扩缩容之外，可以根据自己的延迟要求、请求特征和成本约束调整目标。公告没有宣布Cloud Run降价，也没有承诺某个目标值适合所有服务。
配图为AI生成的概念插图，表现容量控制与请求分配，不是真实产品界面。
两个目标，对应不同的压力来源
官方配置文档列出，CPU和并发利用率的默认目标均为60%。CPU目标可设为10%至90%，并发目标可设为10%至95%。这里的并发目标是一种利用率目标，不能直接当成每个实例固定接收多少个请求。团队还需要结合服务本身的并发配置理解它。
这种区分对等待外部服务较多的应用很重要。例如，同一个实例内大量请求正在等待数据库返回，CPU不一定很忙，但请求占用的连接、内存和并发位置仍可能形成压力。相反，图片处理或计算型接口可能先碰到CPU瓶颈。调参之前，应先解释当前实例为什么扩展，而不是看到平均CPU低就直接提高利用率。
文档允许禁用CPU或并发这两类驱动中的一个，但不能同时禁用两者。禁用某一驱动后，该项指标不再参与相应扩缩容决策；如果只是希望恢复平台默认行为，应把目标恢复到默认值，而非把所有开关都关闭。
自定义目标并没有接管所有调节机制
一个容易遗漏的条件是Adaptive Concurrency Tuning（ACT）仍然有效。官方明确说明，即便修改了并发目标或禁用CPU扩缩容，ACT依旧运行。因此，配置成“仅按并发目标扩缩”之后，不能假定实例变化只会机械地跟着一个百分比走。
判断当前主导因素时，官方建议查看run.googleapis.com/scaling/recommended_instances指标，并按扩缩容驱动分别观察。建议实例数最高的驱动会主导实例数。这为排查提供了更直接的线索：目标配置、实际负载和平台保护机制应放在同一张时间线上，而不是只保留一张CPU平均值截图。
从运维角度看，最有价值的新增能力是让容量意图可表达、可复核。团队可以说明某条接口为什么需要更多空余容量，也可以解释一个稳定批处理接口为何采用较高目标，而不用把不同业务都塞进同一组默认参数。
提高利用率之前，先定义能接受的服务表现
降低目标通常意味着更早扩展、保留更大的容量余量，也可能带来更多实例和费用。提高目标可能减少闲置，但官方也提醒，更高目标会扩大容忍窗口，扩缩变化可能更集中。此次GA并不改变资源用量需要付费这一事实，不能仅凭实例数减少就宣布优化成功。
比较方案时，可保持代码、CPU配置、请求组合与观测时段尽量一致，同时记录高分位延迟、超时、错误率、实例数和实际费用。如果请求变慢导致客户端重试增加，表面减少的实例可能被额外工作抵消。对于调用数据库的服务，还应记录后端连接与等待情况，避免把下游压力误认成Cloud Run容量不足。
以上是评估建议，并非Google发布了统一验收标准。尤其是峰值持续时间不同的业务，应选择覆盖真实流量起落的窗口，不能只用短暂、平滑的压测曲线决定生产设置。
配置变更会创建新修订版
官方支持通过控制台、gcloud、YAML和Terraform设置目标；每次配置变化都会创建新修订版，后续修订版会继承设置，除非再次显式修改。这使目标值成为需要版本管理的部署配置，而不是一次临时调试动作。
较稳妥的采用方式，是先保存原有配置和回退路径，再给一个独立修订版分配少量流量，观察完整服务指标后逐步扩大。官方文档也建议渐进调整并使用流量拆分。调整完成后，部署记录应包含目标值、主导扩缩容驱动以及观察结果，让下一次代码发布的人知道服务为何这样运行。
这次更新给成熟服务增加了精细控制手段。它最适合解决已经有证据的容量问题；如果还说不清当前瓶颈，先补观测比先改百分比更有价值。
