我对canary版本的理解是，它是部分打开了粘性 session 的生产节点的部分版本。这样，如果您最终发布了一个严重的错误，则可以控制并最大程度地减少受到影响的用户/客户的数量。
我对蓝/绿发行版的理解是，您拥有两个镜像的生产环境(“蓝”和“绿”)，您一次将更改推送到蓝或绿的所有节点，然后使用网络魔术来控制通过DNS路由到哪些环境用户。
因此，在我开始之前，如果到目前为止我所说的话是不正确的，请先纠正我!
假设我大致上步入正轨，那么关于这两种策略的几个问题:
最佳答案
蓝绿色释放更简单，更快。
如果您已经在测试环境中测试了新版本并且可以确定新版本将在生产环境中正常运行，则可以进行蓝绿色发行。始终使用feature toggles是增加您对新版本的信心的好方法，因为新版本的功能与旧版本完全相同，直到有人按下功能开关为止。将您的应用程序划分为可独立发布的小型服务是另一种方法，因为要测试的内容更少，破坏的可能性也更少。
如果您不能完全确定新版本是否可以在生产环境中正常运行，则需要进行Canary发布。即使您是一位全面的测试人员，Internet仍然是一个庞大而复杂的地方，并且总是会带来意想不到的挑战。即使使用功能切换，也可能无法正确实现。
部署自动化很费力，因此大多数组织都会计划每次都使用一种策略。
如果您致力于使自己充满信心的做法，那么蓝绿色部署也是如此。否则，发出金丝雀。
蓝绿色的本质是一次全部部署，而金丝雀部署的本质是增量部署，因此对于单个用户池，我无法想到我会描述为同时进行的一个过程。如果您有多个独立的用户池，例如使用不同的区域数据中心，您可以在每个数据中心内使用蓝绿色，并在各个数据中心内使用金丝雀。尽管如果您不需要在数据中心内进行金丝雀部署，那么您可能在整个数据中心中都不需要它。