蓝绿Blue-Green、滚动Rolling Release和金丝雀Canary部署的负载平衡

[喝茶的DBA]

发布更频繁的软件更新使得部署的代码更有可能包含对站点可靠性产生负面影响并损害客户满意度的错误。幸运的是，有一些策略可以 最大限度地减少生产中的故障。自动化和全面的测试在生产前阶段必不可少，但在将新代码发布到生产中的实时流量中时，受控的部署策略至关重要。

本文讨论了现代 部署和发布模型 ，以及现代负载均衡器和应用程序交付平台对支持这些流程的重要性。

部署模型摘要

 

	大爆炸Big Bang	蓝绿色Blue-Green	滚动释放Rolling Release	金丝雀Canary
描述	一次性完成升级以代替现有代码。	新代码与现有代码一起发布，然后流量切换到新版本。	新代码以增量方式发布。随着新代码的接管，旧代码将被淘汰。	新代码在特定条件下发布给一部分实时用户，然后逐步推出。
最适合	没有冗余可用的设备。单片代码库与底层专有硬件紧密耦合。在维护窗口期间的离线服务是可以接受的。	双资源容量不是问题。实时用户测试并不重要。无状态应用程序的挑战更少。即时回滚能力。首选快速推出。	方便有状态的应用程序。部署在容器或云平台上的应用程序可以轻松编排。	缓慢推出首选。实时用户测试必不可少。部署在容器或云平台上的应用程序可以轻松编排。
零停机时间	不	是的	是的	是的
实时用户测试	不	不	是的	是的
用户对故障的影响	高的	中等的	低的	低的
基础设施成本	低的	高的	低的	低的
回滚持续时间影响	高的	低的	低的	低的

频繁发布很重要

DevOps 实践和现代应用程序基础设施使延迟和扩展发布周期成为过去。 云原生 技术和 微服务 架构使这变得更容易；开发人员可以创建一个 模块化代码库 ，允许开发团队编写新代码并独立发布，而不会影响系统的其他部分。

更短的部署周期的优势是很多的。简而言之：

• 加快上市时间： 在竞争之前推出新功能。
• 满意的客户： 客户反馈得到更快实施并推动持续改进。
• 提高开发人员的士气： 较小的可实现目标和总体满意度。

无需停机即可部署

大多数企业，尤其是那些拥有 DevOps 文化和已建立 CI/CD 管道的企业的目标是在 不影响用户体验的情况下部署新功能和增强功能。您必须能够快速、安全地将更改部署到活动的生产环境中，而不会中断在您的应用程序上参与关键活动的用户。

可以通过使用滚动版本在生产中进行测试来实现无需停机部署新版本  ，包括金丝雀和蓝绿部署方法。通常，您的环境应满足以下要求才能执行此操作：

•  可以创建、测试和部署到特定环境（测试、暂存、生产）的部署管道。
• 一个无状态的应用程序，使集群中的任何节点都可以随时服务请求。
•  将请求路由到服务器节点（例如，虚拟机或容器）的高可用性集群的负载平衡器。

让我们深入探讨部署策略，但首先让我们重温经典的“大爆炸”部署方法。

“大爆炸”部署

“大爆炸”更新或升级是一种一次性升级应用程序的全部或主要组件的方法。这种方法可以追溯到所有软件通常在物理介质上提供并由用户安装的时候。

大爆炸部署是 高风险 的，因此需要大量的开发和测试，通常与“瀑布模型”相关联。从理论上讲，这很简单：您编写和测试代码，然后在准备好后立即发布所有代码。

Big Bang 版本仍然存在，主要用于供应商打包的解决方案，如桌面应用程序或专用设备。对于 Web 应用程序，这种情况不太常见，因为它需要一个较长时间的维护窗口——对于大多数电子商务商店来说，“仅仅几个小时”就关闭是不可想象的。

以下是 Big Bang 部署的一些特性：

• 具有紧密耦合软件子系统的大型单体代码库
• 广泛的开发和测试周期
• 一个密集的升级过程，包括计划、维护窗口和大量的工时——即压力！
• 大量升级是新功能的重要积累，通常需要用户入职
• 假设更改是不可逆的或回滚是不切实际的，假设失败的概率很低。

当涉及到在线应用程序时，应该避免使用 Big Bang 版本。对于面向公众或关键商业的应用程序来说，危险太大了，因为中断和性能问题将产生直接和负面的财务影响。同样，从补救的角度来看，回滚通常是耗时、有风险且难以执行的。

即使有最好的意图和强大的自动化测试套件，一旦新版本发布，特定更改总是有可能产生极端情况错误、性能问题或不可预见的后果。

考虑到这一点，让我们深入研究克服“大爆炸”失败风险的更现代的部署策略。

蓝绿部署

发布新应用程序代码的一种故障安全方法是使用蓝绿部署。在这种方法中， 两个生产环境协同运行。蓝色代表现有的“旧”代码，而绿色代表“新”代码。

Blue 和 Green 都在 Production 中运行，但 最初只有 Blue 接收公共流量。

新的应用程序代码部署在绿色环境中，这是一个没有任何用户的复制生产环境。 Green 在实际生产就绪环境中针对功能、性能和关键健康指标进行了全面测试（集成、端到端、基准测试等）。

当我们对新版本感到满意时，我们可能会将 所有流量从蓝色环境路由到绿色环境。我们可以优雅地做到这一点，方法是从 Blue 耗尽已完成的会话并在 Green 上增加新会话，直到 Green 环境处理所有流量。

蓝绿色是有利的，因为它可以让您在 出现问题时快速恢复。作为灾难​​恢复计划的一部分，我们可以通过将一个环境视为热紧急备份来“回滚”并将流量路由反向回 Blue 环境。

此外，Blue 环境可用作下一次部署的 暂存环境 。蓝色和绿色环境可以在实时版本和以前版本之间循环（用于回滚），然后发布下一个版本。然而，今天更常见的是，由于基础设施不可变和基础设施即代码的能力，以前的环境可能会被逐步淘汰，它们的基础设施会完全释放。对于新的部署，新的虚拟机或容器会从头开始配置新的代码库，以用于下一轮部署。

这种技术最显着的优点是 没有停机时间，因为切换几乎是瞬时的（这实际上是理想的）。由于没有停机时间，用户不会注意到他们的请求何时由新环境提供服务。不幸的是，这可能会同时造成困难——如果我们进行突然切换，所有当前事务和会话都将丢失，以最大限度地减少与用户会话相关的错误。

为避免这种情况，您可以 使用负载均衡器 优雅地耗尽蓝色环境中的现有连接，并增加到新绿色环境的流量。

蓝绿部署的优点

•  由于我们在类似生产的暂存环境中测试新代码库，因此将有缺陷的功能暴露给公共流量的风险很低。
• 回滚很容易 ，因为我们有一套完整的生产环境。
•  与其他部署策略相比，部署快速且直接。

蓝绿部署的缺点

• 管理/维护两个生产环境的工作量和成本很高。
• 回滚决策需要实时分析和洞察力。
• 混合云部署并不总是有利于“微服务”式部署。如果您有微服务应用程序和传统单体应用程序的组合，则在两者之间进行协调以进行蓝绿部署可能仍会导致停机。
• 蓝色环境中的长期事务使切换到绿色环境变得困难，因为您必须等待优雅地关闭进行中的事务。
• 数据库管理可能很复杂，因为这两个环境应该同时运行（即使它们没有接收任何流量）。
• 很难向一小部分现场用户测试实验性功能。

滚动部署或分阶段部署 

与“大爆炸”版本或纯蓝绿部署方法相比，滚动和分阶段部署更适合在线 Web 应用程序。它降低了相关风险，例如面向用户的停机时间而无需轻松回滚。在滚动部署中， 应用程序的新版本逐渐取代旧版本。实际部署会随着时间的推移而发生，新版本和现有版本共存而不影响功能或用户体验。

在滚动部署策略中，您 首先部署一个包含更新软件的附加节点。例如，这可能是一个新的 Web 应用程序服务器实例，其中包含新用户界面或新产品功能的代码。需要负载均衡器代理对应用程序的请求，才能将流量路由到新节点。 随着时间的推移，您会在更多节点上部署新版本。 实际上，您可以让最新版本的应用程序与旧版本一起运行，直到新节点逐步淘汰具有最新版本的旧代码的所有实例。 

滚动和分阶段部署方法假定逐步和增量地替换实例（例如，Web 服务器节点）。 它们更易于使用现代应用程序基础架构实现， 因为自动缩放和滚动部署编排通常内置于平台中。例如，Kubernetes 等容器编排平台将处理容器的滚动更新。此外，现代应用程序通常由可以独立部署的多个组件或微服务组成，因此可以独立于其他微服务发布微服务，从而进一步隔离整个应用程序中遇到的潜在问题。 

您应该具有实时监控功能来跟踪最近添加的节点的运行状况，以帮助做出回滚决策。在出现错误的情况下， 您可以决定是继续滚动发布还是 将新代码部署的实例回滚到最后一个已知的工作代码库——这与“金丝雀”部署所需的粒度控制水平相当，我们会看到下一个。

金丝雀部署

金丝雀部署和滚动部署一样，是一种逐步发布新代码的技术。与向有限数量的节点发布新代码的滚动部署不同，金丝雀部署通过在 将新代码 发布到整个基础设施并提供给所有人之前逐步向部分用户发布新代码来控制风险。这减少了任何潜在的负面影响。

获得新代码的用户子集以煤矿中的金丝雀命名为“金丝雀”  。Canary 受到密切监控，并提供新代码运行状况的指标。这为决定是否回滚或向所有人发布新代码提供信息。通过 Canary 部署，我们可以隔离关键指标，例如新版本的错误、延迟和有趣的用户反馈。

没有具体的流量划分公式，但您通常可以预期 Canary 版本会将 5% 到 20% 的流量分配给新的“Canary”版本。Canary 部署永远不会将流量分成 50-50，因为如果出现问题，一半的用户会有糟糕的体验。 

Canary 部署的优点

• 微服务可以实时独立更新 ，并在全面推出之前监控实时生产中的性能一致性。
•  每天处理数十万用户的平台或服务（游戏、银行、电子商务、社交媒体等）的风险最小，错误升级可能导致重大财务损失。
• 对动态客户端流量的“真实世界”测试 是最好的测试，并且仅在实时生产服务器上可行。

金丝雀部署的缺点

• 传统的基础设施是静态的，并且会产生维护两个生产环境的费用。
• 回滚决策需要实时分析和洞察力。
• 数据库管理可能很复杂，因为这两个环境应该同时运行（即使它们没有接收任何流量）。

A/B 测试呢？

顺便说一句，让我们谈谈 A/B 测试。虽然 A/B 测试与蓝绿测试和金丝雀测试有许多相似之处，但它在几个方面有所不同。这也是拆分测试的一种形式，但 重点是在 引入新版本时进行试验而不是减少错误。

A/B 测试技术涉及测试变量的两个或多个变体。A 变体是“对照”，B 变体是“变体”或测试变量的新版本。测试的变量可以是网页布局、新组件等，并同时呈现给不同的访问者细分，以查看哪个版本具有最显着的影响并推动业务指标和用户满意度。

A/B 测试和部署发布方法之间的另一个区别 是假设测试变体运行正确，重点是哪个变体性能最好，而不是“它会崩溃吗？”。因此， 您可以将应用程序的两个版本分发给所有用户。它可能是 50-50 的拆分、80-20 的拆分或介于两者之间的任何方式。

A/B 测试消除了网站优化的不确定性，并允许企业根据数据支持的洞察力进行功能发布。可能关注的指标包括：

• 销售转化，例如购物车结账与放弃的比率
• 操作后评级系统，例如“使用 5 星评价易用性？”
• 平均会话时间和跳出率
• 广告点击率
• 注册 

现代部署策略的先决条件

负载均衡器对于新应用程序代码和现有应用程序代码之间的流量拆分是必要的。然而，专注于可用性和路由到正确目的地的普通旧负载平衡在控制流量分配和实时监控方面未能真正减少蓝绿和金丝雀部署中的错误。

如果您愿意，需要智能负载均衡器或应用交付控制器 (ADC) 才能完美执行实时部署，不仅是分发请求，而且根据客户端、网络和环境提供的各种信息来引导请求他们正在经营的地方。

以下是使用 Snapt 等现代应用程序交付平台来确保完美的现代部署策略的一些优势。

• 第 7 层智能： 根据客户端属性拆分流量——客户端标识符（名称、忠诚度状态）、会话 ID、设备类型、地理位置等。
• 会话持久性： 首先，做出路由决策，然后会话持久性确保用户不会在新旧应用程序版本（蓝色和绿色）之间反弹。
• 连接耗尽： 从托管旧应用程序代码的现有节点“耗尽”客户端连接的能力，在允许节点正常关闭之前完成所有会话。同时，新节点接管更多流量并开始处理集群中的所有客户端请求。
• 细粒度控制： 即时控制流量分配，增加或减少对新代码的路由，或在切换开关或 API 调用时回滚。
• 实时监控和洞察： 比较 Canary 和基线数据以获得精确的指标，例如延迟、错误率、平均负载和成功请求。
• 全球服务器负载平衡 (GSLB)： 提供在全球范围内扩展部署、在蓝绿之间分配 Internet 流量以及使用 Canary 部署推出新数据中心的能力。
• 云和平台无关： 使用云和容器平台更容易实现滚动和分阶段部署，但大多数组织仍然维护单一应用程序。要在传统和现代应用程序之间拆分流量或迁移，请调用与平台无关的负载均衡器作为混合部署的外观。
• 可编程性和 API： 组织通过采用基础架构即代码方法来获得 DevOps 速度，从而获得通过版本控制和 CI/CD 等软件工程方法管理基础架构的能力。负载均衡器对现代基础设施平台也不例外。它们应该无缝集成到 API 驱动的云架构中，允许开发人员和系统管理员以编程方式和大规模地与基础设施交互，而不是手动配置资源。 

结论

无论您希望为下一个应用程序代码版本采用何种部署策略，这种负载平衡用例都需要一个高级应用程序交付平台。在 DevOps 方法中更是如此，在这种方法中，频繁发布并且失败是不可避免的，但却是有计划的。

现代应用程序团队需要一个自助服务、API 驱动的平台，该平台可以无缝集成到 CI/CD 管道中，以加快和安全地切换新的应用程序代码，无论您的应用程序是混合应用程序还是微服务。

有关 Snapt 的现代应用程序负载平衡和安全解决方案的更多信息， 请查看 Snapt Nova 并申请免费试用。

 

来源：https://www.cncf.io/blog/2022/05/09/load-balancing-for-blue-green-rolling-and-canary-deployment/