79,539
社区成员




发布更频繁的软件更新使得部署的代码更有可能包含对站点可靠性产生负面影响并损害客户满意度的错误。幸运的是,有一些策略可以 最大限度地减少生产中的故障。自动化和全面的测试在生产前阶段必不可少,但在将新代码发布到生产中的实时流量中时,受控的部署策略至关重要。
本文讨论了现代 部署和发布模型 ,以及现代负载均衡器和应用程序交付平台对支持这些流程的重要性。
大爆炸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,因为如果出现问题,一半的用户会有糟糕的体验。
顺便说一句,让我们谈谈 A/B 测试。虽然 A/B 测试与蓝绿测试和金丝雀测试有许多相似之处,但它在几个方面有所不同。这也是拆分测试的一种形式,但 重点是在 引入新版本时进行试验而不是减少错误。
A/B 测试技术涉及测试变量的两个或多个变体。A 变体是“对照”,B 变体是“变体”或测试变量的新版本。测试的变量可以是网页布局、新组件等,并同时呈现给不同的访问者细分,以查看哪个版本具有最显着的影响并推动业务指标和用户满意度。
A/B 测试和部署发布方法之间的另一个区别 是假设测试变体运行正确,重点是哪个变体性能最好,而不是“它会崩溃吗?”。因此, 您可以将应用程序的两个版本分发给所有用户。它可能是 50-50 的拆分、80-20 的拆分或介于两者之间的任何方式。
A/B 测试消除了网站优化的不确定性,并允许企业根据数据支持的洞察力进行功能发布。可能关注的指标包括:
负载均衡器对于新应用程序代码和现有应用程序代码之间的流量拆分是必要的。然而,专注于可用性和路由到正确目的地的普通旧负载平衡在控制流量分配和实时监控方面未能真正减少蓝绿和金丝雀部署中的错误。
如果您愿意,需要智能负载均衡器或应用交付控制器 (ADC) 才能完美执行实时部署,不仅是分发请求,而且根据客户端、网络和环境提供的各种信息来引导请求他们正在经营的地方。
以下是使用 Snapt 等现代应用程序交付平台来确保完美的现代部署策略的一些优势。
无论您希望为下一个应用程序代码版本采用何种部署策略,这种负载平衡用例都需要一个高级应用程序交付平台。在 DevOps 方法中更是如此,在这种方法中,频繁发布并且失败是不可避免的,但却是有计划的。
现代应用程序团队需要一个自助服务、API 驱动的平台,该平台可以无缝集成到 CI/CD 管道中,以加快和安全地切换新的应用程序代码,无论您的应用程序是混合应用程序还是微服务。
有关 Snapt 的现代应用程序负载平衡和安全解决方案的更多信息, 请查看 Snapt Nova 并申请免费试用。
来源:https://www.cncf.io/blog/2022/05/09/load-balancing-for-blue-green-rolling-and-canary-deployment/