蓝绿色配色_蓝绿色部署

蓝绿色配色

传统上，我们通过替换当前版本来部署新版本。 旧版本停止了，新版本被替换了。 这种方法的问题是从旧版本停止到新版本完全运行之间的停机时间。 无论您尝试执行此过程的速度如何，都会有一些停机时间。 那可能只有一毫秒，也可能持续数分钟，在极端情况下甚至可能持续数小时。 具有整体式应用程序会带来其他问题，例如，需要等待相当长的时间才能初始化应用程序。 人们试图以各种方式解决此问题，并且大多数人使用了蓝绿色部署过程的某些变体。 其背后的想法很简单。 在任何时候，其中一个版本都应处于运行状态，这意味着在部署过程中，我们必须与旧版本并行部署一个新版本。 新版本和旧版本分别称为蓝色和绿色。

在任何给定的时刻，至少有一个服务版本已启动并正在运行

我们将一种颜色作为当前版本运行，将另一种颜色作为新版本运行，并在完全运行后将所有流量从当前版本切换到新版本。 通常使用路由器或代理服务进行此切换。

使用蓝绿色流程，不仅可以减少部署停机时间，而且还可以减少部署可能带来的风险。 无论我们在软件到达生产节点之前对其进行了多好的测试，总是有可能出问题。 发生这种情况时，我们仍然可以使用当前版本。 在经过足够的测试以验证由于生产节点的某些细节导致的任何合理的失败可能性之前，没有真正的理由将流量切换到新版本。 这通常意味着集成测试是在部署之后和进行“切换”之前执行的。 即使这些验证返回了假阴性，并且在重定向流量后仍然存在故障，我们仍可以快速切换回旧版本并将系统还原到以前的状态。 与需要从某些备份还原应用程序或进行另一次部署相比，我们可以回滚得更快。

如果我们将蓝绿色的流程与不可变的部署（过去通过虚拟机，今天通过Docker容器）相结合，那么结果将是一个功能强大，安全且可靠的部署过程，可以更频繁地执行该过程。 如果架构是基于微服务结合Docker容器的，则我们不需要两个节点来执行该过程，并且可以同时运行两个版本。

这种方法面临的重大挑战是数据库。 在许多情况下，我们需要以支持两个版本的方式升级数据库架构，然后继续进行部署。 此数据库升级可能引起的问题通常与发行版之间的间隔时间有关。 当经常完成发行时，对数据库模式的更改往往很小，从而使维护两个发行版之间的兼容性更加容易。 如果两次发布之间相隔数周或数月，则数据库更改可能会很大，以至于向后兼容可能无法实现或不值得做。 如果我们的目标是持续交付或部署，则两次发布之间的时间间隔应该较短，或者如果不是，则涉及对代码库的相对少量更改。

蓝绿色部署过程

蓝绿色部署过程在应用于以容器包装的微服务时，如下所示。

当前版本（例如蓝色）正在服务器上运行。 该版本的所有流量都通过代理服务进行路由。 微服务是不变的，并作为容器部署。

不变的微服务部署为容器

当准备好要部署新版本（例如绿色）时，我们将其与当前版本并行运行。 这样，由于所有流量都将继续发送到当前版本，因此我们可以在不影响用户的情况下测试新版本。

新版本的不变微服务与旧版本一起部署

一旦我们认为新版本可以按预期工作，就可以更改代理服务配置，以便将流量重定向到该版本。 大多数代理服务都将使用旧的代理配置让现有请求完成其执行，从而不会造成中断。

重新配置Poxy以指向新版本

当发送到旧版本的所有请求均收到响应时，可以删除服务的先前版本，甚至更好的是，停止运行该服务。 如果使用后一个选项，则在新版本失败的情况下，回滚几乎是瞬时的，因为我们要做的就是恢复旧版本。

旧版本已删除

翻译自: https://www.javacodegeeks.com/2016/02/blue-green-deployment.html

蓝绿色配色