ECS Fargate部署断路器回滚行为与标准部署的差异问询

未启用断路器的标准部署行为（你的理解是正确的） #

• 服务正常运行在旧版本
• 触发新部署时，旧版本任务保持运行，同时启动新版本任务
• 新版本任务通过健康检查后，旧版本任务开始连接draining，流量逐步切换到新版本
• 若新版本启动失败或未通过健康检查，旧版本任务不受影响，流量继续流向旧版本，但部署会处于失败状态，ECS可能会持续尝试重新部署新版本（取决于部署配置的重试次数）

启用断路器并开启回滚后的行为 #

当部署断路器和回滚功能启用后，核心差异在于部署失败后的处理逻辑：

1. 停止重试并触发主动回滚：当新版本部署失败（达到重试次数上限），ECS会停止继续尝试部署新版本，而是自动发起一个新的部署任务，将服务的期望状态恢复到最后一次成功部署的版本。
2. 清理失败部署的残留资源：回滚过程会清理掉失败部署中启动的异常任务（比如无法通过健康检查的新版本任务），确保所有运行中的任务都回到旧版本。
3. 重置部署状态：回滚完成后，服务的部署状态会重置为“成功”，而不是停留在“失败”状态，让部署历史更清晰，也避免了后续不必要的自动重试。
4. 明确的期望状态同步：虽然旧版本任务在标准模式下也能正常运行，但回滚会主动将服务的期望版本设置回旧版本，确保服务的配置（如任务定义ARN）与实际运行的任务完全匹配，避免出现“期望版本是失败的新版本，但实际运行旧版本”的不一致情况——这种不一致可能会给后续的部署、监控或自动化操作带来混淆。

为什么需要主动回滚（而不是保留旧版本原样） #

你提到的“旧版本本就未受影响”是事实，但主动回滚解决了标准模式下的几个隐性问题：

• 终止无效重试：标准模式下，ECS可能会持续重试部署失败的新版本，浪费资源且增加系统噪音。回滚后，服务的期望版本回到旧版本，不会再触发无效的重试。
• 消除状态不一致：标准模式下，服务的“期望版本”仍然是失败的新版本，但实际运行的是旧版本，这种状态不匹配可能导致监控告警、自动化脚本（如CI/CD流程）误判服务状态。
• 清理残留资源：部分失败的新版本任务可能处于“pending”或“running但不健康”的状态，回滚会主动终止这些任务，释放资源。

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