10.DevOps - 部署策略

在我们当前的 DevOps/Cloud 世界中，我们有很多强大的工具来部署和向世界公开我们的服务。但是使用强大的功能却没有正确的使用方法，对于您的团队/企业来说可能是一个巨大的损失（金钱、时间……） 。

因此，这里有一些部署策略可以帮助您改进部署和/或利用您的工具。

什么是部署策略？
“部署策略”是管道的一部分，您可以在其中定义如何部署应用程序/服务。

您可以有一个简单的部署管道，其中的策略适用于整个管道。

但是您可以拥有更复杂的管道（如 CD [1] 管道），其中策略只涉及其中的一部分。

攻略
重建
重新创建策略是最简单且成本效益较低的策略。

顾名思义，该策略由 2 个步骤组成

删除服务器/集群中应用程序的当前版本
在服务器/集群中部署新版本

优点
做起来简单快捷
由许多流水线工具支持
缺点
该服务将在一段时间内不可用。因此，如果您的 SLA [2]很高，那么它显然不是最佳选择。
新版本必须支持所有现有功能而不进行重大更改（如果您有一些重大更改，这对您的消费者来说可能是个问题）。
滚动部署
此策略将使用新版本逐步更新应用程序的所有实例。

脚步 ：

为每个实例循环
杀死现有实例
使用新版本部署新实例
检查新实例是否正确启动，如果是则转到下一个实例

优点
不会影响您的可用性
易于使用和设置 Kubernetes
缺点
新版本必须支持所有现有功能而不进行重大更改（如果您有一些重大更改，这对您的消费者来说可能是个问题）。
多个版本
顾名思义，这个策略简单明了，是为了在生产中支持应用程序的多个版本。

优点
会让您的客户有时间迁移到新版本
您的应用程序不需要支持旧功能
但…

缺点
仅当您有重大更改时才使用它。如果您在不破坏更改的情况下为每个版本都这样做，您将失去生产力，尤其是在支持方面。
支持更多生产版本。您在生产中拥有更多版本，您必须更新/测试更多版本…当生产问题发生时。
花很多时间。使用此策略，您将不得不手动设置很多东西（管道、路由配置…）。
一定要从构思阶段考虑，避免以后有很多的breaking changes。
这种策略在重大变更案例中非常有用。但正如所解释的，您可能会有一些惊喜。

因此，如果您要使用它，请注意缺点并准备一个明确的策略，以避免每年有 45 个重大更改并同时支持 10 个版本。考虑到这些因素，应该没问题。

蓝绿
该策略基于 2 个生产环境：

可以使用服务的现场
我们部署新版本服务的阶段
当您的暂存环境准备好用于生产时（在质量测试之后），您必须在两个环境之间转移流量。

如果在暂存环境上一切正常，您可以将流量完全切换到这个环境，这将成为新的“现场”环境。

如果您遇到一些问题，请将所有流量切换回该服务的当前版本。

优点
简单易懂
使用一些工具可以很容易地设置
轻松回滚
缺点
使用一些本身不具备此功能的工具（或者如果您手动进行设置）可能会花费更长的时间
可能很贵。您将必须至少将服务的运行实例翻倍，以便拥有所有可用资源来运行它们并重新部署它们。（如果您使用微服务，可能会更多）
设置起来可能很复杂，尤其是微服务，如果您使用 Kafka 或 MQ 之类的东西，则更是如此。您必须确保所有服务仅与“同一环境中的其他服务”通信。
金丝雀
此策略是将您的用户逐步迁移到新版本。

怎么做？

您将用新版本替换您当前的一些实例，并且您将转移它上面的一些流量。然后您可以检查新版本上的所有内容是否适合该组。

如果是，您可以增加使用新版本的用户百分比，并继续用“旧”版本替换实例，直到更新所有实例。

如果不是，您可以轻松回滚到“旧”版本。

优点
比蓝/绿策略更容易和更便宜的设置
快速安全的生产迁移解决方案
缺点
必须有更多的准备/设置/配置以防发生重大变化
作为蓝/绿策略，使用微服务进行设置可能会很复杂，尤其是当您使用 Kafka 或 MQ 等队列服务时。
必须进行监控设置才能正确查看两个版本上发生的情况。
A/B 测试
A/B 休息是一种技术上类似于 Canary 策略的策略。您将在有限数量的实例上部署新版本并转移一些流量。

但是，这里的目标是更多地对多个想法进行一些实验，看看哪个效果好。

我认为这是前端应用程序的一个很好的部署，可以查看用户是否感到无聊或不会在序列中间退出以查找/做某事。

优点
真的很强大，可以检索一些真实世界的印象
安装简单且便宜
缺点
实验心态。您将进行测试和实验。有些元素可能会破坏应用程序，因此根据应用程序的严重程度，您必须采取一些预防措施
因为它用于实验，所以设置自动化测试可能会很长和/或很复杂
最好的策略是什么？
每个部署都没有最佳策略。他们都有自己的优点和缺点。

那么如何选择呢？

这将取决于几点。所以一定要看看以下几点，然后问你“根据我的回答，什么最合适？”。

标准
可用性：您的应用程序是否可以在一段时间内关闭？
批评：如果在部署过程中出现问题，您会承担风险吗？（例如：数据库完整性）
重大变更：您会部署具有重大变更的新版本吗？
预算：您的基础设施/部署预算大吗？
流量管理：您有什么东西可以轻松管理应用程序的流量吗？
我的经验
根据我的经验，我发现一个项目不会只有一种部署策略。没有魔法。您不会以相同的方式管理有和没有重大变化的版本。

我通常看到：

简单且未真正使用的应用程序的重新创建策略
“简单更新”的滚动部署
金丝雀（当所有工具都在这里时）进行巨大的更新，而不会破坏更改或打开新的大功能
用于基础设施迁移或重写应用程序而不更改功能的蓝/绿部署
在使用辅助策略进行重大更改的情况下进行多版本部署，以确保不同版本的数量不会增加，并且所有消费者都将“快速”进行更新
当你想测试一些用户界面并想看看哪个是最有效的时，A/B 部署。
总而言之，即使您已经在生产环境中，也不要害怕在您的非生产环境中进行一些测试或改变您的策略。

尤其是在 IT 领域，我们不知道未来 5 到 10 年是否会有什么东西能胜任这项工作。所有这些解决方案都可以长期有效，但也许新工具/策略最适合您的环境，或者您的环境可以发展！

因此，不要将您的选择刻在石头上并接受您的解决方案，了解每个方案的所有优点/缺点，一切都应该没问题！

希望对您有所帮助！🍺