金丝雀释放策略与蓝色/绿色

我对于金丝雀版本的理解是，它是打开了粘性会话的生产节点子集的部分版本。这样，如果您最终发布了一个错误，您就可以控制和最小化受到影响的用户/客户的数量。

我对蓝/绿版本的理解是，你有两个镜像生产环境(“蓝”和“绿”) ，你一次推送变更到所有的节点，无论是蓝色还是绿色，然后使用网络魔法来控制哪个环境用户通过 DNS 路由。

所以，在我开始之前，如果我到目前为止所说的任何东西是不正确的，请开始纠正我！

假设我或多或少地进入了正轨，那么关于这两种策略的几个问题是:

  • 是否有这样的情况: 金丝雀比蓝色/绿色更受欢迎，反之亦然？
  • 是否存在部署模型可以同时实现这两种策略的场景？
66008 次浏览
小开

蓝绿色释放更加简单快速。

如果您已经在测试环境中测试了新版本，并且非常确定新版本将在生产环境中正常工作，那么您可以执行蓝绿色版本。始终使用 功能开关是增加您对新版本的信心的一个好方法，因为新版本的功能与旧版本完全一样，直到有人翻转一个功能开关。将应用程序分解为小型的、独立可发布的服务是另一种方法，因为要测试的内容较少，可能中断的内容也较少。

如果您不能完全确定新版本在生产中能够正常工作，那么 需要会发布一个金丝雀版本。即使你是一个彻底的测试者，互联网是一个庞大而复杂的地方，总是会带来意想不到的挑战。即使使用特性开关，也可能有一个实现不正确。

部署自动化需要付出努力，因此大多数组织每次都计划使用一种或另一种策略。

因此，如果您致力于使您有信心这样做的实践，那么可以进行蓝绿部署。否则，就派出金丝雀。

蓝绿部署的本质是一次性部署，而金丝雀部署的本质是增量部署，因此，在只有一个用户池的情况下，我想不出一个我可以描述为同时进行两个部署的过程。如果您有多个独立的用户池，例如使用不同的区域数据中心，那么您可以在每个数据中心内执行蓝绿色操作，并在数据中心之间执行金丝雀操作。尽管如果您不需要在数据中心内部部署金丝雀，那么您可能不需要跨越数据中心。

小开

我在这里写了一篇关于这个主题的详细论文: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

在我看来，区别在于新的“绿色”版本是否向真正的用户公开。如果是的话，我会叫它金丝雀。实现 Canary 的一种常见方法是常规的 Blue/Green，并在新版本中添加特定用户的智能路由。详细的比较请阅读这篇文章

蓝色/绿色: enter image description here

金丝雀: enter image description here

小开

尽管这两个术语看起来非常接近，但它们之间有着细微的差别。一种是对功能发布充满信心，另一种是对发布的方式充满信心。

金丝雀

  1. 金丝雀版本是一种技术，它通过在生产中引入新的软件版本之前，缓慢地向一小部分用户推出更改，从而降低这种风险 整个基础设施

  2. 它将了解新版本将如何执行(与其他应用程序、 CPU、内存、磁盘使用量等集成)。

蓝色/绿色:

  1. 它更多的是关于零停机时间部署的可预测发布。
  2. 在失败的情况下容易回滚。
  3. 完全自动化的部署过程
小开

一个很好的定义开始。 我认为，如果您将“发布”定义分解为“部署”和“发布(功能)”，这也有助于为您的战略做出决策。

部署(二进制文件)

将产品部署到(生产)系统的二进制操作。

发布(功能)

管理功能对(组)用户的可用性的操作。

为什么? 在“释放”时，你通常会有(多重)两个顾虑: 1) bug/向后兼容性/等 2)验证新功能的有效性/可用性

然后，在选择金丝雀、蓝色/绿色或任何灰色/混合模式策略之前，问问自己: 在发布/部署新版本时，我们有什么顾虑？只有这样，你才能知道自己的顾虑，选择自己的策略。

此外，还可以执行更复杂的部署/发布策略。 例如，在一些云/基础设施中，有可能有多个生产服务器，并以不同的比例将负载转发给不同的服务器和产品版本，并在将发布/部署扩展到所有用户之前监视健全性。

特征标记

“配置”(冷的，甚至是热的)哪些功能(不)对哪些(组)用户可用的操作

如果你也做一些类似“功能标记”的事情，你可以先部署，从向后兼容性/bug 的角度衡量你的版本的可靠性，然后逐渐向不同的用户发布新功能，反之亦然(缩小甚至回滚功能和/或二进制文件)。 特性标记允许将功能的可用性从二进制文件的部署中分离出来，并提供比“部署/回滚”更细粒度的决策

小开

这里有一些内联的定义-

  • Blue-Green Deployment -当部署新版本的 应用程序时，将创建第二个环境 环境是测试，它接管了旧版本。旧的 环境，然后可以关闭。

  • A/B 测试 -同时运行两个版本的应用程序。请求的一部分分配给每个。然后开发人员可以比较版本。
  • Canary Release -微服务的新版本和旧版本一起启动。然后，新版本可以接收部分请求，团队可以测试新版本如何与整个系统交互。
小开

2022年5月更新:

蓝色-绿色部署(蓝色-绿色版本)和 金丝雀部署(放飞)的区别是:

  • 蓝绿部署很快
  • 金丝雀部署是循序渐进的

蓝色-绿色部署:

有 两个环境，蓝色环境是“旧的”，并包含一个或多个应用程序(实例或容器)和 “新”的绿色环境，包含一个或多个应用程序(实例或容器)。

然后，100% 的流量迅速从 蓝色环境切换到 绿化环境，如下所示，你可以说 蓝绿部署是金丝雀部署的快捷方式:

enter image description here 上面这张图片来自 https://www.encora.com/insights/zero-downtime-deployment-techniques-blue-green-deployments，最初是由公司 < strong > “ Encora”创建的

金丝雀部署:

有 两个环境，蓝色环境是“旧的”，并包含一个或多个应用程序(实例或容器)和 “新”的绿色环境，包含一个或多个应用程序(实例或容器)。

然后，100% 的流量逐渐从 蓝色环境切换到 绿化环境，比 蓝绿部署花费更长的时间(30分钟，小时，或者几天) ，如下所示，你可以说 金丝雀部署是蓝绿部署的渐进方式:

enter image description here 上面这张图片来自 https://www.encora.com/insights/zero-downtime-deployment-techniques-canary-deployments，最初是由公司 < strong > “ Encora”创建的

小开

我刚才回答了这个 有个问题，这里我也要解释一下，因为从我看到的来看，人们对这两者之间的区别有点困惑。

这与真正的用户无关。A/B 测试也可以在真正的用户身上进行。假设你想在你的网站上添加一个横幅来宣布一些事情(或者一个广告) ，但是你觉得这可能会对你的业务产生负面影响。因此，您可以将带有横幅的站点发送给一小部分用户，并跟踪他们的活动。这将是对一小部分用户的 A/B 测试。

或者假设你有一个新的 UI (或者两个 UI) ，你想看看哪一个能吸引更多的用户(用哪个 UI 你能得到更多的客户)。您可以发送50-50给所有用户，并再次跟踪他们的活动。那将是对一半用户的 A/B 测试。

所以它不是关于真正的用户或者一小群用户或者逐渐从一个版本切换到另一个版本等等。但是它更多的是关于功能和最重要的 会话亲和力。

根据我对另一个问题的回答

A/B 测试的目的通常是看用户对新 UI、特性等的反应(在某种程度上，看他们有多喜欢它)。但你知道新版本很有效。所以，你实际上把两个版本的应用程序随机发送给他们。五五分，八二分，九十分，什么都行。有时功能甚至不相关。你可能想看看哪个版本能吸引更多的客户之类的。

Canary 更关注新特性的工作效果。或者它是否真的有用。它通常是90-10,80-20，A > B 绝不是50-50，因为如果它出错了，你不希望你的一半用户有一个糟糕的体验。因此，如果新版本将按预期工作，那么您就不能确定。

最重要的区别(这是几乎没有人谈论的)是，金丝雀测试具有会话亲和性。因此，它不会将两个版本都发送给所有用户，而是随机地将一些用户发送到新版本，并将他们保持在相同的版本中。


提交答案