云端架构的弹性模式与权衡

关键要点

在云端架构中，需要评估多种因素以选择最优的架构。本文探讨了五种弹性模式及其实施中的权衡，包含设计复杂性、实施成本、运营努力、安全性及环境影响。这将帮助你在构建系统时实现不同层次的弹性。

这篇文章最初发布于2022年6月，并在2023年2月更新了有关在云中高效构架弹性模式的更多信息。

构架工作负载的弹性时，通常需要评估多个因素，以决定最优的架构。例如，样例公司拥有多个应用程序，具有不同的重要性。每个应用程序在弹性、复杂性和成本方面的需求各不相同。他们有很多选择来构架其工作负载以提高弹性和降低成本，但哪些选项最适合他们的需求？在选择与应用程序需求最匹配的模式时，他们该考虑哪些？

为了帮助解决这些问题，本文将讨论图1中的五种弹性模式及实施时需考虑的权衡：1设计复杂性，2实施成本，3运营努力，4安全性努力，以及5环境影响。这将有助于你实现不同层次的弹性，并在构建架构时做出最合适的决策。我们的目的是提供一个高层次的方法，以方便结构化关于这些模式所关联的权衡的讨论。关于每种模式的深入探讨，请导航到本文最后的进一步阅读部分。

注意：这些模式并非相互排斥，你可以选择实现一种或多种模式的组合。

什么是弹性？为什么重要？

AWS WellArchitected Framework 将弹性定义为“在受到负载更多服务请求、攻击无论是通过错误的意外攻击，还是有意的攻击或工作负载的任何组件失效时的恢复能力。”

为了满足你的业务弹性需求，设计工作负载时请考虑以下核心因素：

核心因素说明设计复杂性系统复杂性增加通常会导致系统的意外行为增加。每个工作负载组件都需要具备弹性，需要消除在人员、流程和技术元素中的单点故障。实施成本实施更高弹性时，成本通常会显著增加，因为需要操作新的软件和基础设施组件。重要的是，这些成本应该能够被未来损失的潜在成本抵消。运营努力部署和支持高弹性系统需要复杂的运营流程和高级技术技能。客户需要评估其运营能力，确认是否具备所需的流程成熟度和技能。安全性努力安全性复杂性与弹性之间关系不那么直接。然而，对于高度弹性的系统，通常需要保护更多组件。使用云部署的安全最佳实践可以在不增加复杂性的情况下实现安全目标。环境影响高弹性系统的增加部署可能会增加云资源的消耗。你可以使用权衡，例如近似计算，有意实施延迟响应来减少资源消耗。

模式1P1：多可用区MultiAZ

P1 是一种基于云的架构模式见图2，通过在架构中引入可用区AZ，以提升系统的弹性。P1模式使用多可用区架构，应用程序在单个AWS区域内的多个AZ中运行，从而使应用程序能够承受可用区级别的影响。

了解弹性模式和权衡，以便在云中高效架构架构博客

如图2所示，样例公司使用P1模式部署其内部员工应用程序。这些应用程序对业务影响较小，因此对弹性的要求较低。

样例公司将他们的低业务影响应用程序部署为一个由自动扩展组管理的单个亚马逊弹性计算云Amazon EC2实例。Amazon EC2 通过健康检查自动检测故障。如果某个AZ发生故障，Amazon EC2会提示Amazon EC2自动扩展组在另一个未受影响的AZ中重新创建应用程序。

权衡

P1在多个类别中较低，并能够减轻承载应用的AZ的中断，但这也牺牲了应用恢复的速度。如果某个AZ出现故障，用户在新的资源被重新配置到新的AZ的过程中，将无法访问应用程序。这种情况被称为双模行为。

模式2P2：多可用区与静态稳定性

P2利用在多个可用区中的多个实例提高弹性。该模式通过静态稳定性来防止双模行为。静态稳定的系统在操作环境变化时保持稳定并处于单一模式。AWS上静态稳定系统的一个主要好处是，它减少了在发生干扰时的恢复复杂性，因为预先配置的资源容量已经存在，AWS服务控制平面也不需要可用以成功恢复。有关静态稳定性、数据平面和控制平面的详细信息，请阅读构建者库文章利用可用区实现静态稳定性。

如图3所示，样例公司拥有一个面向客户的网站，容忍度低。如果网站宕机，就可能导致收入损失。因此，该网站需要在两个AZ中部署的两个EC2实例。通过健康检查，当某个AZ出现障碍时，网站将继续运行，因为弹性负载均衡器会将流量转移至未受影响的AZ。有关健康检查的更多信息，请参阅实现健康检查文章。

权衡

P2能够在不影响应用客户的情况下减轻AZ的中断，但必须与成本考虑权衡。P1在基础设施成本方面较低，因为它配置的计算容量较少，并依赖于在故障情况下启动新实例。然而，P1的双模行为可能影响在大规模事件中的客户。

实施P2需要你的应用程序支持跨多个实例的分布式操作。如果你的应用程序能够支持这一模式，你可以将工作负载部署到区域内所有可用的AZ中通常为3个或更多。这将减少与过度配置相关的成本，因为你只需在三个AZ中配置150的容量，而不是在两个AZ中配置200。

模式3P3：应用程序组合分布

P3采用多区域模式以提高功能弹性，见图4。它将不同关键应用分布在多个区域中。

样例公司通过多个数字渠道向消费者提供银行服务，例如信用余额查询。这些服务通过移动应用程序、呼叫中心和基于网络的应用程序提供给消费者。每个数字渠道都会在不同的区域中部署，从而规避区域服务中断的风险。

例如，某个地区的客户移动应用程序可能会发生中断，导致移动应用无法使用，但客户仍可以通过在另一个区域中部署的在线银行访问银行服务。虽然区域服务中断很少发生，但实施这种模式可确保用户在中断过程中继续访问关键业务服务。

权衡

P3降低了区域服务中断同时影响多种系统的可能性。然而，运营一个跨多个区域的应用程序组合需要显著的运营计划和管理。隔离的功能元素可能依赖于已在单一地区部署的公共下游系统和数据源。因此，区域范围的事件可能仍会造成中断，但影响的面应该减少。

模式4P4：多可用区域部署多区域灾难恢复

样例公司运营几个业务关键服务，这些服务对中断的容忍度非常低，例如消费者进行银行支付。样例公司审查了AWS上工作负载的灾难恢复：云中的恢复中定义的四种常见灾难恢复模式，决定对其多区域应用使用以下子模式：

启动灯Pilot Light 该模式适用于需要10分钟的恢复时间目标/恢复点目标RTO/RPO的应用程序。数据被主动复制，应用程序基础设施在灾难恢复区域预先配置。成本优化是这里的关键驱动因素，因为应用程序基础设施保持关闭状态，只在恢复事件期间开启。温备份Warm Standby 该模式与启动灯模式相比显著提高了恢复时间，因为它在灾难恢复区域保持应用程序的运行，但容量较低。在发生灾难恢复事件时，应用程序基础设施将扩展，但这通常可以通过最小的手动工作自动化实现。如果正确实施，该模式可以实现以分钟级为单位的RTO/RPO。