部署策略对比：蓝绿部署、金丝雀发布及其他

目前，软件开发最大的变化是部署频率。产品团队更早（更频繁）的将产品发布到生产环境。数月或者数年的发布周期变得越来越短-对那些构建纯软件产品的人来说更是如此。

现在，使用面向服务的架构和微服务方式，开发者可以设计模块化的代码库。这允许他们同时在代码库中不同的地方编写和部署代变更。

缩短部署周期的业务优势狠明显：

\n
缩短上市时间\n
客户可以在更短的时间内获得产品价值\n
客户的反馈也会更快的到达产品团队，这意味着团队可以更快的迭代特性和修复问题\n
开发人员的整体士气会上升\n

但是，这种转变也给运维或者DevOps 团队带来了新挑战。更频繁的部署，意味着已经部署的代码会对站点可用性和客户体验带来负面影响。这就是制定代码部署策略如此重要的原因，因为它可以最大限度的降低产品和客户的风险。

在本文中，我们将讨论不同的部署策略、最佳实践和工具，让你的团队可以更快更可靠的工作。

现代应用的挑战

现代应用通常是分布式的，基于云的。它们可以弹性扩展来满足需求，基于高可用架构更好地容错。这些应用可以使用全托管服务，例如AWS Lambda 和Elastic Container Service(ECS)等平台处理一些运维责任。

这些应用经常频繁部署。例如，移动app 和web 应用可能一个月内经历多次更改。有些甚至一天多次部署到生产环境。

它们通常采用微服务架构，多个组件一起工作来提供完整的功能。不同的组件可以有不同的发布周期，但它们全部无缝衔接在一起工作。

活动部分数量的增加，意味着出错的几率增大。随着多个开发团队对代码库的修改，当问题发生时，很难定位到问题的根因是什么。

另一个挑战是基础设施层的抽象，它们现在已经被当作代码了。在部署新应用的时候，可能还需要部署新的基础设施代码。

常见部署策略

为了应对这些挑战，应用和基础设施团队应该设计和采用适合他们用例的部署策略。

这里我们将回顾和讨论不同部署策略的优缺点，以便你可以选择合适的。

“大爆炸“部署

顾名思义，“大爆炸”部署一次性更新整个应用或者其中的大部分。这个策略可以回溯到软件在物理介质上发布并由客户安装的时代。

大爆炸部署要求企业在发布之前进行广泛的开发和测试，通常和大型有序发布的“瀑布模型”有关。

现代应用不管是在客户端还是服务端，都有定期自动更新的优势。大爆炸的方式对于现代团队来说，太慢，而且不敏捷。

大爆炸部署的特点包括：

\n
所有的主要部件都打包在一个部署中；\n
用新的软件版本整个替换现有的版本，或者替换大部分；\n
部署通常会导致长时间的开发和测试周期；\n
假定失败的可能性很小，因为回滚是不可能和不现实的；\n
完成时间通常需要很久，需要多个团队的共同努力；\n
需要客户采取措施来更新客户端安装。\n

大爆炸部署不适用于现代应用，因为面向公众的或者是关键业务应用无法接受这种风险，一旦中断就意味着巨大的经济损失。回滚通常耗时且代价巨大，甚至是不可能的。

大爆炸的方式适合非生产环境系统（例如，重新创建开发环境），或者是类似桌面应用这种供应商打包的解决方案。

滚动部署

滚动、阶段性，或者是分步部署比大爆炸部署更好一些，因为它们可以最大限度的降低相关风险，包括面向用户的停机时间。

在滚动部署中，应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。

下图显示了该部署模式：旧版本显示为蓝色，新版本显示为绿色，它们部署在集群中的每一台服务器上。

应用程序套件升级是一个滚动部署的典型例子。如果原始应用部署在容器中，升级可以一次处理一个容器。修改每个容器从应用供应商的站点上下载最新的镜像。如果其中的一个应用存在兼容性问题，旧的镜像可以重新创建这个容器。在这种情况下，套件的新旧版本应用可以共存，直到每个应用都更新完毕。

蓝绿、红黑、A/B 部署

这是另一个能自动防御故障的流程。在这个方法中，两个相同的生产环境并行工作。

一个是当前运行的生产环境，接收所有的用户流量（称之为蓝）。另一个是它的副本，但是闲置（称之为绿）。两者使用相同的数据库后端和应用配置：

\n应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。

\n如果绿色版本激活后发现了问题，则将流量路由回到蓝色版本中。

在蓝绿部署中，两个系统使用相同的持久化层和数据库后端。保持应用的数据同步至关重要，镜像数据库可以帮助实现这一目标。

你可以使用蓝色版本作为主库进行写入操作，使用绿色版本作为备库进行读操作。在从蓝色版本切换到绿色版本时，数据库会从主库故障转移到备库。如果绿色版本在测试过程中需要写数据，数据库可以进行双向复制。

一旦绿色版本被激活，你可以关闭或者是回收旧的蓝色版本实例。你可以在这些实例上部署一个新版本，用作下次发布的新的绿色版本。

蓝绿部署依赖流量路由。这可以通过更新主机的DNS CNAMES 来完成。但是，TTL 太久会导致这些变更被延迟。或者，你可以改变负载均衡的配置，让变更立即生效。类似ELB 的连接特性可以用来提供无缝连接。

金丝雀部署

金丝雀部署和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。

采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。

如果没有错误发生，新版本可以逐渐推广到整个基础设施。下图示范了金丝雀部署：

金丝雀部署的主要挑战是设计一种路由部分用户到新应用的方法。此外，一些应用可能需要同类用户进行测试，另一些应用可能每次都需要不同类型的用户。

探索一些技术，来考虑路由新用户的方法：

\n
在允许外部用户访问之前，将内部用户暴露给金丝雀部署；\n
基于源IP 范围的路由；\n
在特定地理区域发布应用；\n
使用应用程序逻辑为特定用户和群体解锁新特性。当应用为其他用户上线后，移除此逻辑。\n

部署最佳实践

现代应用团队可以遵循一些最佳实践，来最大限度的降低部署风险：

\n
使用部署清单。例如，清单上可能有一项是“在确保停止应用服务后，备份所有数据库”，来防止数据损坏。\n
采用持续集成（CI）。CI 确保从代码仓库检入的特性分支代码，只会在经过一系列的依赖检查，单元和集成测试，并且成功构建后，才会合并到主干分支。如果过程中出现错误，构建就会失败，并通知应用团队。所以使用CI 意味着应用的每次变更在部署之前都会进行测试。常见的CI 工具包括：CircleCI，Jenkins。\n
采用持续交付（CD）。使用CD 打包CI 构建的代码产物，并随时准备部署到一个或多个环境中。更多内容可以看看我们的Low-Risk Continuous Delivery eBook。\n
使用标准操作环境（SOEs）来确保环境一致性。你可以使用类似Vagrant 和Packer 这样的工具来部署工作站和服务器。\n
使用自动化构建工具来自动化环境构建。使用这些工具，通常都是简单的点击一个按钮，来销毁整个基础设施栈并从头开始构建。CloudFormation 就是这种工具。\n
在目标服务器中使用类似Puppet、Chef和Ansible 这样的配置管理工具，来自动应用OS 设置、打补丁和安装软件。\n
使用Slack 这样的通信渠道来自动通知不成功的构建和应用故障。\n
创建一个程序，在部署失败的时候向负责的团队发送警告。理想情况下，你会在CI 环境中捕获这些内容，但是如果变更已经部署了，你将需要一种方法来通知负责的团队。\n
无论是因为可用性还是错误率问题，对健康检查失败的部署启用自动回滚。\n

部署后监控

即使你采用了所有的这些最佳实践，事情仍然可能会失败。因此，对部署后立即发生的问题进行监控，与规划和执行完美的部署同样重要。

应用性能监控（APM）工具可以帮助团队监控关键性能指标，包括部署后的服务器响应时长。应用和系统架构的变更会极大的影响应用性能。

类似Rollbar 这样的错误监控解决方案同样重要。它会迅速通知团队新部署或重新激活部署中的错误，这些部署可能会引发严重的bug，需要立即引起关注。

如果没有错误监控工具，这些bug 可能永远也不会被发现。虽然一些遇到bug 的用户会花时间反馈，但大多数其他用户不会这样做。随着时间推移，客户的负面体验会降低满意度，甚至更糟糕的是，阻碍正在进行的业务交易。

错误监控工具还可以在运维/DevOps 团队和开发者之间，共享所有部署后发生的问题。这些共享让团队变得更具有协作性，响应能力更强。

查看英文原文：Win-Win Deployment Strategies for Modern Apps