异地复制概述

对于应用程序开发人员和 IT 工程师，共同的目标是构建和运行可复原的应用程序。 复原能力被定义为应用程序对故障做出反应的能力，并且仍然保持正常运行。 为了在面对云中区域故障时实现弹性，第一步是构建冗余以避免单点故障。 可以通过异地复制实现此冗余。

使用App Configuration异地复制功能，可以将配置存储复制到所选区域。 每个新 副本 将位于不同的区域中，并为应用程序创建新的终结点以向其发送请求。 配置存储的原始端点被称为Origin。 除无法删除原点外，其行为与其他任何副本类似。

可以在任何副本中更改或更新密钥值。 在最终一致性模型之后，这些更改将与所有其他副本同步。

复制您的配置存储会带来以下好处：

• 增强对Azure中断的弹性：在发生区域性服务中断时，每个副本都会分别受到影响。 如果一个区域发生中断，则位于不受影响区域的所有副本仍可访问并持续同步。 中断缓解后，所有受影响的副本都将同步到最新的状态。 请注意，异地复制仅通过 App Configuration 的配置提供程序提供自动故障转移功能。 否则，还可以在应用程序的配置中生成自己的自定义故障转移机制，在不同副本终结点之间切换，以缓解Azure中断的影响。
• 重新分发请求限制： 可以在应用程序使用的副本终结点的代码中自定义，以便分发请求负载以避免请求限制耗尽。 例如，如果应用程序在多个区域中运行，并且只向一个区域发送请求，则可以开始耗尽App Configuration请求限制。 可以通过在应用程序运行的区域创建副本来帮助重新分发此负载。 每个副本都有独立的请求限制，大小等于源的请求限制。 在一个副本中耗尽请求限制不会影响另一个副本的请求限制。
• 区域隔离： 访问多个区域可以提高应用程序与配置存储之间的延迟，如果应用程序将请求发送到其最近的副本，则会导致请求响应更快，性能更佳。 指定副本访问还可以根据偏好限制不同区域之间的数据存储和流动。

若要在商店中启用此功能，请参考如何启用异地复制的指南文件。

示例用例

开发人员团队正在构建一个由多个应用程序组成的系统，目前在中国北部 3 区域中有一家Azure App Configuration商店。 其系统的使用情况正在快速增长，他们希望在：中国东部 2、中国北部 3 中扩大和满足其客户需求。 他们目前所使用的所有应用程序都依赖于华北 3 区的配置存储，这样就形成了一个单点故障。 如果中国北部 3 发生区域性中断，并且没有其他故障转移机制或默认行为，则其系统将不可用给客户。 此外，全局上所有应用程序当前受一个配置存储的请求限制限制。 随着团队扩展到更多区域，这种限制是不可持续的。

此团队将受益于异地复制。 他们可以在其应用程序运行的每个区域中创建其配置存储的副本。 然后，他们的应用程序可以将请求发送到同一区域的副本，而不是所有应用程序都向中国北部 3 发送请求。 这将提供两个好处：改进了请求延迟和更好的负载分布。 具有良好的分布式请求负载有助于避免请求配额耗尽。 此外，通过多个副本，团队可以将应用程序配置为在发生区域性服务中断时进行故障转移。 例如，团队可以将应用程序配置为从中国东部 2 区域拉取配置，但如果中国东部 2 区域发生中断，则回退到中国北部 3 区域。 即使App Configuration在给定区域中不可用，团队的系统也不受影响。

注意事项

• 异地复制在免费层和开发人员层中不可用。
• 每个副本都有限制，如 App Configuration 定价页中所述。 这些限制按副本进行隔离。
• Azure App Configuration 还支持 Azure 可用性区域，以在 Azure 区域中创建具有复原能力和高可用性的存储。 如果副本的区域具有可用性区域支持，则副本会自动包含可用性区域支持。 将可用区组合在一个区域内实现冗余，并通过跨多个区域的异地复制，能够增强配置存储的可用性和性能。

成本和计费

创建的每个副本将产生额外的费用。 有关详细信息，请参阅 App Configuration 定价页。 例如，如果源是一个标准层配置存储区，并且你有五个副本，则会为系统收取 6 个标准层配置存储的费率，但副本的每个隔离配额和请求都包含在此费用中。

监测

若要深入了解异地复制功能的特征，App Configuration提供了名为 Replication Latency 的指标。 复制延迟指标描述了将数据从一个区域复制到另一个区域所需的时间。

后续步骤

复原和灾难恢复