常见的几种部署方式

canary（金丝雀） 部署

在亚马逊等地方实行“ 绿色环保”部署已有十多年了。 它们是一种安全，可靠的方法。 现在，蓝绿色的部署不是灵丹妙药，但对它们来说很有用。 但是，A / B测试呢？ 甚至金丝雀测试？ 在所有＃microservices，DevOps和云原生的讨论中，有很多关于它们的讨论，但是我想澄清它们之间的区别。

蓝绿色部署

请欣赏Martin Fowler关于蓝绿色部署的链接 。 它给出了总体要点。 基本上，这是一种以可预测的方式发布应用程序的技术，目的是减少与发布相关的停机时间 。 这是在发布应用前准备应用的快速方法，如果发现问题也可以快速回滚。

简而言之，您拥有两个相同的环境（基础结构），其中的“绿色”环境托管着当前的生产应用程序（例如，app1 version1，app2 version1，app3 version1）：

绿色部署

现在，例如，当您准备对app2进行更改并将其升级到v2时，您将在“蓝色环境”中进行操作。 在该环境中，您将部署该应用程序的新版本，运行冒烟测试以及任何其他测试（包括对操作系统，缓存，CPU等进行测试/启动的测试）。 当一切看起来不错时，您可以更改负载平衡器/反向代理/路由器以指向蓝色环境：

您监视由于发行而引起的任何故障或异常。 如果一切看起来不错，您最终可以关闭绿色环境，并使用它来发布任何新版本。 如果没有，您可以通过将负载均衡器向后指向来快速回滚到绿色环境。
理论上听起来不错。 但是有些事情要提防。

在绿色环境中长期运行的事务。 当您切换到蓝色时，您必须优雅地处理那些未完成的事务以及新的事务。 如果您的数据库后端无法处理此问题，这也会变得很麻烦（请参阅下文）
企业部署通常不适合“微服务”风格的部署-也就是说，您可能混合了微服务风格的应用程序和一些传统的，难以更改的应用程序一起工作。 进行蓝绿色部署之间的协调仍然会导致停机
数据库迁移可能会非常棘手，因此必须与应用程序部署一起迁移/回滚。 有很好的工具和技术可以执行此操作，但是在具有传统RDBMS，NoSQL和文件系统支持的DB的环境中，确实需要事先考虑这些事情； 盲目地说您正在进行Blue Green部署无济于事–实际上可能会造成伤害。
您需要具备执行此操作的基础结构
如果尝试在非隔离的基础架构（VM，Docker等）上执行此操作，则可能会破坏蓝色和绿色环境
正如我已经说过的那样，有许多好的技术可以克服这些挑战，并使这种部署样式很好地实现，包括插入一个连续的部署管道，但不要轻描淡写。

A / B测试
A / B测试不是蓝绿色的部署。 我碰到了会误解这一点的团体。 A / B测试是一种出于各种原因（例如可用性，受欢迎程度，引人注意等）以及这些因素如何影响底线而测试应用程序功能的方法。 它通常与应用程序的UI部分相关联，但是当然需要后端服务才能实现此目的。 您可以使用应用程序级开关（即知道何时显示某些UI控件的智能逻辑），静态开关（在应用程序中）以及Canary版本（如下所述）来实现此功能。

蓝绿色部署与A / B测试之间的区别在于A / B测试是为了衡量应用程序中的功能。 蓝绿色部署是关于安全发布新软件并可以预测地回滚。 您显然可以将它们结合起来：使用蓝绿色部署在可用于A / B测试的应用程序中部署新功能。

金丝雀发布

最后，Canary版本是一种将应用程序的新版本发送到生产环境中的一种方法，该过程扮演“ canary”角色，以了解其性能（与其他应用程序，CPU，内存，磁盘使用情况等集成） ）。 这是另一种发布策略，可以缓解以下事实：无论在较低环境中进行的巨大级别的测试，在生产中仍然会有一些错误。 金丝雀释放可以让您测试水域，然后再完全释放触发器。

获得的反馈越快，部署失败或谨慎进行的速度就越大。 出于与蓝绿色部署相同的原因，请当心以上几点，请当心。 也就是说，数据库更改仍然会使您失望。

摘要
无论您是否使用特定的云技术，都可以实施所有这些策略。 但是正如您可以想象的那样，诸如Docker和Kubernetes之类的技术对于实施这些策略可能非常有帮助（即使没有内置规定）。 例如， OpenShift和Fabric8通过提供使用这些技术所需的工具而不必担心底层细节， 从而大大简化了Docker和Kubernetes的使用。 可以分享一些精彩的视频，这些视频演示了此工具以及我上面讨论的即用型部署功能：

Veer Muchandi演示了OpenShift v3上的蓝绿色部署
James Rawlings 用Fabric8v2内置的完整CI / CD演示了金丝雀版本