蓝绿与金丝雀，各自拿什么去换
一句话总结
蓝绿色和金丝雀不是好坏的问题，而是在回滚速度、流量控制精度、资源成本之间选择什么的问题。
##为什么需要这个
如果一次性更换发布，出现问题时，恢复的时间很快就会变成故障时间。因此，发布策略都是调整“将如何一点一点地暴露在新版本中”和“如果出现问题时，将如何尽快恢复”的装置。
BlueGreen会保持两个规模相同的环境，一次性切换流量。切换前，通过prePromotionAnalysis进行烟雾测试，确认绿是正常的，切换后，将scaleDownDelaySeconds设置为300~600秒，暂时保留旧版本。这个时间一过，旧版本Pod就会结束，所以回滚时需要重新创建Pod，所以需要更长时间。也就是说，这个延迟就是立即回滚的有效期。
金丝雀将比例提高到5%→分析→20%→50%→100%等，作为每个阶段的指标进行判断。这里顺序是决定性的。setWeight必须先执行，然后在金丝雀流经流量后才开始分析，才能收集实际流量为基础的指标。如果将顺序颠倒，就会在没有任何数据的情况下进行判断。
怎么操作
自动中断临界值在实际使用中是这样的。成功率0.99以上（interval 30s, count 10, failureLimit 2），p95延迟300ms以下，错误日志率0.005以下。如果组织标准SLO是成功率99%，P95300ms以下，那么金丝雀临界值也应该根据 đó调整，才能前后一致。
最常见的陷阱是Inconclusive。如果金丝雀流量太少，查询返回NaN，判断就会一直留在未决状态。对应有两种。default(result[0], 1)像这样给出基本值，或者在analysis前面加上pause来收集样本。样本为0的话，无法判断的事实本身是管道需要知道的。所以制作好的分析脚本在请求数为0时，不是通过而是失败。
选择标准以表格整理。流量控制精度是金丝雀高（以1%为单位），没有蓝绿。滚动速度是蓝绿非常快。资源成本是蓝绿是Pod的两倍。数据模式变更是蓝绿相对简单。一般规则如下。大多数服务是金丝雀，像结算或认证这样一次错误也会造成很大的成本的服务是蓝绿。如果使用滚动更新，标准值是maxSurge 1，maxUnavailable 0。
在现场相遇的样子
无论怎么好的策略，如果遇到DB迁移，就会崩溃。因为无论是滚动还是蓝绿，新旧代码同时存在的时间段在几十秒到数分钟之间肯定存在。先更改模式表就会崩溃旧版本代码，先更改代码就会崩溃引用还没有新代码的模式表。无论先做哪一方都会崩溃一方。
解决办法是Expand-Contract 3阶段。在Expand中让旧结构和新结构共存，在Migrate中做备份和双重亮点，在Contract中删除旧结构。核心是滚动回溯的不对称性。Expand滚动回溯可以忽略，Migrate滚动回溯也很安全，但Contract滚动回溯已经删除了旧列，所以不能用简单的代码滚动回溯恢复。所以留下了谚语。Expand自由，Contract谨慎。最常见的错误是把Expand和Contract同时放在一个版本中。
##无法逆转的事情
从可以撤销发布战略的价值来看。但是有些东西会影响流量。
即使退回去也不会一起回来。在选择策略之前，必须先确认一下这个列表。
**已经发送过。**邮件、通知、结算批准、发送给外部系统的请求。新版本是
如果发错了，则只会停止发送更多回滚，而已经发送的将收到取消通知。
只能再寄一封。所以**有向外出副作用的变更是
开始金丝雀比例特别小**，可以将无法逆转的点推迟到分布后。
先看看有没有。
**已删除的数据。**前面看到的Expand-Contract的Contract就是这个。列
删除后，即使只恢复代码，该列也不会恢复。
**以格式变更的状态堆积起来的。**新版本以新的格式写入了CASHINA Queue。
如果回滚的话，旧版本读取它时会失败。**缓存格式变更时，钥匙也会一起变更。
改变**是彻底解决这个问题的方法，如果是Q的话，旧版本会变成新格式。
应该能够跳过。
**只往一个方向移动的以前。**在将数据转移到新的存储器时，不再保留原件。
如果让它不使用的话，从那个瞬间开始，回滚就意味着会失去中间积累的东西。
所以制定分发计划时，把两个写在一起。回溯的程序和
无法回头的地方是什么时候。如果不把后面的事情写下来，障碍
在中间第一次判断“现在可以回去吗”。那一刻，没有人
不冷静。
##下次实习要做的事情
这个板没有Argo Rollouts也没有Load Balancer。所以把两个容器漂浮在8091（blue）、8092（green）上，把活跃对象用一个文件表示，用Shell实现转换、健康检查、自动回滚。用类似的方式熟练掌握了金丝雀比例分配和自动中断判断。看到决定将流量发送到哪里只需要一行文件的事实后，实际控制器所做的事情变得更加清晰了。