金丝雀部署部署策略简介：蓝绿部署、金丝雀部署等

如今，软件开发最大的变化是部署频率。产品团队可以更早（也更频繁地）将版本部署到生产环境中。长达数月甚至数年的发布周期正变得越来越少见，尤其是在构建纯软件产品的团队中。

如今，使用面向服务的架构和微服务方法，开发人员可以将代码库设计成模块化的。这使得他们能够同时编写和部署对代码库不同部分的更改。

缩短部署周期的业务优势显而易见：

• 上市时间缩短
• 客户在更短的时间内获得产品价值
• 客户反馈也能更快地反馈给产品团队，这意味着团队可以更快地迭代功能并解决问题
• 总体开发人员士气上升

然而，这种转变也给运营或 DevOps 团队带来了新的挑战。随着部署频率的提高，已部署的代码更有可能对网站可靠性或客户体验产生负面影响。因此，制定代码部署策略以最大程度地降低产品和客户风险至关重要。

在本文中，我们将讨论一些不同的部署策略、最佳实践和工具，以使您的团队能够更快、更可靠地工作。

现代应用的挑战

现代应用程序通常是分布式且基于云的。它们可以弹性扩展以满足需求，并且由于高可用性架构，它们能够更好地应对故障。它们可能会使用AWS Lambda或弹性容器服务 (ECS)等完全托管的服务，由平台承担部分运维职责。

这些应用程序几乎总是需要频繁部署。例如，一个移动应用程序或面向消费者的 Web 应用程序可能在一个月内发生多次更改。有些应用程序甚至一天部署到生产环境多次。

他们通常使用微服务架构，其中多个组件协同工作以提供完整的功能。不同组件可以有不同的发布周期，但它们必须无缝协作。

活动部件数量的增加意味着出错的可能性更大。由于多个开发团队对整个代码库进行更改，当问题不可避免地发生时，很难确定问题的根本原因。

另一个挑战是：基础设施层的抽象，现在被视为代码。部署新的应用程序可能也需要部署新的基础设施代码。

流行的部署策略

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

我们将回顾几种不同的部署策略并讨论其优缺点，以便您可以选择最适合您组织的策略。

“大爆炸”部署

顾名思义，“大爆炸”部署会一次性更新应用程序的全部或大部分内容。这种策略可以追溯到软件以物理介质形式发布并由客户安装的时代。

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

现代应用程序的优势在于能够在客户端或服务器端定期自动更新。这使得“大爆炸”方法对于现代团队来说速度更慢，敏捷性也更低。

大爆炸部署的特点包括：

• 所有主要部件均打包在一次部署中；

• 用新版本大量或完全替换现有软件版本；

• 部署通常会导致漫长的开发和测试周期；

• 假设失败的可能性很小，因为回滚可能是不可能或不切实际的；

• 完成时间通常很长，需要多个团队的努力；

• 要求客户端采取行动来更新客户端安装。

大爆炸式部署并不适合现代应用程序，因为对于面向公众或业务关键的应用程序来说，这种风险是不可接受的，因为一旦发生中断，就意味着巨大的财务损失。回滚通常成本高昂、耗时，甚至无法实现。

大爆炸方法适用于非生产系统（例如，重新创建开发环境）或桌面应用程序等供应商打包的解决方案。

滚动部署

滚动、分阶段或步骤部署比大爆炸部署更好，因为它们最大限度地减少了许多相关风险，包括用户面临的停机时间而无法轻松回滚。

在滚动部署中，应用程序的新版本会逐渐替换旧版本。实际部署过程需要一段时间。在此期间，新旧版本将共存，而不会影响功能或用户体验。此过程使回滚任何与旧组件不兼容的新组件变得更加容易。

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

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

蓝绿、红黑或 A/B 部署

这是另一个故障安全流程。在此方法中，两个相同的生产环境并行工作。

一个是当前正在运行的生产环境，接收所有用户流量（蓝色表示）。另一个是其克隆版本，但处于空闲状态（绿色表示）。两者使用相同的数据库后端和应用程序配置：

新版本的应用程序部署在绿色环境中，并进行功能和性能测试。测试结果合格后，应用程序流量将从蓝色环境路由到绿色环境。绿色环境随后成为新的生产环境。

如果绿色通道变为可用状态后出现问题，流量可以路由回蓝色通道。

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

您可以使用蓝色数据库的主数据库进行写入操作，并使用绿色数据库的辅助数据库进行读取操作。在从蓝色数据库切换到绿色数据库的过程中，数据库会从主数据库故障转移到辅助数据库。如果绿色数据库在测试期间也需要写入数据，则可以将数据库设置为双向复制。

绿色实例上线后，您可以关闭或回收旧的蓝色实例。您可以在这些实例上部署新版本，并将其作为下一个版本的新绿色实例。

蓝绿部署依赖于流量路由。这可以通过更新主机的 DNS CNAME 来实现。但是，较长的 TTL 值可能会延迟这些更改。或者，您可以更改负载均衡器设置，使更改立即生效。ELB 中的连接耗尽等功能可用于服务正在运行的连接。

金丝雀部署

金丝雀部署类似于蓝绿部署，但它更倾向于规避风险。它不是一次性从蓝部署切换到绿部署，而是采用分阶段的方法。

使用金丝雀部署，您可以在生产基础架构的一小部分区域部署新的应用程序代码。一旦应用程序获得发布批准，只有少数用户会被引导到该应用程序。这最大限度地减少了影响。

如果没有错误报告，新版本可以逐步推广到其余基础设施。下图演示了金丝雀部署：

金丝雀部署的主要挑战在于设计一种方法，将部分用户引导至新的应用。此外，有些应用可能始终需要同一组用户进行测试，而有些应用可能每次都需要不同的用户组。

考虑通过探索几种技术来引导新用户：

• 在允许外部用户访问之前，先将内部用户暴露给金丝雀部署；

• 根据源 IP 范围进行路由；

• 在特定地理区域发布应用程序；

• 使用应用程序逻辑为特定用户和群组解锁新功能。当应用程序向其他用户上线时，此逻辑将被删除。

部署最佳实践

现代应用程序团队可以遵循一些最佳实践，将部署风险降至最低：

• 使用部署清单。例如，清单上的一项可能是“仅在应用服务停止后备份所有数据库”，以防止数据损坏。

• 采用持续集成 (CI)。CI确保签入代码库功能分支的代码只有在经过一系列依赖项检查、单元测试和集成测试以及成功构建后，才会与主分支合并。如果构建过程中出现错误，构建将失败，并通知应用团队。因此，使用 CI 意味着应用程序的每项更改在部署之前都会经过测试。CI 工具示例包括：CircleCI、Jenkins。

• 采用持续交付 (CD)。使用持续交付 (CD)，CI 构建的代码工件将被打包，并随时准备在一个或多个环境中部署。阅读我们的低风险持续交付电子书了解更多信息。

• 使用标准操作环境 (SOE)来确保环境一致性。您可以使用 Vagrant 和 Packer 等工具来构建开发工作站和服务器。

• 使用构建自动化工具来自动化环境构建。使用这些工具，通常只需单击按钮即可轻松拆除整个基础架构堆栈并从头开始重建。CloudFormation 就是此类工具的一个例子。

• 在目标服务器中使用 Puppet、Chef 或 Ansible 等配置管理工具自动应用操作系统设置、应用补丁或安装软件

• 使用 Slack 等通信渠道自动通知构建失败和应用程序故障

• 创建一个流程，用于在部署失败时向负责的团队发出警报。理想情况下，你会在持续集成 (CI) 环境中捕获这些错误，但如果更改已部署，则需要一种方式来通知负责的团队

• 对于由于可用性或错误率问题导致的运行状况检查失败的部署，启用自动回滚。

部署后监控

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

应用程序性能监控 (APM) 工具可以帮助您的团队监控关键性能指标，包括部署后的服务器响应时间。应用程序或系统架构的变化可能会显著影响应用程序性能。

像Rollbar这样的错误监控解决方案同样重要。它会迅速通知您的团队部署中出现的新错误或重新激活的错误，从而发现需要立即关注的重要错误。

如果没有错误监控工具，这些错误可能永远都不会被发现。虽然少数遇到错误的用户会花时间报告，但大多数用户不会。负面的客户体验会随着时间的推移导致满意度问题，甚至更糟的是，导致业务交易无法进行。

错误监控工具还能在运维/DevOps团队和开发人员之间建立对所有部署后问题的共享可见性。这种共享理解使团队能够更好地协作并提高响应速度。

最初发表于rollbar.com