Azure Container Apps新版本为何未继承旧版本副本数，引发负载瓶颈？

为什么新版本不继承旧版本的副本数？ #

Azure Container Apps（ACA）的每个版本（修订版）都是独立的部署单元，默认行为是以缩放规则中配置的最小副本数（minReplicas）启动新版本，而非继承旧版本当前运行的副本数，核心原因有三点：

• 版本隔离机制：ACA设计上默认假设新版本可能存在未知风险（比如代码Bug、依赖兼容性问题），如果直接继承旧版本的高副本数，一旦新版本有问题，会快速扩散影响所有流量，而从最小副本数启动能降低故障影响范围。
• 缩放规则的触发逻辑：自动缩放依赖于新版本的实时运行指标（如请求数、CPU使用率），新版本启动初期没有足够的指标数据积累，需要等待1-2分钟让监控系统采集到符合阈值的指标后，才会触发扩容动作。
• 配置优先级规则：你设置的HTTP缩放规则中minReplicas=1是新版本启动的默认初始值，该配置优先级高于旧版本的当前副本数，ACA不会将旧版本的运行状态作为新版本的启动依据。

如何避免部署新版本时的负载缺口？ #

可以通过以下几种方式解决：

• 部署时显式指定初始副本数
  使用Azure CLI部署新版本时，添加--replica-count参数指定初始副本数：

  az containerapp update --name <你的应用名> --resource-group <资源组名> --image <新版本镜像> --replica-count 10
  

  或者在Azure门户中，进入容器应用的"部署"页面，在"修订版设置"里手动设置初始副本数为10，再启动部署。
• 临时调整最小副本数
  在部署新版本前，先把缩放规则的minReplicas临时修改为10，部署完成后再改回1。这样新版本启动时直接以10个副本运行，后续自动缩放仍会按照规则调整。
• 采用蓝绿/金丝雀发布策略
  利用ACA的蓝绿部署功能：先部署新版本到独立的环境，手动扩容到10个副本并验证正常后，再将流量全部切换到新版本，完全避免部署初期的负载集中问题。

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