本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 可用区独立性 要实现第一个效果，即停止向受影响的可用区发送工作，您需要实现[可用区独立性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/) (AZI)，有时也称[可用区亲和性](https://aws.amazon.com/blogs/architecture/improving-performance-and-reducing-cost-using-availability-zone-affinity/)，来实现撤离。这种架构模式隔离了可用区内的资源，并防止不同可用区中的资源之间进行交互，除非绝对需要（如连接到其他可用区中的主数据库实例）。 在请求/响应类型的工作负载中，要实现 AZI，您需要[禁用应用程序负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/disable-cross-zone.html#cross_zone_console_disable) (ALB)、[经典负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-disable-crosszone-lb.html#disable-cross-zone) (CLB) 和[网络负载均衡器 (NLB) 的跨区域负载均衡](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-cross-zone.html)（默认情况下，NLB 的跨区域负载均衡处于禁用状态）。禁用跨区域负载均衡时，需要做出权衡。禁用跨区域负载均衡后，无论各个可用区中有多少实例，[流量都会平均分配给每个可用区](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing)。如果您有不均衡的资源或自动扩缩组，则可能会给资源较少的可用区造成额外负担。如下图所示，可用区 1 中有两个实例，各接收 25% 的负载，而可用区 2 中有五个实例，各接收 10% 的负载。 ![\[该图显示了实例不均衡时禁用跨区域负载均衡的效果\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/advanced-multi-az-resilience-patterns/images/disabling-cross-zone-load-balancing.png) 您使用的其他区域服务也需要实现 AZI 模式，以有效撤离可用区。例如，接口 VPC 端点[为接口端点所在的每个可用区提供特定的 DNS 名称](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint)。 实现 AZI 的一个挑战在于数据库，尤其是大多数关系数据库在任何时候都只支持单个主写入器。与主实例通信时，您可能需要跨越可用区边界。许多 AWS 数据库服务都支持用户定义的多可用区配置，并具有内置的多可用区失效转移功能，例如 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html) 或 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html)。在许多故障场景中，该服务可以检测到影响，并在出现问题时自动将数据库失效转移到其他可用区。但是，在灰色故障中，服务可能无法检测到其对您的工作负载的影响，或者不认为此影响与数据库相关。在这些情况下，如果您检测到可用区受到影响，可以手动调用失效转移来移动主数据库。这样能够有效地应对单个可用区受损情况。 如果您在这些数据库中使用只读副本功能，则可能还需要为这些数据库实现 AZI，因为您无法像处理主数据库那样将只读副本失效转移到其他可用区。如果您在可用区 1 中有一个只读副本，并且将三个可用区的实例都配置为使用该副本，则影响可用区 1 的损坏也会影响其他两个可用区的运行。您需要防止出现这种影响。 对于 RDS 实例，您将收到一个 DNS 端点，用于访问特定可用区中的副本。要实现 AZI，您需要为每个可用区提供一个只读副本，并让您的应用程序了解其所在可用区使用哪个副本端点。要实现这种操作，一种方法是将可用区 ID 附加到数据库标识符中，比如 `use1-az1-read-replica.cbkdgoeute4n.us-east-1.rds.amazonaws.com`。另一种方法是使用服务发现（例如通过 [AWS Cloud Map](https://aws.amazon.com/cloud-map/)）或查找存储在 [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) 或 DynamoDB 表中的简易地图。请参见下图，了解此概念。 ![\[该图显示了查找每个可用区的 RDS 端点 DNS 名称\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/advanced-multi-az-resilience-patterns/images/discovering-rds-endpoint-names.png) Amazon Aurora 的默认配置是提供[单个读取器端点](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html#Aurora.Endpoints.Reader)，用于在可用只读副本之间对请求进行负载均衡。要使用 Aurora 实现 AZI，您可以为每个使用 `ANY` 类型的只读副本使用[自定义端点](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html#Aurora.Endpoints.Custom)（这样您就可以在需要时提升只读副本）。根据部署该副本的可用区 ID 命名自定义端点。然后，您可以使用自定义端点提供的 DNS 名称连接到特定可用区中的特定只读副本，如下图所示。 ![\[该图显示了为 Aurora 只读副本使用自定义端点\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/advanced-multi-az-resilience-patterns/images/custom-endpoint-rds-read-replicas.png) 如果您的系统采用这种架构，撤离可用区就简单多了。例如，在下图中，可用区 3 受到损坏的影响，而可用区 1 和 2 中的读取和写入操作并不会受到影响。 ![\[该图显示了使用 Amazon Aurora 只读副本实现 AZI 来防止受到影响\]](http://docs.aws.amazon.com/zh_cn/whitepapers/latest/advanced-multi-az-resilience-patterns/images/using-azi-with-rds-read-replicas.png) 换一种情况，如果可用区 2 受到影响，可用区 1 和 3 中的读取操作仍可以成功执行。此时如果 Amazon Aurora 没有自动对主数据库进行失效转移，您可以手动将其失效转移到其他可用区，以恢复处理写入的能力。借助这种方法，您在撤离可用区时，无需对数据库连接进行任何配置更改。需要进行的更改越少，流程越简单，则操作越可靠。