测验：发布策略

Bluegreen为什么将scaleDownDelaySeconds设置为300~600秒？

• 就等新版本出来了。
• 缓慢移动交通
• 转换后，我们希望将旧版本的 Pod 保留一段时间，以便立即回滚。
• 等待数据库迁移完成

为什么setWeight和analysis的顺序在金丝雀阶段定义中很重要？

• 因为分析优先，所以回滚速度更快。
• 这是因为setWeight是先执行的，流量流到金丝雀后才开始分析，收集实际流量指标。
• 顺序并不重要，只要声明即可。
• 这是因为 setWeight 接收分析结果作为参数。

金丝雀分析继续以“不确定”结束。最常见的原因和反应是什么？

• 门槛太宽松——提高门槛。
• 查询错误——删除分析
• 金丝雀流量太低，查询返回 NaN - 要么给它一个默认值，要么在分析之前暂停以收集样本。
• Pod 不足——减少副本

对于支付或身份验证等哪怕一个错误都会造成巨大损失的服务，哪种策略更合适？

• Canary — 因为您可以以 1% 的增量精确曝光
• 滚动更新——因为它节省资源
• 重新创建——因为这是最简单的
• 蓝绿 — 因为如果您发现问题，可以立即回滚所有流量。

Expand-Contract 的三个步骤中哪一个不能通过简单的代码滚动来撤消？

• 扩张
• 迁移
• 合同
• 这三个步骤都是安全的

如果架构更改被推送到一个版本中，为什么滚动/蓝绿分发会中断？

• 这是因为迁移本身会减慢，导致整个部署向后推并导致超时。
• 这是因为DB连接池不足。
• 总有一个部分是新旧代码同时运行的，因此，如果您先更改架构，旧版本的代码将会中断，如果您先更改代码，它将因引用不存在的架构而中断。
• 这是因为回滚速度慢但不存在功能问题。