我最近接触过的很多团队都对“devops”很感兴趣（不管那是什么意思……对不同的人来说似乎意味着不同的东西？）当我们坐下来讨论它的真正含义时，谈话的方向可以沿着许多有趣的路径。而且有时候，它走的路让人觉得 很不舒服 。前一段时间我和一个团队讨论部署最佳实践、热部署、回滚等，当我提到 蓝绿部署 时，他们变得有点反胃。另一个团队不明白为什么做他们一直在做的事情 并不是一件好事 。
蓝绿部署 已经在亚马逊等地实践了 10 多年。它们是一种安全、经过验证的方法。现在，蓝绿部署不是灵丹妙药，但对它们有一定的用处。但是a/b测试呢？甚至金丝雀测试？在所有关于#microservices、devops 和云原生的讨论中，有很多关于它们的讨论，但我想澄清它们之间的区别。
蓝绿部署
请查看 martin fowler 关于蓝绿部署的链接 。它提供了总体要点。它基本上是一种 以可预测的方式发布应用程序的 技术，目的是 减少与发布相关的任何停机时间 。这是在发布应用程序之前准备好应用程序的快速方法，如果发现问题也可以快速回滚。
简而言之，您有两个相同的环境（基础设施），“绿色”环境托管当前的生产应用程序（例如 app1 version1、app2 version1、app3 version1）：
现在，当您准备好对 app2 进行更改并将其升级到 v2 时，您将在“蓝色环境”中执行此操作。在该环境中，您可以部署新版本的应用程序、运行冒烟测试和任何其他测试（包括运行/启动操作系统、缓存、CPU 等的测试）。当一切看起来不错时，您将负载平衡器/反向代理/路由器更改为指向蓝色环境：
您监控因发布而导致的任何故障或异常。如果一切看起来都不错，您最终可以关闭绿色环境并使用它来暂存任何新版本。如果没有，您可以通过将负载均衡器指向后方来快速回滚到绿色环境。
理论上听起来不错。但有些事情需要注意。
- 在绿色环境中长期运行的事务。当你切换到蓝色时，你必须优雅地处理那些未完成的交易以及新的交易。如果您的数据库后端无法处理这个问题，这也会变得很麻烦（见下文）。
- 企业部署通常不适合“微服务”风格的部署——也就是说，您可能混合使用微服务风格的应用程序，以及一些传统的、难以更改的应用程序一起工作。在两者之间协调蓝绿部署仍然会导致停机
- 数据库迁移可能会变得非常棘手，并且必须与应用程序部署一起迁移/回滚。有很好的工具和技术可以做到这一点，但在具有传统 rdbms、nosql 和文件系统支持的数据库的环境中，确实需要提前考虑这些事情；盲目地说你正在进行蓝绿色部署没有任何帮助——它实际上可能会造成伤害。
- 你需要有基础设施来做到这一点
- 如果您尝试在非隔离基础设施（vms、docker 等）上执行此操作，您将面临破坏蓝绿环境的风险
正如我所说，有一些很好的技术可以克服这些挑战并使这种部署方式非常有效，包括插入持续部署管道，但不要随便跳进去。
a/b测试
A/B 测试不是蓝绿部署。我遇到过一些错误的团体。 a/b 测试是一种出于各种原因（例如可用性、受欢迎程度、引人注目等）以及这些因素如何影响底线 而测试应用程序功能 的方法。它通常与应用程序的用户界面相关联，但当然需要后端服务才能执行此操作。您可以使用应用程序级开关（即知道何时显示某些 ui 控件的智能逻辑）、静态开关（在应用程序中）以及使用金丝雀发布（如下所述）来实现这一点。
蓝绿部署和 a/b 测试之间的区别在于 a/b 测试用于衡量应用程序中的功能。蓝绿部署是关于安全地发布新软件并可预测地回滚。您显然可以将它们结合起来：使用蓝绿部署在可用于 A/B 测试的应用程序中部署新功能。
金丝雀发布
最后，金丝雀发布是一种将应用程序的新版本发送到生产环境的方式，它扮演着“金丝雀”的角色，以了解它将如何执行（与其他应用程序、CPU、内存、磁盘使用等集成） ).这是另一种发布策略，可以缓解这样一个事实：无论您在较低环境中进行的测试水平如何，您仍然会在生产中遇到一些错误。金丝雀发布让您在全面发布之前先试水。
您获得的反馈越快，部署失败或谨慎进行的速度就越快。出于与蓝绿部署相同的一些原因，请注意上述事项；即，数据库更改仍然会使您出错。
概括
无论您是否使用特定的云技术，所有这些策略都可以实施。但正如您可以想象的那样， docker 和 kubernetes 等技术对于实施这些策略非常有帮助（即使没有内置规定）。例如， openshift 和 fabric8 通过提供使用这些技术所需的工具而无需担心底层细节，从而大大简化了 docker 和 kubernetes 的使用。要分享的几个很棒的视频展示了我在上面讨论的这个工具和开箱即用的部署功能：