区域服务

区域服务是在 AWS 多个可用区之上构建的服务，因此客户不必弄清楚如何充分利用区域服务。我们在逻辑上将部署在多个可用区的服务组合在一起，为客户提供单个区域终端节点。亚马逊SQS和亚马逊 Dynam oDB 就是区域服务的示例。它们利用可用区域的独立性和冗余性来最大限度地减少基础设施故障，这是可用性和耐久性风险中的一类。例如，Amazon S3 将请求和数据分散到多个可用区，旨在自动从可用区的故障中恢复。但是，您只能与服务的区域终端节点进行交互。

AWS 相信大多数客户可以通过使用依赖区域服务的区域服务或多可用区架构在单个区域实现其弹性目标。但是，某些工作负载可能需要额外的冗余，您可以使用的隔离 AWS 区域 来创建用于高可用性或业务连续性的多区域架构。两者之间的物理和逻辑分离 AWS 区域 避免了它们之间的相关故障。换句话说，与您是EC2客户并可以通过跨可用区部署来从隔离可用区中受益类似，通过跨多个区域进行部署，您也可以获得同样的优势来获得区域服务。这要求您为应用程序实施多区域架构，这可以帮助您抵御区域服务的损害。

但是，实现多区域架构的好处可能很困难；要利用区域隔离，同时又不能在应用程序层面撤消任何东西，需要谨慎行事。例如，如果您要在区域之间对应用程序进行故障切换，则需要在每个区域的应用程序堆栈之间保持严格分离，注意所有应用程序依赖关系，并将应用程序的所有部分一起进行故障转移。使用复杂的、基于微服务的架构实现这一目标，该架构在应用程序之间存在许多依赖关系，需要许多工程和业务团队进行规划和协调。允许单个工作负载自己做出故障转移决策可以降低协调的复杂性，但是由于不同区域之间发生的延迟与单个区域内部的延迟存在显著差异，从而引入了模态行为。

AWS 目前不提供同步跨区域复制功能。使用跨区域异步复制的数据存储库（由提供 AWS）时，当您在区域之间对应用程序进行故障转移时，可能会出现数据丢失或不一致的情况。为了减少可能的不一致性，您需要一个值得信赖的可靠数据协调流程，并且可能需要对工作负载组合中的多个数据存储进行操作，或者您需要愿意接受数据丢失。最后，你需要练习故障转移，才能知道它会在你需要的时候起作用。定期在区域之间轮换应用程序以练习故障转移需要大量的时间和资源投入。如果您决定使用跨区域同步复制的数据存储来支持在多个区域同时运行的应用程序，那么跨越 100 或 1000 英里的此类数据库的性能特征和延迟与在单个区域中运行的数据库有很大不同。这要求您从头开始规划应用程序堆栈，以应对这种行为。它还使两个区域的可用性成为硬性依赖，这可能会导致工作负载的弹性降低。