依托亚马逊云科技构建韧性应用

背景

现代业务系统受到越来越多的韧性相关的挑战，特别是客户要求他们的业务系统 7×24 不间断的运行。因此，韧性对于云的基础设施和应用系统有着至关重要的作用。

亚马逊云科技把韧性视为一项最基本的工作，为了让我们的业务系统能持续优雅地提供服务，从各种故障和灾难中迅速恢复，亚马逊云科技不仅提供了全球高可用的基础设施，也提供了构建韧性系统的最佳实践和方法。

可靠性是工作负载按预期正确且一致地执行其预期功能的能力，为了实现这一目标，必须构建韧性架构。韧性是工作负载从基础设施、服务或应用程序中断中恢复、动态获取计算资源以满足需求以及减轻中断（例如配置错误或短暂的网络问题）的能力。

亚马逊云科技高可靠揭秘

亚马逊云科技韧性的技术实现

分区、区域和可用区隔离机制

分区

第一层隔离机制叫分区。每个分区是一组不同的区域，其中每个区域都位于一个分区中，并且大多数分区都有多个区域。亚马逊云科技总共包含三个分区：商业（海外）分区、中国分区和美国政府分区。每个分区包含账户、数据和资源，每个分区都有自己独立的 IAM 用户，您无法使用一个分区中的 IAM 凭证与另一分区中的资源进行交互。另外，某些云服务提供跨区域功能，例如 Amazon S3 跨区域复制或 Amazon Transit Gateway 区域间对等连接，这些类型的功能仅在同一分区中的区域之间受支持。

区域和可用区

截止到 2023 年 12 月，亚马逊云科技的服务横跨全球 32 个地理区域。每个区域由同一地理区域内多个物理上独立的可用区组成。所有区域目前都有 3 个以上的可用区。每个区域都是独立于其他区域，区域之间的这种隔离机制确保单个区域发生服务故障时，其他区域的能正常运营，不受影响。32 个区域共有 102 个可用区，区域中的每个可用区彼此相隔几十公里到 100 公里，这样既能防止关联故障，又能实现数据的同步复制。可用区的这种隔离机制，确保它们不会同时受到公用电力或水中断、光纤中断、地震、火灾、龙卷风或洪水的影响。每个可用区都是由一个或多个独立的数据中心组成，具有独立且冗余的电力基础设施和网络连接。亚马逊云科技拥的区域和可用区模型已得到认可，并被 Gartner 列为运行高可用企业应用程序的推荐方法。

控制平面和数据平面隔离

亚马逊云科技服务分为控制平面和数据平面两部分。控制平面提供用于创建、读取/描述、更新、删除和列出（CRUDL）资源的管理 API，例如，启动新的 Amazon EC2 实例、创建 Amazon S3 存储桶以及描述 Amazon SQS 队列。数据平面是提供服务的主要功能。例如，正在运行的 EC2 实例本身、读取和写入 EBS 卷、在 S3 存储桶中获取和放置对象，以及回答 DNS 查询和执行运行状况检查的 Route 53。

控制平面往往是复杂的协调和聚合系统。当您启动 EC2 实例时，控制平面必须执行多项任务，例如查找具有容量的物理主机、分配网络接口、准备 Amazon EBS卷、生成 IAM 证书、添加安全组规则等。与控制平面相比，数据平面没有那么复杂，从统计学上讲，数据平面中发生故障事件的可能性较小。尽管数据平面和控制平面都有助于服务的整体运行和成功，但我们将它们视为不同的组件，即控制平面和数据平面是独立设计的，这种隔离既有性能方面的好处，又有可用性方面的好处。

亚马逊云科技提供的三种服务类型

根据区域和可用区的隔离机制以及控制平面和数据平面分离的原则，亚马逊云科技提供三种服务类型：全局（Global）服务、区域级（Region）服务、可用区级（AZ）服务。

全局（Global）服务

全局服务的控制平面和数据平面不是在每个区域中独立存在的，由于它们的资源不属于特定于区域的，因此将其称为全局服务。全局服务遵循传统的设计模式，即分离控制平面和数据平面，以实现静态稳定性，它们的控制平面托管在单个区域，而其数据平面是全球分布的。所谓静态稳定性，是指系统在依赖项故障或不可用期间，无需进行任何更改，在静态状态下继续正常运行。

让我们以 IAM 为例，以更深入地了解全球服务的架构。在下图中我们可以看到 IAM 的数据平面是独立存在于每个区域，该区域中的每个云服务都直接与 IAM 数据平面交互，以对它们收到的请求进行身份验证和授权。IAM 有独立的控制平面，您可以使用它来管理身份和策略等 IAM 资源，因此，当您调用 CreateRole 时，它会流经控制平面，控制平面还负责将这些更改传播到它们需要去的任何地方，在本例中是分区中的每个区域。当更改传播到数据平面后，数据平面将不再依赖控制平面而独立运行，实现静态稳定性。当 IAM 控制平面故障的情况下，无需任何更改，每个区域的身份验证和授权都可以继续正常运行。

区域级（Region）服务

区域级服务是建立在多个可用区域之上的服务，数据平面和控制平面都是区域级别。Amazon S3 、Amazon SQS 和 Amazon DynamoDB 是区域级服务的示例，它们利用可用区的独立性和冗余性来最大限度地减少基础设施故障带来的影响，例如，Amazon S3 将请求和数据分布在多个可用区之间，可以自动从可用区故障中恢复。客户可以通过使用区域服务实现其韧性目标，您只需要与区域终端节点进行交互。

可用区级（AZ）服务

可用区独立的特性使我们可以提供可用区级别的服务，例如 Amazon EC2 和 Amazon EBS，可用区服务可以指定将资源部署到哪个可用区。这些服务在一个区域内的每个可用区中独立运行，不依赖于其他可用区中的组件，之所以可以这样做是因为有可用区级别的数据平面。在某些情况下，例如 EC2，还提供了区域级控制平面端点，以便于与服务交互。您可以通过部署多可用区架构运行具有更高可用性、容错能力和可扩展性的生产级工作负载，当工作负载使用多个可用区架构时，可以更好地隔离和保护客户免受影响单个可用区物理基础设施问题的影响，如果架构正确，即使一个可用区出现故障，工作负载也能保持运行。

单元架构

单元架构是一种设计模式，该模式将服务切分为多个部署堆栈，每个部署堆栈称为“单元” ，每个单元之间都是互相独立的，不共享任何内容，包括数据库，每个单元服务一个或多个客户。

对于可用区级别的服务，如果没有单元架构，服务的爆炸半径是整个可用区，如果采用了单元架构，理论爆炸半径已从整个可用区减少到仅该可用区中的单元。对于区域级别的服务也是一样的道理，有了单元架构，服务的故障限制在单元内。因此，影响是 1/n，其中 n 是单元的数量，1/n 可能只占您支持的总客户的一小部分，实际上单元的数量远高于下图中显示的 3 个。

随机分片（Shuffle Sharding）

随机分片已成为一种核心设计模式，使我们可以提供具有高性价比的多租户服务，为每个客户提供单租户体验。随机分片简单而不失强大功能，它的强大远超我们最初的设想。我们以 Route 53 为例，说明随机分片的工作原理。

Route 53 是全局服务，其服务可用性至关重要，采用随机分片的方法保证其架构韧性。对于 Route 53，亚马逊将流量分配到 2048 个虚拟名称服务器中，这些服务器是虚拟的，每个客户域由四个虚拟名称服务器组成的分片承载，可能的分片组合达到 7300 亿个。因为我们有很多可能的随机分片，因此我们可以为每个客户域分配一个唯一的分片。实际上，我们可以更进一步，确保没有任何客户域与任何其他客户域共享两个以上的虚拟名称服务器。

亚马逊云科技韧性的运营实现

服务责任模型

我们采用服务责任模型，激励团队不断改进其运营。我们的工程和产品管理工作由小型多学科团队领导，他们对所提供的服务拥有强大的所有权。这种所有权不仅负责设计和启动服务，还负责在生产过程中运营服务，并在出现问题时随时待命。

运营准备情况审核

在启动之前，还需要使用运营准备审核（ORR）流程来审核所有新服务的运营准备情况。启动团队回答一系列有关韧性的问题以及其他已知的最佳实践，并使用标准化的运行手册来确保他们的服务符合标准。服务部署后，每周召开运营会议，检查系统的运营性能以及任何未解决的问题。

安全、持续部署

当对部署软件进行服务更新或推出新服务时，我们使用安全、持续的部署管道。通过使用广泛的预生产测试、自动回滚和交错生产部署，将自动化部署安全构建到发布过程中，使我们能够最大限度地减少错误部署对生产造成的潜在影响。例如，服务的更新从小处开始；该更新首先部署到可用区内的单个最小单元（OneBox 阶段），并经过指定的等待期以验证没有出现问题。从那里开始，更新将部署到整个可用区的其余部分，然后部署到其他可用区，然后部署到单个区域，最后部署到其余区域。

错误流程纠正：如果出现任何问题，我们会利用错误纠正（CoE）流程等事件管理机制来帮助我们的团队了解根本原因。问题得到缓解后，我们会推动全公司范围内的工程冲刺，以确保所有服务中的问题得到解决，从而减少未来类似事件影响其他服务的可能性。这些经验教训会被记录下来并成为运营准备情况审核（ORR）流程的一部分，从而确保类似的问题不会再次发生。

依托亚马逊云科技构建韧性应用

云上高可用系统

当我们考虑在亚马逊云科技上部署具有高可用能力的应用时，我们第一个可以依赖的就是可用区，可用区设计权衡考虑了延迟、可用性、成本，方便客户构建高可用的应用。我们以下图一个非常标准的 Web 三层架构来展示了如何使用多可用区实现高可用性。

首先是网络层，我们将 ELB 的多个 endpoint 部署在每个可用区，建议启用 cross-zone load balancing，从而让 ELB 能够容忍任意 endpoint 的故障。ELB 还通过 TargetGroup 为其背后的应用实例提供健康检查功能，及时摘除异常的应用实例或增加可用的应用实例。建议为应用 health check 设计一个专门页面，能够判断应用是否能够真正处理业务流量（readiness）。NAT Gateway 为 private subnet 主动访问外部提供了网关服务，在设计部署架构时，应该为 VPC 内的每个可用区（AZ）创建 NAT Gateway，并将映射到该 AZ 的所有 subnet 默认路由指向该 AZ 的 NAT Gateway，不仅能够实现 AZ 级别的网络高可用，同时能避免到 Internet 的流量产生 Cross AZ 费用。

其次，在部署时，应将应用 stateless 优化后，部署在跨 3 个可用区的 Auto Scaling Group（ASG）中，并结合 ELB 实现应用的负载均衡。当应用实例故障，ASG 将自动替换故障的节点，帮助系统恢复正常。ASG 能应对一般的高可用需求，但对于关键业务场景，使用 ASG 应对 AZ 级别的故障并不能实现静态稳定性的最佳实践，因为 ASG 依赖控制面来获取计算资源。因此对于核心的关键业务，还需要考虑冗余，保证在故障时 ASG 失效的极端情况下仍然有足够的资源应对 100% 的业务流量，实现静态稳定性。

最后，在 Web 三层架构里，用户往往使用 MySQL/PostgreSQL 等关系数据库用于用户数据的访问存取。针对这些开源数据库软件，用户往往需要花费大量的时间精力，设计数据库的高可用以及确保高可用情况下的数据一致性。亚马逊云科技为用户提供 RDS 服务，为这些开源数据库提供内建的跨 AZ 高可用能力，在 RDS MySQL 中开启 Multi-AZ 情况下，当数据库实例故障，RDS 将自动为用户故障转移数据库到其他的 AZ。RDS 还为用户提供自动备份能力，通过 snapshot 快速备份数据库数据，用于应对误删除等操作。对于关键的业务场景，往往需要更高的可用性和性能，亚马逊云科技为用户提供了 Aurora 数据库服务，Aurora 支持 MySQL 和 PostgreSQL，内建跨多 AZ 的高可用能力。其数据跨 3 个 AZ，共 6 个副本，提供数据层的高度冗余。Aurora 还提供读写和只读的 endpoint 用于帮助客户实现读写分离和更短的故障切换时间。我们看到该架构还使用了一些区域级的服务 Amazon DynamoDB 和 Amazon S3，这些服务不会向用户公开其可用区配置，但会跨多个可用区运行计算和存储，我们依靠区域服务来消除单个可用区故障的的影响。

当我们考虑在亚马逊云科技上部署具有高可用能力的应用时，我们第二个可以依赖的是托管服务来满足各式各样的业务需求，帮助用户减少使用这些技术自身的高可用设计和维护工作。亚马逊云科技提供的托管服务几乎都实现了跨AZ的高可用能力。在标准的 Web 三层架构中使用的常见服务，如 Amazon Elastic Kubernetes Service、Amazon Elastic Container Service、Amazon ElastiCache、Amazon Managed Streaming for Apache Kafka、Amazon DocumentDB、Amazon Keyspaces 等托管服务都提供了跨 AZ 的高可用能力。

以 Amazon EKS 为例，亚马逊云科技在设计此类服务时，充分考虑了组件的跨 AZ 冗余。

EKS 服务分为控制平面和数据平面。其中控制平面完全托管在 EKS-managed VPC 内，核心的 etcd 服务部署在 3 个 AZ，通过至少 3 个奇数节点进行选举 leader，遵循少数服从多数原则，因此跨 AZ 的隔离对于 etcd 非常重要，需要保障单一 AZ 的运行实例异常情况下，仍然有超过 1/2 的运行实例处于健康状态。kube-apiserver 是无状态的服务可随着负载的增大自动的扩展节点，并提升实例的规格。kube-scheduler、kube-controller 服务自身支持高可用，通过 leader 选举只有一个服务实例处于工作状态，故障时重新选举 leader 切换到健康运行实例，因此也需要部署多个确保高可用，这些在 EKS 服务中，都是由亚马逊云科技托管和实现高可用的，用户只需关注 Worker 节点的高可用。

Worker 节点由 Auto Scaling Group 维护，可针对自身的业务需要，将单个 Auto Scaling Group 跨多个 AZ 实现高可用，或者为每个 AZ 创建单独的 Auto Scaling Group。因此，Worker 可轻松地实现高可用。

最后，针对用户的应用部署，应充分的考虑 Pod Disruption Budget、Affinity and anti-affinity、Readiness 和 Liveness 以及 Startup 探针、Graceful Shutdown、PreStop hooks、SIGTERM 等设计，配合 EKS 的机制实现应用的 Zero Downtime 运行。

云上灾难恢复系统

灾难恢复（DR）是韧性策略的重要组成部分，涉及灾难发生时工作负载如何响应（灾难是对您的业务造成严重负面影响的事件，如自然灾害、技术故障、人为错误）。灾难恢复必须基于业务目标设定 RTO（称为恢复时间目标）和 RPO（称为恢复点目标），并制定相应的灾难恢复策略，以避免数据丢失并减少停机时间。

亚马逊云科技可供您使用的灾难恢复策略大致可分为四种方法，从低成本、低复杂性的备份与恢复策略到使用多个区域的更复杂的策略。对于高可用的工作负载，您可能只需要备份和恢复方法来进行灾难恢复，如果您对灾难的定义超出了区域破坏或受损的范围，或者如果您需要遵守法规要求，那么您应该考虑守夜灯、温备/热备或多区域多活的策略。

备份与恢复

备份和恢复是减少数据丢失或损坏的合适方法，此方法还可用于通过将数据复制到其他区域来缓解区域灾难，或者缓解工作负载只部署到单个可用区缺乏冗余的情况。除了数据之外，您还必须在恢复区域中重新部署基础设施、配置和应用程序代码。为了能够快速重新部署基础设施而不会出现错误，您可以使用 CloudFormation 或云开发工具包（Amazon CDK）等服务使用基础设施即代码（IaC）进行部署。除了用户数据之外，还请务必备份代码和配置，包括用于创建 Amazon EC2 实例的 Amazon 系统映像（AMI）。Amazon Backup 提供一个集中位置来配置、计划和监控备份的功能。对于 Amazon S3，您可以使用 Amazon S3 跨区域复制功能（CRR）。

守夜灯

守夜灯方案将数据从一个区域复制到另一个区域，数据（例如数据库和对象存储）始终处于开启状态，但应用程序代码和配置处于“关闭”状态，并且仅在测试期间或灾难恢复故障转移时使用，配置、代码更改同时部署到每个区域。守夜灯方法通过最大限度地减少活动资源来减少灾难恢复的持续成本，并简化灾难发生时的恢复流程。

温备/热备

温备方案确保在另一个区域中存在生产环境的缩小（热备是和生产环境 1:1 配置）但功能齐全的副本，此方案扩展了守夜灯概念并缩短了恢复时间，因为您的工作负载在另一个区域始终处于开启状态。此方法还允许您更轻松地实施灾难恢复测试，以增强您从灾难中恢复能力的信心。

多区域多活

多区域多活方案可以在多个区域同时运行工作负载。通过多区域多活方案，用户可以访问任何区域的工作负载。这种方法是最复杂、成本最高的灾难恢复方法，但通过正确的技术选择和实施，它可以将大多数灾难的恢复时间和数据丢失减少到接近于零。下图是以两个区域为例，并可扩展到多个区域。

使用混沌工程测试韧性

混沌工程是在生产环境或尽可能接近生产的环境中定期进行实验的学科, 目的是建立抵御生产环境故障的能力及信心。利用混沌工程，您的团队能够在基础设施、工作负载和组件级别，以可控的方式不断注入真实世界的故障，而对最终客户的影响极小甚至没有影响。混沌工程使您的团队能够从故障中学习，观察、测量和提高工作负载的韧性，并验证在发生事件时，系统会发出警报并通知团队。如果您的系统能够经受住这些故障，那么应将混沌实验作为自动回归测试的一部分，这样一来，将混沌实验作为系统开发生命周期（SDLC）的一部分，以及作为 CI/CD 管道的一部分来执行，持续提高系统韧性。但需要强调，混沌工程不是一个孤立的系统实验，它需要系统本身的韧性、可靠性设计以及可观测性的实现，是一个系统整体的设计实践。

总结

亚马逊云科技把韧性视为一项最基本的工作，在设计之初就通过技术手段（包括分区、区域和可用区的隔离机制、控制平面和数据平面隔离机制、单元架构和随机分片等）保证了云平台的韧性，并通过运营模型和机制（包括服务责任模型、运营准备情况审核、安全持续部署、错误流程纠正等）保证持续的韧性。客户可以依托亚马逊云科技，根据自身的业务目标构建韧性的架构，包括云上高可用系统和云上灾难恢复系统，并通过混沌工程进行持续提高。

参考文档

Amazon 故障隔离边界-区域隔离：https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/partitions.html

Amazon 故障隔离边界-静态稳定设计： https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html

Amazon 故障隔离边界-服务类别：https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html

单元架构：https://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html