我们在深入接触云原生软件的过程中，发现有些重要的需求是能够零停机时间和频繁发布代码，毫无疑问，软件开发生命周期中（尤其DevOps）需要密切地关注着部署相关的一切。
在 DevOps 实践和云原生基础设施的世界中，部署的概念已经从一个无趣的实现细节演变为现代系统的基本元素。似乎对其重要性有了一个普遍的理解，并且正在努力构建解决方案和工具以实现更好的部署实践。
这篇文章试图列出和定义哪些常见的部署策略：
- 重新创建(Recreate Deployment)：终止版本 A，然后推出版本 B。
- 滚动升级（Rolling Upgrade）：版本 B 缓慢推出并替换版本 A。
- 蓝绿部署(Blue/Green Deployment)：版本 B 与版本 A 一起发布，然后流量切换到版本 B。新版本B（蓝色版）上线进行测试和评估，用户仍使用稳定版A（绿色版）。准备就绪后，用户将切换到蓝色版本B。如果出现问题，您可以切换回绿色版本A。
- 金丝雀部署(Canary Deployment)：版本 B 发布给一部分用户，然后进行全面部署。
- A/B 部署：版本 B 在特定条件下发布给一部分用户。A/B 部署可以被认为类似于 A/B 测试，尽管 A/B 部署意味着代码和配置的多个版本，而 A/B 测试通常使用一个代码库进行特定于应用程序的检查。
- 影子部署（Shadow Deployment)：版本 B 与版本 A 一起接收真实世界的流量，并且不会影响响应。
重新创建(Recreate)
重新创建策略是一种虚拟部署，包括关闭版本 A，然后在关闭版本 A 后部署版本 B。这种技术意味着服务的停机时间取决于应用程序的关闭和启动持续时间。
优点：
- 易于设置。
- 应用程序状态完全更新。
缺点：
- 对用户的影响很大，预计停机时间取决于应用程序的关闭和启动持续时间。
滚动升级(Rolling Upgrade)
滚动升级部署策略包括通过一个接一个地替换实例来缓慢地推出应用程序的一个版本，直到推出所有实例。它通常遵循以下过程：在负载均衡器后面使用版本 A 的池，部署版本 B 的一个实例。当服务准备好接受流量时，实例被添加到池中。然后，从池中删除版本 A 的一个实例并关闭。
根据负责加速部署的系统，您可以调整以下参数以增加部署时间：
- 并行性，最大批量大小：要推出的并发实例数。
- 最大激增：在当前数量的基础上要添加多少个实例。
- 最大不可用：滚动更新过程中不可用实例的数量。
优点：
- 易于设置。
- 版本跨实例缓慢发布。
- 对于可以处理数据重新平衡的有状态应用程序很方便。
缺点：
- 推出/回滚可能需要时间。
- 支持多个 API 很困难。
- 无法控制流量。
蓝/绿部署(Blue/Green Deployment)
蓝/绿部署策略与斜坡部署不同，版本 B（绿色）与版本 A（蓝色）一起部署，实例数量完全相同。在测试新版本满足所有要求后，流量在负载均衡器级别从版本 A 切换到版本 B。
优点：
- 即时推出/回滚。
- 避免版本控制问题，整个应用程序状态一次性更改。
缺点：
- 昂贵，因为它需要两倍的资源。
- 在发布到生产环境之前，应对整个平台进行适当的测试。
- 处理有状态的应用程序可能很困难。
金丝雀(Canary Deployment)
金丝雀部署包括逐渐将生产流量从版本 A 转移到版本 B。通常根据权重拆分流量。例如，90% 的请求转到版本 A，10% 转到版本 B。
当测试缺乏或不可靠或者对平台上新版本的稳定性没有信心时，通常会使用此技术。
优点：
- 为部分用户发布的版本。
- 便于错误率和性能监控。
- 快速回滚。
骗局：
- 缓慢推出。
A/B部署
A/B 部署包括在特定条件下将一部分用户路由到新功能。它通常是一种基于统计信息而非部署策略做出业务决策的技术。但是，它是相关的，可以通过向金丝雀部署添加额外功能来实现，因此我们将在此处简要讨论它。
此技术广泛用于测试给定功能的转换，并仅推出转换最多的版本。
以下是可用于在版本之间分配流量的条件列表：
- 通过浏览器cookie
- 查询参数
- 地理定位
- 技术支持：浏览器版本、屏幕尺寸、操作系统等。
- 语
优点：
- 多个版本并行运行。
- 完全控制流量分布。
缺点：
- 需要智能负载均衡器。
- 很难对给定会话的错误进行故障排除，分布式跟踪成为强制性的。
影子部署(Shadow Deployment)
影子部署包括与版本 A 一起发布版本 B，分叉版本 A 的传入请求并将它们发送到版本 B，而不会影响生产流量。这对于测试新功能的生产负载特别有用。当稳定性和性能满足要求时，将触发应用程序的推出。
这种技术设置起来相当复杂，需要特殊要求，尤其是出口流量。例如，给定一个购物车平台，如果您想对支付服务进行影子测试，您最终可以让客户为他们的订单支付两次费用。在这种情况下，您可以通过创建一个复制来自提供者的响应的模拟服务来解决它。
优点：
- 使用生产流量对应用程序进行性能测试。
- 对用户没有影响。
- 在应用程序的稳定性和性能满足要求之前不会推出。
缺点：
- 昂贵，因为它需要两倍的资源。
- 不是真正的用户测试，可能会产生误导。
- 设置复杂。
- 在某些情况下需要模拟服务。
总结
有多种方法可以部署应用程序的新版本，这实际上取决于需求和预算。当发布到开发/暂存环境时，重新创建或升级部署通常是一个不错的选择。在生产方面，斜坡或蓝/绿部署通常是一个很好的选择，但对新平台进行适当的测试是必要的。
蓝/绿和影子部署策略对预算的影响更大，因为它需要双倍的资源能力。如果应用程序缺乏测试，或者对软件的影响/稳定性没有信心，那么可以使用金丝雀、a/b 测试或影子发布。如果您的企业需要在特定用户群中测试新功能，并且可以根据地理位置、语言、操作系统或浏览器功能等一些参数进行过滤，那么您可能需要使用 a/b 测试技术。
最后但并非最不重要的一点是，影子发布很复杂，需要额外的工作来模拟出口流量，这在使用可变操作（电子邮件、银行等）调用外部依赖项时是必需的。但是，当迁移到新的数据库技术并使用影子流量来监视负载下的系统性能时，此技术非常有用。
下图可帮助您选择正确的策略：
根据云提供商或平台的不同，以下文档可能是了解部署的良好开端：
本文参考了thenewstack.io，并做了一些定义上的修改。
