近些年，“DevOps”非常热门，最近，我们团队讨论了部署最佳实践、热部署、回滚等，当提到蓝绿部署时，大家表现出浓烈的兴趣。蓝绿部署已经在像亚马逊这样的地方实践了 10 多年。它们是一种安全、经过验证的方法。现在，蓝绿部署不是灵丹妙药，但它们有一定的用处。其实还有A/B 测试，甚至 Canary 测试，在所有微服务、DevOps和云原生交流中，有很多关于它们的讨论，因此，我简单归纳了它们的区别。Blue Green Deployments的详细介绍请参阅Martin Fowler 关于蓝绿部署的链接（http://martinfowler.com/bliki/BlueGreenDeployment.html）。它给出了总体要点。
它基本上是一种以可预测的方式发布应用程序的技术，目的是减少与发布相关的任何停机时间。这是在发布前为您的应用做好准备的一种快速方式，如果您发现问题，也可以快速回滚。
简单地说，您有两个相同的环境（基础架构），其中“绿色”环境托管当前的生产应用程序（例如 app1 version1、app2 version1、app3 version1）：
现在，当您准备对 app2 进行更改并将其升级到 v2 时，您将在“蓝色环境”中进行。在该环境中，您部署应用程序的新版本、运行冒烟测试和任何其他测试（包括那些用于运行/启动操作系统、缓存、CPU 等的测试）。当事情看起来不错时，您将负载均衡器/反向代理/路由器更改为指向蓝色环境：
您监视由于发布而导致的任何故障或异常。如果一切看起来不错，您最终可以关闭绿色环境并使用它来发布任何新版本。如果没有，您可以通过将负载均衡器指向回快速回滚到绿色环境。• 在绿色环境中长期运行的交易。当您切换到蓝色时，您必须优雅地处理那些未完成的交易以及新的交易。如果您的数据库后端无法处理此问题，这也会变得很麻烦（见下文）；• 企业部署通常不适合“微服务”风格的部署——也就是说，你可能有微服务风格的应用程序和一些传统的、难以更改的应用程序一起工作的混合体。为蓝绿部署在两者之间进行协调仍然可能导致停机；• 数据库迁移可能会变得非常棘手，并且必须与应用程序部署一起迁移/回滚。有很好的工具和技术可以做到这一点，但在传统 RDBMS、NoSQL 和文件系统支持的数据库的环境中，这些事情确实需要提前考虑；盲目地说你在做蓝绿部署没有任何帮助——实际上可能会造成伤害。• 如果您尝试在非隔离的基础架构（VM、Docker 等）上执行此操作，您将面临破坏蓝色和绿色环境的风险；
正如我所说，有一些很好的技术可以克服这些挑战并使这种部署方式非常有效，包括插入到持续部署管道中，但不要轻易跳入其中。A/B 测试不是蓝绿部署，有些人会混淆这一点。A/B 测试是一种出于各种原因（例如可用性、流行度、引人注目度等）以及这些因素如何影响底线而测试应用程序功能的方法。它通常与应用程序的 UI 部分相关联，但当然需要后端服务才能执行此操作。您可以使用应用程序级开关（即知道何时显示某些 UI 控件的智能逻辑）、静态开关（在应用程序中）以及使用 Canary 版本（如下所述）来实现这一点。
蓝绿部署和 A/B 测试之间的区别在于 A/B 测试用于测量应用程序中的功能。蓝绿部署是关于安全地发布新软件并按预期回滚。您显然可以将它们结合起来：使用蓝绿部署在可用于 A/B 测试的应用程序中部署新功能。最后，Canary发布是一种将您的应用程序的新版本发送到生产环境的方式，它扮演“云雀”的角色，以了解它将如何执行（与其他应用程序、CPU、内存、磁盘使用情况等集成） ）。这是另一种发布策略，可以缓解以下事实：无论您在较低环境中进行的测试级别如何，您仍然会在生产中遇到一些错误。云雀版本让您在完全释放扳机之前先试水。
您获得的反馈越快，部署失败或谨慎进行的速度就越快。出于与蓝绿部署相同的一些原因，请注意上述事项；即，数据库更改仍然会绊倒您。
无论您是否使用特定的云技术，都可以实施所有这些策略。但正如您想象的那样，Docker和Kubernetes等技术对实施这些策略非常有帮助（如果甚至没有内置规定）。例如，OpenShift和Fabric8通过提供使用这些技术所需的工具而无需担心底层细节，从而大大简化了使用 Docker 和 Kubernetes。原文链接：https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/
