应用部署的六种策略

来源：互联网发布：办公室椅子知乎编辑：程序博客网时间：2024/06/06 01:57

目前有各种各样的技术来将新应用部署到生产环境，所以权衡对系统和终端用户的影响降至最少，选择正确的方式是非常重要的。

本文将着重讨论如下部署策略：

重建部署：版本A下线后版本B上线
滚动部署（滚动更新或者增量发布）：版本B缓慢更新并替代版本A
蓝绿部署：版本B并行与版本A发布，然后流量切换到版本B
金丝雀部署：版本B向一部分用户发布，然后完全放开
A/B部署布：版本B只向特定条件的用户发布
影子部署：版本B接受真实的流量请求，但是不产生响应

我们来看一下每个策略最适合哪种用户使用场景。为了简化，我们使用Kubernetes，并用Minikube进行例子演示。每个策略的配置例子和详细步骤都可以在这个Git仓库[1]上找到。

重建策略

重建策略是一个冗余的方式，它包含下线版本A，然后部署版本B。这个方式意味着服务的宕机时间依赖于应用下线和启动耗时。

优点：

便于设置
应用状态完整更新

缺点：

对用户影响很大，预期的宕机时间取决于下线时间和应用启动耗时

滚动部署

滚动部署策略是指通过逐个替换应用的所有实例，来缓慢发布应用的一个新版本。通常过程如下：在负载调度后有个版本A的应用实例池，一个版本B的实例部署成功，可以响应请求时，该实例被加入到池中。然后版本A的一个实例从池中删除并下线。

考虑到滚动部署依赖于系统，可以调整如下参数来增加部署时间：

并行数，最大批量执行数：同时发布实例的数目
最大峰值：考虑到当前实例数，实例可以加入的数目
最大不可用数：在滚动更新过程中不可用的实例数

优点：

便于设置
版本在实例间缓慢发布
对于能够处理数据重平衡的有状态应用非常方便

缺点：

发布/回滚耗时
支持多个API很困难
无法控制流量

蓝绿部署

蓝绿部署策略与滚动部署不同，版本B（绿）同等数量的被并排部署在版本A（蓝）旁边。当新版本满足上线条件的测试后，流量在负载均衡层从版本A切换到版本B。

优点：

实时发布、回滚
避免版本冲突问题，整个应用状态统一一次切换

缺点：

比较昂贵因为需要双倍的资源
在释放版本到生产环境之前，整个平台的主流程测试必须执行
处理有状态的应用很棘手

金丝雀部署

金丝雀部署是指逐渐将生产环境流量从版本A切换到版本B。通常流量是按比例分配的。例如90%的请求流向版本A，10%的流向版本B。

这个技术大多数用于缺少足够测试，或者缺少可靠测试，或者对新版本的稳定性缺乏信心的情况下。

优点：

版本面向一部分用户发布
方便错误评估和性能监控
快速回滚

缺点：

发布缓慢

A/B测试

A/B测试是指在特定条件下将一部分用户路由到新功能上。它通常用于根据统计来制定商业决策，而不是部署策略。然而，他们是相关的，可以在金丝雀部署方式上添加额外功能来实现，所以我们这里简要介绍一下。

这个技术广泛用于测试特定功能的切换，并发布使用占大部分的版本。

下面是可以用于在版本间分散流量的条件：

浏览器cookie
查询参数
地理位置
技术支持：浏览器版本、屏幕尺寸、操作系统等
语言

优点：

多个版本并行运行
完全控制流量分布

缺点：

需要智能负载均衡
对于给定的会话，很难定位问题，分布式跟踪是必须的

影子部署

影子部署是指在版本A旁边发布版本B，将版本A进来的请求同时分发到版本B，同时对生产环境流量无影响。这是测试新特征在产品负载上表现的很好用的方式。当满足上线要求后，则触发发布新应用。

这个技术配置非常复杂，而且需要特殊条件，尤其是分出请求。例如一个购物车平台，如果你想影子测试支付服务，你可能最终会是用户为他们的订单支付两次。这种情况下，可以通过创建一个仿真的服务来重复响应用户的请求。

优点：

可以使用生产环境流量进行性能测试
对用户无影响
直到应用的稳定性和性能满足要求后才发布

缺点：

双倍资源，成本昂贵
不是真实用户测试，可能出现误导
配置复杂
某种情况下需要模拟服务

总结

部署应用有很多种方法，实际采用哪种方式取决于需求和预算。当发布到开发或者模拟环境时，重建或者滚动部署是一个好选择。当发布到生产环境时，滚动部署或者蓝绿部署通常是一个好选择，但是新平台的主流程测试是必须的。

蓝绿部署和影子部署对预算有更高的要求，因为需要双倍资源。如果应用缺乏测试或者对软件的功能和稳定性影响缺乏信心，那么可以使用金丝雀部署或者AB测试或者影子发布。如果业务需要根据地理位置、语言、操作系统或者浏览器特征等这样参数来给一些特定的用户测试，那么可以采用AB测试技术。

最后但并不是最不重要的，影子发布很复杂，且需要额外工作来模拟响应分支流量请求，当可变操作（邮件、银行等）调用外部依赖时这是必须的，这个技术在升级新数据库是非常有用，使用影子流量来监控负载下的系统性能。

下表可以帮助你选择正确的策略：

取决于云服务提供商和平台，如下文档是理解部署的很好开始：

Amazon Web Services[2]
Docker Swarm[3]
Google Cloud[4]
Kubernetes[5]

我希望这是有用的，如果有任何问题或者反馈，可以在下面评论。