蓝绿部署（Blue-Green Deployment）

蓝绿部署已被亚马逊等公司实践了十多年，是一种经过验证的持续软件部署安全方法。

您的用户是否经历过因错误发布而导致的停机？你是否曾在周末被叫去回滚升级？你是否经常要在疯狂的时候起床，因为只有在这个时候才能关闭系统？发布日会让你感到焦虑吗？

如果是这样，没关系--你并不孤单--但不必非得如此。有许多方法可以帮助我们在不停机或不需要维护窗口的情况下进行安全部署。其中一种方法叫做蓝绿（或蓝/绿），这就是我们今天要学习的内容。

什么是蓝绿部署？

蓝绿部署是一种发布管理技术，可降低风险并最大限度地减少停机时间。它使用两个生产环境（称为 “蓝 ”和 “绿”）来提供可靠的测试、持续的无中断升级和即时回滚。

蓝绿部署的起源

故事开始于 2005 年左右，当时有两名开发人员和一个问题。他们正在开发的电子商务网站出现了许多意想不到的错误。这两名开发人员一丝不苟，并制定了良好的测试套件，但不知何故，错误总是在不经意间出现，并影响到生产。整个情况给他们的客户带来了很多麻烦。

经过更深入的检查，他们找到了原因。他们注意到生产机器和测试机器之间存在太多差异。他们在测试环境中通过了测试，但在生产环境中部署代码时却失败了。

丹尼尔-诺斯（Daniel North）和杰兹-汉布尔（Jez Humble）这两位开发人员随后想到了一个非常规但又绝妙的主意。他们将直接在生产中进行部署和测试。

我知道你在想什么。在生产中进行测试不是大忌吗？通常是的。但你看，这里的关键点在于，他们并没有覆盖旧网站。相反，他们是在同一个物理机箱中并排运行新网站，因此用户不会察觉到正在进行的部署。当 Dan 和 Jez 忙于发布时，旧网站照常运行。

部署工作是这样进行的。他们将包含最新版本的文件夹复制到生产机器中。然后，他们使用一个单独的域启动网站，并在那里进行烟雾测试。一旦他们感到满意，就会将 Apache 网络服务器指向新文件夹，然后收工，大概还会喝上一轮啤酒。如果出现任何问题，他们可以将网络服务器指向旧文件夹，修复错误，然后再试一次。这种策略大大提高了错误检测能力，因为测试和生产环境现在是一样的。

此时，他们在同一台机器上有两个环境：一个是旧版本，另一个是新版本。起初，他们想用字母来称呼它们：环境 A、环境 B，以此类推。但有人指出，人们会倾向于认为 A 在某种程度上比 B 好（也许听起来太像 “B 计划 ”了）。最后，他们决定用颜色来代替，因为颜色没有自然顺序。因此，他们计划用蓝色、绿色或橙色来命名（他们避免使用红色，因为红色意味着危险）。最后，他们发现只需要两种环境。于是就有了蓝绿色这个词。

蓝绿部署如何运作？

除了我们稍后将探讨的一些注意事项外，蓝绿部署几乎可以满足理想部署流程的所有要求：

- 无缝：用户不会经历任何停机时间。

- 安全：故障几率低。

- 完全可逆：我们可以撤销更改，而不会造成不良影响。

蓝绿方法的基础是并行部署。为此，我们需要两个独立但完全相同的环境。我指的环境是最一般的环境，包括服务器、虚拟机、容器、配置、数据库等。有时，我们可以使用不同的服务器。有时，我们可以使用运行在同一硬件上的不同虚拟机。或者，它们可以是在单个设备中运行的不同容器。

两个独立的生产环境

但在实际操作中，并不是所有东西都需要运行一个备用副本。例如，保持两个数据库同步就非常困难。因此，我们经常发现共享组件的蓝绿部署。

两个具有某些共享组件的生产环境

我们还需要在两个环境之间切换输入连接的方法。我们将用路由器符号来表示。它可以是一个真正的路由器、一个负载平衡器、一个反向代理，或者像最初的情况一样，是一个网络服务器。

路由器每次将流量切换到一个生产环境

蓝色和绿色轮流扮演生产角色。在任何时候，只有一个环境处于运行状态。比如说，蓝色环境处于运行状态。在这种情况下，蓝色环境接收所有流量，而绿色环境则作为暂存区，我们可以在此部署和测试下一个版本。

用户继续访问蓝色版本v1，而新的版本v2则部署在绿色版本上

一旦确定绿色版本运行良好，我们就会切换路线。然后循环往复。

一旦用户切换到运行在绿色系统上的新版本，部署工作即告完成

云使蓝绿部署更可行

始终保持两套环境的运行成本会很高。幸运的是，我们有很多工具可以按需启动和关闭基础设施。我们可以通过 Ansible 或 Terraform 等基础设施即代码（IaC）平台启动和停止服务器。我们可以使用容器简化发布，或使用 Kubernetes 协调部署。令人惊讶的是，当我们考虑到云所提供的灵活性和成本降低因素时，蓝绿部署就变得触手可及了。

云将大部分基础设施抽象化。

我们可以将部署描绘成一系列松散耦合的组件。

云中的蓝色生产环境

当需要发布新版本时，我们会在不接触实时环境的情况下创建新资源。在实践中，我们将使用Semaphore等CI/CD工具来创建相同的新组件并进行部署。

按需创建绿色生产环境

然后，我们一次性重新路由所有用户连接。

用户流量切换到绿色生产环境

一旦部署完成，我们感到满意，就可以废除旧环境。

去除蓝色，以释放资源和降低成本

Kubernetes 就是一种能让 “蓝绿 ”变得简单明了的技术。要了解更多信息并查看 Kubernetes 的实际部署情况，请免费下载我们的电子书： 使用 Docker 和 Kubernetes 进行 CI/CD。

谁能从蓝绿部署中受益？

当我们需要时，蓝绿技术是一个很好的解决方案：

- 正常运行时间：当我们无法承担停机更新系统的费用时。

- 准确测试：需要更可靠、更准确的测试时。

- 可靠性：当我们希望提高部署的可靠性时。

要使用蓝绿部署，我们需要一些东西：

- 自动化：我们需要持续交付管道来实现调配、部署和测试流程的自动化。

- 测试：我们需要详尽的测试。我们将依靠它们来决定何时可以部署发布版本。我们应该使用持续集成来快速捕捉错误，并在上线前测试新版本。

- 隔离：我们需要两个完全相同的独立环境。否则，一个环境可能会影响另一个环境。

每个人都能进行蓝绿部署吗？不一定，某些情况下我们可能无法使用这种方法：

- 无论在什么情况下，我们都无法进行持续更新。

- 法规限制了软件更新的方式。例如，在航空航天、电信或医疗行业。

- 当我们无法拥有两个完全相同的环境时。

- 当我们无法隔离环境时。

- 由于基础设施的原因，我们无法使用路由器、负载平衡器或反向代理。

蓝绿部署的优点

那么，蓝绿部署战略是否适合你？要回答这个问题，我们必须比较一下它的优缺点。

测试均等：这是最大的特点。测试均等意味着测试能真正反映生产的实际情况。这正是 Dan 和 Jez 设计蓝绿测试时所追求的。通过在相同的硬件和软件上运行测试，他们让测试变得更有用、更有意义。

随时部署：无停机时间意味着我们可以随时发布版本。无需等待维护窗口。

即时切换：用户可即时或几乎即时切换到新版本。每个人都能同时看到最新版本。

即时回滚：切换是双向的。如果我们决定返回到以前的版本，我们可以立即将所有用户切换回去。

热备用：蓝绿可以在灾难场景中拯救我们。假设一个数据中心脱机，导致实时环境瘫痪。没关系，我们可以切换到另一个数据中心，直到问题解决。只要我们采取预防措施，不将蓝绿数据中心放在同一可用区，这种方法就能奏效。

事后分析：就地部署很难调试失败的发布版本。面对宕机，优先考虑的总是恢复正常。收集调试数据是次要的，因此在回滚过程中可能会丢失很多有价值的信息。蓝绿系统就不会出现这个问题--回滚过程中，失败的部署总是完好无损，可供分析。

蓝绿部署的缺点

说到这里，你可能会想，蓝绿部署肯定有缺点。否则，每个有能力的人都会使用它。那么，让我们来看看它的缺点：

冷启动：用户在突然切换到新环境时可能会遇到运行缓慢的问题。此外，任何未检测到的性能问题都可能在此时出现。预热工作和压力测试可以缓解这些问题。

成本：与其他方法相比，蓝绿部署成本更高。按需配置基础设施会有所帮助。但是，当我们每天要进行多次扩展部署时，成本就会像滚雪球一样越滚越大。

时间：建立蓝绿部署流程需要时间和精力。该流程非常复杂，责任重大。我们可能需要反复多次才能使其正常运行。

数据库：数据库迁移比较困难，甚至会导致失败。数据库模式更改必须向前和向后兼容。我们可能需要在新旧版本之间来回切换。如果我们有两个数据库，一个是蓝色数据库，一个是绿色数据库，问题就更复杂了。保持数据同步是个麻烦事。常见的应对策略包括使用复制或将一个数据库设为只读。

用户交易：在切换期间，一些用户交易将被中断。我们必须仔细考虑如何处理它们。我们应该如何处理应用了一半的事务？是显示错误信息，让用户重试？还是尝试将它们带入新环境？一种可能的解决方案是将所有事务并行地同时馈送到两个环境中。在这种情况下，我们需要在部署完成后处理任何重复的数据。

共享服务：数据库和其他共享服务可能会在蓝绿之间泄露信息。在此我们需要谨慎，否则一个环境可能会间接影响另一个环境。这可能会破坏隔离规则并干扰部署。

如你所见，蓝绿与传统的就地部署相比有很多优点，但也有一些缺点。有些人不喜欢“全有或全无 ”的方法，而更喜欢使用 ”金丝雀 ”发布，它结合了蓝绿部署和就地部署的元素，提供了更渐进的过渡。