# 使用故障隔离来保护工作负载
<a name="use-fault-isolation-to-protect-your-workload"></a>

故障隔离可将组件或系统故障的影响限制在定义的界限内。通过适当的隔离，界限之外的组件不受故障影响。跨多个故障隔离界限运行工作负载，可以提高工作负载对故障的韧性。

**Topics**
+ [REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 组件的自动恢复受限于单个位置](rel_fault_isolation_single_az_system.md)
+ [REL10-BP03 采用隔板架构来限制影响范围](rel_fault_isolation_use_bulkhead.md)

# REL10-BP01 将工作负载部署到多个位置
<a name="rel_fault_isolation_multiaz_region_system"></a>

 将工作负载数据和资源分布到多个可用区，或在必要时分布到多个 AWS 区域。

 AWS 中服务设计的一个基本原则是避免单点故障，包括底层物理基础设施。AWS 在全球多个地理位置（称为 [Regions](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html)）提供云计算资源和服务。每个区域在物理和逻辑上都是独立的，由三个或更多 [Availability Zones (AZs)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) 组成。可用区在地理上彼此接近，但在物理上是分开和隔离的。当您将工作负载分布于各个可用区和区域之间时，可以降低火灾、洪水、与天气相关的灾难、地震和人为错误等威胁的风险。

 制定位置策略，以提供适合您的工作负载的高可用性。

 **期望结果：**生产工作负载分布于多个可用区（AZ）或区域之间，以实现容错和高可用性。

 **常见反模式：**
+  您的生产工作负载只存在于单个可用区中。
+  您在多可用区架构满足业务要求时实施多区域架构。
+  您的部署或数据变得不同步，这会导致配置偏差或数据复制不足。
+  当应用程序组件之间的韧性和多位置要求不同时，您未考虑这些组件之间的依赖关系。

 **建立此最佳实践的好处：**
+  您的工作负载更能抵御意外事件，例如电源或环境控制故障、自然灾害、上游服务故障或影响可用区或整个区域的网络问题。
+  在启动特定 EC2 实例类型时，您可以访问更广泛的 Amazon EC2 实例清单，并降低出现 InsufficientCapacityExceptions（ICE）的可能性。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 在区域的至少两个可用区（AZ）中部署和运行所有生产工作负载。

 **使用多个可用区** 

 可用区是资源托管位置，它们在物理上彼此分开，以避免由于火灾、洪水和龙卷风等风险而导致的相关故障。每个可用区都有独立的物理基础设施，包括市电连接、备用电源、机修服务和网络连接。这种安排方式可将其中任何组件的故障限制在受影响的可用区内。例如，如果可用区范围的事件导致 EC2 实例在受影响的可用区中不可用，则您在其它可用区的实例仍保持可用。

 尽管同一 AWS 区域中的可用区在物理上是分开的，但它们之间的距离足够近，可以提供高吞吐量、低延迟（个位数毫秒）的联网。您可以在可用区之间同步复制大多数工作负载的数据，而不会显著影响用户体验。这样一来，您便能以主动/主动或主动/备用配置使用区域中的可用区。

 与工作负载关联的所有计算均应分布于多个可用区中。这包括 [Amazon EC2](https://aws.amazon.com/ec2/) 实例、[AWS Fargate](https://aws.amazon.com/fargate/) 任务和 VPC 连接的 [AWS Lambda](https://aws.amazon.com/lambda/) 函数。AWS 计算服务，包括 [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)、[Amazon Elastic Container Service（ECS）](https://aws.amazon.com/ecs/)和 [Amazon Elastic Kubernetes Service（EKS）](https://aws.amazon.com/eks/)，为您提供了跨可用区启动和管理计算的方法。将它们配置为根据需要在不同的可用区中自动替换计算以保持可用性。要将流量定向到可用的可用区，请在计算前放置一个负载均衡器，例如应用程序负载均衡器或网络负载均衡器。如果某个可用区受到损害，AWS 负载均衡器可以将流量重新路由到可用的实例。

 您还应该为工作负载复制数据，并使其在多个可用区中可用。某些 AWS 托管式数据服务，例如 [Amazon S3](https://aws.amazon.com/s3/)、[Amazon Elastic File Service（EFS）](https://aws.amazon.com/efs/)、[Amazon Aurora](https://aws.amazon.com/aurora/)、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Simple Queue Service（SQS）](https://aws.amazon.com/sqs/)和 [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)，默认情况可在多个可用区中复制数据，并且可以抵御可用区损害。对于其它 AWS 托管式数据服务，例如 [Amazon Relational Database Service（RDS）](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/) 和 [Amazon ElastiCache](https://aws.amazon.com/elasticache/)，您必须启用多可用区复制。启用后，这些服务会自动检测可用区损害，将请求重定向到可用的可用区，并在恢复后根据需要重新复制数据，而无需客户干预。熟悉您使用的每项 AWS 托管式数据服务的用户指南，以了解其多可用区的功能、行为和操作。

 如果您使用的是自行管理的存储，例如 [Amazon Elastic Block Store（EBS）](https://aws.amazon.com/ebs/)卷或 Amazon EC2 实例存储，则必须自行管理多可用区复制。

![\[图中显示了跨三个可用区部署的多层架构。请注意，Amazon S3 和 Amazon DynamoDB 始终会自动部署到多个可用区。而 ELB 也会被部署到所有三个区。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/multi-tier-architecture.png)


 **使用多个 AWS 区域** 

 如果工作负载需要极高的韧性（如关键基础设施、与运行状况相关的应用程序或具有严格的客户或强制可用性要求的服务），您可能需要超出单个 AWS 区域所能提供的额外可用性。在这种情况下，您应该在至少两个 AWS 区域中部署和运行工作负载（假设数据驻留要求支持这么做）。

 AWS 区域位于世界各地和多个大洲的不同地理区域。AWS 区域与单独的可用区相比，其物理分离和隔离程度甚至更高。除了少数例外情况，AWS 服务利用这种设计在不同区域之间完全独立运行（也称为*区域服务*）。AWS 区域服务的故障设计为不影响其它区域中的服务。

 当您在多个区域中运行工作负载时，应考虑其它要求。由于不同区域中的资源彼此分开且独立，因此必须在每个区域中复制工作负载的组件。除计算服务和数据服务外，这还包括基本的基础设施，例如 VPC。

 **注意：**在考虑多区域设计时，请验证工作负载能够在单个区域中运行。如果您在区域之间创建依赖关系，其中一个区域中的组件依赖于另一个区域中的服务或组件，则可能会增加故障风险并显著削弱可靠性状况。

 为了简化多区域部署并保持一致性，[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) 可以跨多个区域复制整个 AWS 基础设施。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) 还可以检测配置偏差，并在某个区域中的 AWS 资源不同步时通知您。许多 AWS 服务为重要的工作负载资产提供多区域复制。例如，例如，[EC2 Image Builder](https://aws.amazon.com/image-builder/) 可以在每次构建后将 EC2 机器映像（AMI）发布到您使用的每个区域。[Amazon Elastic Container Registry（ECR）](https://aws.amazon.com/ecr/)可以将容器映像复制到选定的区域。

 您还必须跨您所选的每个区域复制数据。许多 AWS 托管式数据服务提供跨区域复制功能，包括 Amazon S3、Amazon DynamoDB、Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon Elasticache 和 Amazon EFS。[Amazon DynamoDB 全局表](https://aws.amazon.com/dynamodb/global-tables/)接受在任何受支持的区域中进行写入，并将在所有其它配置的区域间复制数据。对于其它服务，您必须指定一个主区域进行写入，因为其它区域包含只读副本。对于工作负载使用的每项 AWS 托管式数据服务，请参阅其用户指南和开发人员指南，以了解其多区域功能和局限性。请特别注意必须将写入定向到何处、事务处理功能和限制、如何执行复制以及如何监控区域之间的同步。

 AWS 还能够非常灵活地将请求流量路由到区域部署。例如，可以使用 [Amazon Route 53](https://aws.amazon.com/route53/) 配置 DNS 记录，来将流量定向到离用户最近的可用区域。或者，可以在主动/备用配置中配置 DNS 记录，在这种配置中，您将一个区域指定为主区域，仅当主区域变得运行状况不正常时，才回退到区域副本。您可以配置 [Route 53 health checks](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html) 来检测运行状况不正常的端点并执行自动失效转移，此外，还可以使用 [Amazon 应用程序恢复控制器（ARC）](https://aws.amazon.com/application-recovery-controller/)来提供高度可用的路由控制，以便根据需要手动重新路由流量。

 即使您选择不在多个区域中运行来实现高可用性，也可以将多个区域视为灾难恢复（DR）策略的一部分。如果可能，请在辅助区域中以*热备用* 或*指示灯* 配置来复制工作负载的基础设施组件和数据。在此设计中，您从主区域复制基准基础设施，如 VPC、自动扩缩组、容器编排工具和其它组件，但您将备用区域中的可变大小组件（如 EC2 实例和数据库副本的数量）配置为最小可操作大小。您还可以安排从主区域到备用区域的连续数据复制。如果发生事件，则可以横向扩展或增加备用区域中的资源，然后将其提升为主区域。

### 实施步骤
<a name="implementation-steps"></a>

1.  与业务利益相关者和数据驻留专家合作，来确定哪些 AWS 区域可用来托管您的资源和数据。

1.  与业务和技术利益相关者合作，来评估您的工作负载，并确定其韧性需求是否可以通过多可用区方法（单个 AWS 区域）来满足，或者是否需要多区域方法（如果允许多个区域）。使用多个区域可以提高可用性，但可能会增加复杂性和成本。评估时考虑以下因素：

   1.  **业务目标和客户要求**：如果在可用区或区域中发生影响工作负载的事件，允许有多少停机时间？ 评估恢复点目标，如 [REL13-BP01 定义停机和数据丢失的恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)中所述。

   1.  **灾难恢复（DR）要求**：您想要确保自行抵御哪种潜在灾难？ 考虑数据丢失或长期不可用的可能性，影响范围涉及单个可用区到整个区域。如果您跨可用区复制数据和资源，而单个可用区持续出现故障，则可以在另一个可用区中恢复服务。如果您跨区域复制数据和资源，则可以在另一个区域中恢复服务。

1.  将计算资源部署到多个可用区中。

   1.  在 VPC 中，在不同的可用区中创建多个子网。将每个子网配置为足够大，以容纳处理工作负载所需的资源，即使在发生事件期间也是如此。有关更多详细信息，请参阅 [REL02-BP03 确保 IP 子网分配考虑扩展和可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)。

   1.  如果您使用的是 Amazon EC2 实例，请使用 [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 来管理实例。在创建自动扩缩组时，指定在上一步中选择的子网。

   1.  如果您正在对 [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) 或 [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html) 使用 AWS Fargate 计算，请在创建 ECS 服务、启动 ECS 任务或为 EKS 创建 [Fargate 配置文件](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html)时，选择您在第一步中选择的子网。

   1.  如果您使用的 AWS Lambda 函数需要在 VPC 中运行，请在创建 Lambda 函数时，选择您在第一步中选择的子网。对于任何没有 VPC 配置的函数，AWS Lambda 自动为您管理可用性。

   1.  将流量定向器（例如负载均衡器）放在计算资源之前。如果启用了跨区域负载均衡，[AWS 应用程序负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)和[网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)会检测何时由于可用区受损而无法访问 EC2 实例和容器等目标，并将流量重新路由到正常运行的可用区中的目标。如果您禁用跨区域负载均衡，请使用 Amazon 应用程序恢复控制器（ARC）来提供可用区转移功能。如果您使用的是第三方负载均衡器或已实施了自己的负载均衡器，请为它们配置跨不同可用区的多个前端。

1.  跨多个可用区复制工作负载的数据。

   1.  如果您使用的是 AWS 托管式数据服务，例如 Amazon RDS、Amazon ElastiCache 或 Amazon FSx，请研读其用户指南以了解其数据复制和韧性功能。必要时启用跨可用区复制和失效转移。

   1.  如果您使用 AWS 托管式存储服务，例如 Amazon S3、Amazon EFS 和 Amazon FSx，请避免对需要高耐久性的数据使用单可用区或单区配置。对这些服务使用多可用区配置。查看相应服务的用户指南，以确定默认情况下是否启用了多可用区复制，或者是否必须启用它。

   1.  如果您运行的是自行管理的数据库、队列或其它存储服务，请根据应用程序的说明或最佳实践安排进行多可用区复制。熟悉应用程序的失效转移过程。

1.  配置您的 DNS 服务以检测可用区受损，并将流量重新路由到运行状况正常的可用区。Amazon Route 53 与弹性负载均衡器结合使用时，可以自动执行此操作。还可以为 Route 53 配置失效转移记录，这些记录使用运行状况检查来响应仅具有正常运行的 IP 地址的查询。对于用于失效转移的任何 DNS 记录，请指定较短的生存时间（TTL）值（例如，60 秒或更短），以协助防止记录缓存阻碍恢复（Route 53 别名记录为您提供相应的 TTL）。

 **使用多个 AWS 区域时的额外步骤** 

1.  跨所选区域复制工作负载使用的所有操作系统（OS）和应用程序代码。如有必要，可以使用 Amazon EC2 Image Builder 等解决方案复制 EC2 实例使用的亚马逊机器映像（AMI）。使用 Amazon ECR 跨区域复制等解决方案复制存储在注册表中的容器映像。为用于存储应用程序资源的任何 Amazon S3 存储桶启用区域复制。

1.  将您的计算资源和配置元数据（例如，存储在 AWS Systems Manager Parameter Store 中的参数）部署到多个区域。使用前面步骤中介绍的相同过程，但请为您要用于工作负载的每个区域复制配置。使用 AWS CloudFormation 等基础设施即代码解决方案在区域之间统一复制配置。如果您在指示灯配置中使用辅助区域进行灾难恢复，您可以将计算资源的数量减少到最小值以节省成本，同时相应地增加恢复时间。

1.  将数据从主区域复制到辅助区域。

   1.  Amazon DynamoDB 全局表提供数据的全局副本，可以从任何支持的区域写入这些副本。对于其它 AWS 托管式数据服务，例如 Amazon RDS、Amazon Aurora 和 Amazon Elasticache，您可以指定主（读/写）区域和副本（只读）区域。有关区域复制的详细信息，请参阅相应服务的用户和开发人员指南。

   1.  如果您运行的是自行管理的数据库，请根据应用程序的说明或最佳实践安排进行多区域复制。熟悉应用程序的失效转移过程。

   1.  如果工作负载使用 AWS EventBridge，则可能需要将选定的事件从主区域转发到辅助区域。为此，请将辅助区域中的事件总线指定为主区域中匹配事件的目标。

1.  考虑是否以及在多大程度上希望跨区域使用相同的加密密钥。平衡安全性和易用性的典型方法是使用区域范围的密钥来处理区域本地数据和身份验证，并使用全球范围的密钥来对在不同区域间复制的数据进行加密。[AWS Key Management Service（KMS）](https://aws.amazon.com/kms/)支持 [multi-region keys](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)，以便安全地分发和保护跨区域共享的密钥。

1.  考虑使用 AWS Global Accelerator，通过将流量定向到包含正常运行的端点的区域，来提高应用程序的可用性。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [REL02-BP03 确保 IP 子网分配考虑扩展和可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html) 
+  [REL11-BP05 使用静态稳定性来防止双模态行为](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) 
+  [REL13-BP01 定义停机和数据丢失的恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html) 

 **相关文档：**
+  [AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure) 
+  [White paper: AWS Fault Isolation Boundaries](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) 
+  [Resilience in Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html) 
+  [Amazon EC2 Auto Scaling: Example: Distribute instances across Availability Zones](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
+  [How EC2 Image Builder works](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution) 
+  [Amazon ECS 如何将任务放置在容器实例上（包括 Fargate）](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html) 
+  [AWS Lambda 中的故障恢复能力](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html) 
+  [Amazon S3：复制对象概述](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 
+  [Amazon ECR 中的私有映像复制](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html) 
+  [全局表：使用 DynamoDB 的多区域复制](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) 
+  [Amazon Elasticache for Redis OSS: Replication across AWS 区域 using global datastores](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html) 
+  [Amazon RDS 中的弹性](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html) 
+  [使用 Amazon Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) 
+  [AWS Global Accelerator Developer Guide](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [Multi-Region keys in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) 
+  [Amazon Route 53: Configuring DNS failover](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html) 
+  [Amazon Application Recovery Controller (ARC) Developer Guide](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [Sending and receiving Amazon EventBridge events between AWS 区域](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html) 
+  [Creating a Multi-Region Application with AWS Services](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 系列博客文章 
+  [开启 AWS 灾难恢复（DR）架构，第一部分：云端恢复策略](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) 
+  [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) 

 **相关视频：**
+  [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure](https://youtu.be/UObQZ3R9_4c) 

# REL10-BP02 组件的自动恢复受限于单个位置
<a name="rel_fault_isolation_single_az_system"></a>

如果工作负载的组件只能在单个可用区或本地数据中心内运行，则必须利用相关功能在定义的恢复目标内彻底重建工作负载。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 如果由于技术约束无法使用将工作负载部署到多个位置的最佳实践，则必须实施其他的韧性路径。在这种情况下，必须让重建必要基础设施、重新部署应用程序和重建必要数据的操作实现自动化。

 例如，Amazon EMR 会为相同可用区内的特定集群启动全部节点，因为在相同区内运行集群可以改善作业流的性能，提高数据访问速率。如果这是工作负载韧性所需的必要组件，则必须设法重新部署集群及其数据。同样对于 Amazon EMR，您还应该通过除多可用区以外的方式对冗余进行预置。您可以预置[多个节点](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html)。使用 [EMR 文件系统（EMRFS）](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)，EMR 中的数据可存储在 Amazon S3 中，进而可以跨多个可用区或 AWS 区域进行复制。

 同理，对于 Amazon Redshift，默认会在您选择的 AWS 区域内随机选择可用区，然后对其中的集群进行预置。所有集群节点在同一区域中配置。

 对于部署到本地数据中心基于服务器的有状态工作负载，您可以使用 AWS 弹性灾难恢复 来保护 AWS 中的工作负载。如果已经在 AWS 托管中，则可以使用弹性灾难恢复将工作负载保护到其他可用区或区域。弹性灾难恢复在轻量级暂存区域中使用持续的块级复制，以便快速可靠地恢复本地应用程序和基于云的应用程序。

 **实施步骤** 

1.  实施自我修复。尽可能使用自动扩缩部署实例或容器。如果不能使用自动扩缩，则使用 EC2 实例的自动恢复功能，或者基于 Amazon EC2 或 ECS 容器生命周期事件实现自我修复自动化。
   +  将 [Amazon EC2 Auto Scaling 组](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)用于对单个实例 IP 地址、私有 IP 地址、弹性 IP 地址和实例元数据没有要求的实例和容器工作负载。
     +  启动模板用户数据可以用于实现自动化，让大多数工作负载可以自我修复。
   +  将 [Amazon EC2 实例的自动恢复功能](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)用于需要单个实例 ID 地址、私有 IP 地址、弹性 IP 地址和实例元数据的工作负载。
     +  自动恢复功能会在检测到实例故障时，向 SNS 主题发送恢复状态提醒。
   +  在无法使用自动扩缩或 EC2 恢复的情况下，请使用[Amazon EC2 实例生命周期事件](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)或 [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)实现自我修复自动化。
     +  使用这些事件调用自动化，该自动化将根据您需要的流程逻辑来修复组件。
   +  使用 [AWS 弹性灾难恢复](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 保护仅限于单个位置的有状态工作负载。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [Amazon ECS 事件](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) 
+  [Amazon EC2 Auto Scaling 生命周期挂钩](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) 
+  [恢复实例。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+  [服务自动扩缩](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html) 
+  [What Is Amazon EC2 Auto Scaling?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [AWS 弹性灾难恢复](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)

# REL10-BP03 采用隔板架构来限制影响范围
<a name="rel_fault_isolation_use_bulkhead"></a>

实施隔板架构（也称为基于单元的架构），将工作负载中故障的影响限制于有限数量的组件。

 **期望结果：**基于单元的架构使用多个独立的工作负载实例，其中每个实例称为单元。单元彼此独立，不与其他单元共享状态，并且处理整个工作负载请求的子集。这样减少了故障（例如，错误的软件更新）对单个单元及其正在处理的请求的潜在影响。如果某个工作负载使用 10 个单元来服务 100 个请求，则在发生故障时，总请求中有 90% 不会受故障的影响。

 **常见反模式：**
+  让单元无限制地发展。
+  同时将代码更新或部署到所有单元。
+  在不同单元之间共享状态或组件（路由器层除外）。
+  向路由器层添加复杂的业务或路由逻辑。
+  没有尽量减少跨单元交互。

 **建立此最佳实践的好处：**借助基于单元的架构，许多常见类型的故障控制在单元本身，从而实现了额外的故障隔离。若出现难以控制的故障类型（例如不成功的代码部署，或者是受损或调用特定故障模式的请求，也称为*毒丸*请求），这些故障边界可以提供韧性。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 在船舶上，隔板确保船体裂口控制在船体的一个区段内。在复杂的系统中，通常会复制此模式以实现故障隔离。故障隔离边界可将一个工作负载内的故障影响限制于有限数量的组件。边界之外的组件不受故障影响。通过使用多个故障隔离边界，您可以限制对工作负载的影响。在 AWS 中，客户可以使用多个可用区和区域来实现故障隔离，但故障隔离的概念也可以扩展到工作负载的架构。

 整个工作负载是分区的单元，按分区键进行划分。这个键需要与服务的*粒度*，或者与使用最少的跨单元交互来细分服务工作负载的自然方式保持一致。分区键的示例包括客户 ID、资源 ID 或可以在大多数 API 调用中轻松访问的任何其他参数。单元路由层根据分区键将请求分发到单个单元，并向客户端提供单个端点。

![\[图中显示了基于单元的架构\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/reliability-pillar/images/cell-based-architecture.png)


 **实施步骤** 

 在设计基于单元的架构时，需要考虑几个设计注意事项：

1.  **分区键**：选择分区键时应考虑一些特别事项。
   +  分区键应与服务的粒度，或者与使用最少的跨单元交互来细分服务工作负载的自然方式保持一致。示例包括 `customer ID` 或 `resource ID`。
   +  在所有请求中都必须提供分区键，要么直接提供，要么通过很容易由其他参数确定地推断出来的方式提供。

1.  **持久单元映射**：上游服务在其资源的生命周期内应只与单个单元交互。
   +  根据工作负载，可能需要使用单元迁移策略将数据从一个单元迁移到另一个单元。可能需要进行单元迁移的一种情况是：工作负载中的一个特定用户或资源变得太大，要求它具有专用的单元。
   +  单元之间不应该共享状态或组件。
   +  因此，应该避免或尽量减少跨单元交互，因为这些交互会在单元之间产生依赖关系，从而削弱故障隔离的改进。

1.  **路由器层**：路由层是单元之间的共享组件，因此无法遵循与单元相同的分隔策略。
   +  建议路由器层使用分区映射算法以一种计算效率高的方式将请求分发到各个单元，例如结合加密哈希函数和模块化算法，将分区键映射到单元。
   +  为避免产生多单元影响，路由层必须尽可能保持简单和可横向扩展，这就需要在此层中避免出现复杂的业务逻辑。这还有一个额外的好处，即始终可以轻松地理解其预期行为，从而实现彻底的可测试性。正如 Colm MacCárthaigh 在《[Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)》一文中所说，简单的设计和持续工作模式可产生可靠的系统并降低抗脆弱性。

1.  **单元大小**：单元大小应具有上限，不得发展到超过这个值。
   +  应通过执行彻底的测试来确定大小上限，直至达到临界点并建立安全的运营边际。有关如何实施测试实践的更多详细信息，请参阅 [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md) 
   +  总体工作负载增长时应增加额外的单元，使得工作负载能够随着需求的增加而扩展。

1.  **多可用区或多区域策略**：应利用多层韧性来防止出现不同的故障域。
   +  要实现韧性，应使用可构建防御层的方法。其中一层使用多可用区，通过构建高度可用的架构，防止出现较小规模、更常见的中断。另一个防御层用于防御很少发生的事件，例如大范围的自然灾害和区域级别的中断。这个第二层涉及到设计应用程序的架构来跨越多个 AWS 区域。为工作负载实施多区域策略，有助于防御影响到某个国家/地区中较大地理面积的大范围自然灾害，或者区域范围的技术故障。请注意，实施多区域架构会有很高的复杂性，对于大部分工作负载通常来说都是不必要的。有关更多详细信息，请参阅[REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md)。

1.  **代码部署**：交错的代码部署策略应该优于同时将代码更改部署到所有单元。
   +  这有助于最大限度地减少因部署不当或人为错误而导致多个单元出现故障。有关更多详细信息，请参阅[自动实现无需干预的安全部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [REL07-BP04 对工作负载进行负载测试](rel_adapt_to_changes_load_tested_adapt.md) 
+  [REL10-BP01 将工作负载部署到多个位置](rel_fault_isolation_multiaz_region_system.md) 

 **相关文档：**
+  [Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/) 
+ [AWS and Compartmentalization ](https://aws.amazon.com/blogs/architecture/aws-and-compartmentalization/)
+ [使用随机分区进行工作负载隔离](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
+  [自动实现无需干预的安全部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

 **相关视频：**
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small](https://www.youtube.com/watch?v=O8xLxNje30M)
+  [AWS re:Invent 2018: How AWS Minimizes the Blast Radius of Failures (ARC338)](https://youtu.be/swQbA4zub20) 
+  [Shuffle-sharding: AWS re:Invent 2019: Introducing The Amazon Builders' Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1373) 
+ [AWS Summit ANZ 2021 - Everything fails, all the time: Designing for resilience](https://www.youtube.com/watch?v=wUzSeSfu1XA)