什么是蓝绿部署？
蓝绿部署是一种发布管理技术，可降低风险并最大程度地减少停机时间。它使用称为蓝色和绿色的两种生产环境来提供可靠的测试、持续的无中断升级和即时回滚。
蓝绿部署的起源
故事开始于 2005 年左右，有两个开发人员和一个问题。他们正在开发的电子商务网站出现了许多意外错误。这些开发人员一丝不苟，并有一个很好的测试套件，但由于某种原因，错误在雷达下飞来飞去并进入了生产阶段。整个情况给他们的客户带来了很多麻烦。
经过更深入的检查，他们找到了原因。他们注意到生产和测试机器之间存在太多差异。他们的测试在测试环境中通过了，但在生产中部署时代码失败了。
这些开发人员Daniel North 和 Jez Humble然后有了一个非常规但绝妙的主意。他们将直接在生产中进行部署和测试。
现在我知道你在想什么了。生产中的测试不是一个很大的禁忌吗？通常，是的。但是你看，这里的关键是他们没有覆盖旧网站。相反，他们在同一个物理盒子中并排运行新的，因此用户不知道正在进行的部署。旧站点继续照常工作，而 Dan 和 Jez 则负责发布。
部署是这样工作的。他们将包含最新版本的文件夹复制到生产机器中。然后他们使用单独的域启动了该网站，并在那里对其进行了冒烟测试。一旦他们感到高兴，他们就会将 Apache Web 服务器指向新文件夹，收工，大概喝一杯啤酒。如果出现任何问题，他们可以将 Web 服务器指向旧文件夹，修复错误，然后重试。这种策略极大地改进了错误检测，因为测试和生产环境现在是相同的。
此时，他们在同一台机器上有两个环境：一个用于旧版本，另一个用于新版本。最初，他们想用字母来称呼它们：环境 A、环境 B等等。但有人指出，人们会倾向于相信 A 在某种程度上比 B 更好（可能听起来太像“计划 B”了）。他们最终决定使用没有自然顺序的颜色来代替。因此，他们计划了诸如blue、green或orange 之类的名称（他们避免使用红色，因为它暗示着危险）。最后，事实证明他们只需要两个环境。因此创造了蓝绿色这个词。
蓝绿部署如何运作？
除了我们稍后将探讨的一些注意事项外，蓝绿色几乎检查了理想部署过程的所有框：
- 无缝：用户不应经历任何停机时间。
- 安全：失败的可能性低。
- 完全可逆：我们可以撤消更改而不会产生不利影响。
蓝绿方法的基础是并行部署。为此，我们需要两个独立但相同的环境。我指的是最通用的环境，包括服务器、虚拟机、容器、配置、数据库等。有时我们可以使用不同的盒子。其他时候，我们可以使用运行在同一硬件上的不同虚拟机。或者它们可以是在单个设备中运行的不同容器。
以最纯粹的形式，蓝绿要求我们复制我们的应用程序所依赖的每个资源。
然而，在实践中，运行所有内容的备用副本并不总是有意义的。例如，保持两个数据库同步尤其困难。出于这个原因，我们经常发现带有共享组件的蓝绿部署。
我们还需要某种方式来切换两个环境之间的传入连接。我们将用一个路由器符号来表示它。它可以是一个真正的路由器、一个负载平衡器、一个反向代理，或者像在原始情况下一样，一个 Web 服务器。
蓝色和绿色轮流扮演生产角色。在任何给定时间，只有一种环境处于活动状态。例如，假设蓝色处于活动状态。在这种情况下，它接收所有流量——同时，green 充当一个临时区域，我们可以在那里部署和测试下一个版本。
一旦我们确保以绿色运行的版本运行良好，我们将切换路线。然后循环再次开始。
云使蓝绿部署更可行
始终保持两组环境运行会变得昂贵。幸运的是，我们有许多工具可以让我们按需启动和拆除基础设施。我们可以使用基础设施即代码(IaC) 平台（如 Ansible 或 Terraform）启动和停止服务器。我们可以使用容器来简化发布，或者使用 Kubernetes 来编排部署。令人惊讶的是，当我们考虑到云提供的灵活性和成本降低时，每个人都可以实现蓝绿部署。
云将大部分基础设施抽象化。我们可以将部署描绘成一系列松散耦合的组件。
当需要发布新版本时，我们会在不接触实时环境的情况下创建新资源。在实践中，我们将使用像这样的CI/CD工具来创建相同的新组件并进行部署。
然后我们立即重新路由所有用户连接。
一旦部署完成并且我们感到满意，我们就可以废弃旧环境。
Kubernetes 是一种让蓝绿变得非常简单的技术。
谁可以从蓝绿部署中受益？
当我们需要时，蓝绿色是一个很好的解决方案：
- 正常运行时间：当我们无法关闭系统来更新它时。
- 准确测试：当需要更可靠和准确的测试时。
- 可靠性：当我们想要提高部署的可靠性时。
要使用蓝绿部署，我们需要做一些事情：
- 自动化：我们需要持续交付管道(CI/CD Pipeline)来自动化配置、部署和测试过程。
- 测试：我们需要详尽的测试。我们将依靠他们来决定何时可以部署版本。我们应该使用持续集成(continuous integration)来快速捕获错误并在上线之前测试新版本。
- 隔离：我们需要两个相同且独立的环境。否则，一种环境可能会影响另一种环境。
每个人都可以做蓝绿部署吗？并非总是如此，某些情况可能会阻止我们使用该方法：
- 无论在什么情况下，我们都无法进行持续更新。
- 当法规限制必须如何更新软件时。例如，在航空航天、电信或医疗行业。
- 当我们不能有两个相同的环境时。
- 当我们无法隔离环境时。
- 由于基础设施的原因，我们不能使用路由器、负载均衡器或反向代理。
- 当我们有破坏性的数据库架构更改时。数据库更改需要向前和向后兼容。
蓝绿部署的优点
那么，蓝绿是适合您的部署策略吗？要回答这个问题，我们必须比较它的优缺点。
让我们从优点开始：
- 测试奇偶校验：这是功能。测试对等意味着测试真正反映了生产的现实。这就是 Dan 和 Jez 在设计蓝绿色时所寻找的。通过在相同的硬件和软件上运行测试，他们使它们更有用和更有意义。
- 随时部署：无停机意味着我们可以随时发布。无需等待维护时段。
- 即时切换：用户即时或几乎切换到新版本。每个人都可以同时看到最新版本。
- 即时回滚：切换是双向的。如果我们决定回到以前的版本，我们可以立即将所有用户切换回来。
- 热备：蓝绿可以将我们从灾难场景中拯救出来。假设一个数据中心离线，导致现场环境瘫痪。没什么大不了的，我们会切换到另一个，直到问题得到解决。只要我们采取了不将蓝色和绿色放在同一个可用区上的预防措施，这就会起作用。
- 事后分析：就地部署很难调试失败的版本。面临停机时，首要任务始终是恢复正常。收集调试数据是次要的，因此在回滚过程中可能会丢失很多有价值的信息。Blue-green 不会遇到这个问题——回滚总是让失败的部署完好无损以供分析。
蓝绿部署的缺点
在这一点上，您可能会认为蓝绿色一定有问题。否则，每个可能会使用它的人。那么，让我们检查一下缺点：
- 冷启动：用户突然切换到新环境时可能会感到缓慢。此外，此时可能会出现任何未检测到的性能问题。热身作业和压力测试可以缓解这些问题。
- 成本：与其他方法相比，蓝绿部署更昂贵。按需配置基础架构会有所帮助。但是当我们每天进行几次横向扩展部署时，成本可能会滚雪球。
- 时间：设置蓝绿部署过程需要时间和精力。过程复杂，责任重大。在让它正常工作之前，我们可能需要进行多次迭代。
- 数据库：数据库迁移更难，甚至到了成为表演者的地步。数据库模式更改必须向前和向后兼容。我们可能需要在新旧版本之间来回移动。当我们有两个数据库时，问题变得更加复杂，一个用于蓝色，一个用于绿色。保持数据同步是一种痛苦。解决此问题的常见策略包括使用复制或将一个数据库设为只读。
- 用户交易：割接过程中，部分用户交易会中断。我们必须仔细考虑如何处理它们。我们应该如何处理半应用的交易？我们是否显示错误消息并告诉用户重试？或者我们是否尝试将它们转移到新环境中？一种可能的解决方案是同时并行地将所有事务提供给两个环境。在这种情况下，我们需要在部署完成后处理任何重复的数据。
- 共享服务：数据库和其他共享服务可能会在蓝绿之间泄漏信息。这里需要谨慎，否则一种环境可能会间接影响另一种环境。这可能会破坏隔离规则并干扰部署。
如您所见，蓝绿与传统的就地部署相比具有许多优点，但它也有一些缺点。有些人不喜欢全有或全无的方法，更喜欢使用金丝雀部署，它结合了蓝绿部署和就地部署的元素，并提供更渐进的过渡。