Azure 应用程序配置的可靠性

Azure 应用程序配置集中存储和管理应用程序配置设置和功能标志，从而替换直接嵌入在应用程序中的配置文件。 使用此方法，可以动态更新配置值、跟踪版本历史记录，并维护一段时间内的配置更改记录。 应用程序配置的可用性和可靠性是重要的注意事项，因为应用程序行为可以直接依赖于在运行时访问配置数据。

使用 Azure 时，可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。

本文介绍应用配置的可靠性体系结构，以及该服务在暂时性故障、可用性区域故障和区域中断期间如何保持可用。

提高可靠性的生产部署建议

对于应用配置的大部分生产部署，请考虑以下建议：

有关生产环境工作负载的推荐做法和配置列表，请参阅 构建具有高复原能力的应用程序。

可靠性体系结构概述

部署应用配置时，请部署 应用商店。 应用商店包含应用程序可能使用的各种类型的设置，包括 键和值以及 功能标志。 该服务还包括用于组织、保护、版本控制以及跨环境安全推出配置更改的内置功能。 有关详细信息，请参阅 什么是应用配置？

应用配置是一项完全托管的服务。 Microsoft负责对服务执行维护，并存储和管理设置。

生成连接到 App Configuration 的客户端应用程序时，可以选择使用 App Configuration 与 Azure Front Door（预览）配合 来启用缓存并加速全球流量。 此配置引入了异地复制的其他注意事项，本文将在此文章中突出显示（如果适用）。

暂时性故障的复原能力

暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。

与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循Azure暂时性故障处理指南。 有关详细信息，请参阅有关处理暂时性故障的建议。

使用应用配置时，请考虑以下最佳做法，尽量减少暂时性故障对配置访问的影响，尤其是在关键代码路径中。

• 配置提供程序： 使用具有内置重试和缓存功能和其他复原功能 的应用配置提供程序。

• 如果应用程序需要发送写入请求，Azure SDK：使用应用配置 SDK。 SDK 会自动重试 HTTP 状态代码 429 响应和其他暂时性错误。

• 重试逻辑： 如果无法使用应用配置提供程序或 SDK，请在自定义客户端中包含重试逻辑。 retry-after-ms响应中的标头提供建议的等待时间（以毫秒为单位），然后客户端重试请求。

• 缓存： 尽可能在内存中进行缓存设置，以减少直接请求到存储系统的次数。

有关其他应用程序配置指南，请参阅 应用配置常见问题解答。

应对可用区故障的弹性

可用性区域 是 Azure 区域内物理上分开的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。

应用配置在 支持可用性区域的区域中自动提供区域冗余。 此冗余可在区域中提供高可用性，而无需任何特定配置。

当可用性区域不可用时，应用配置会自动将请求重定向到其他正常的可用性区域，以确保高可用性。

要求

区域支持： 部署到以下区域的存储会自动区域冗余。

成本

应用配置的区域冗余无需额外付费。

配置可用性区域支持

Microsoft在支持可用区的区域中时自动为存储配置区域冗余。

如果应用配置将可用性区域支持添加到现有区域，则无需采取任何操作即可从可用性区域支持中受益。 您的商店将受益于在该地区应用配置存储的可用区支持。

所有区域正常时的行为

本部分介绍在具有区域冗余应用配置存储区且所有区域都正常运行时预期的情况。

• 跨区域操作： 应用配置会自动管理可用区之间的流量路由。 在正常作期间，它会以透明方式跨区域分配请求。

• 跨区域数据复制： 在支持区域的区域中，应用配置跨可用性区域同步复制数据。 此复制可确保即使某个区域不可用，设置也保持一致且可用。

区域故障期间的行为

本部分描述当您拥有一个跨区域冗余应用配置存储，并且其中一个区域发生中断时可能预期的情况。

• 检测和响应： 应用配置服务会检测区域故障并自动响应它们。 在区域故障期间无需执行任何操作。

• Notification： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。

• 活动请求： 在一个区域发生故障时，受影响的区域可能会无法处理正在传输中的请求，这需要客户端应用程序重试这些请求。 客户端应用程序应遵循 暂时性故障处理做法 ，确保在发生区域故障时可以重试请求。

• 预期数据丢失： 由于区域之间的同步复制，区域故障期间不会发生数据丢失。

• 预期的停机时间： 预计不会停机。

• 分配： 应用配置自动将流量从受影响区域重新路由到正常区域，而无需任何客户干预。

区域恢复

当以前不可用的区域恢复时，应用配置会自动在所有可用性区域中还原正常操作。 无需执行任何操作即可从区域故障中恢复。

测试区域故障

应用配置平台管理区域冗余存储的流量路由、故障转移和区域恢复。 Microsoft完全管理此过程，因此无需验证可用性区域故障进程。

对区域范围的故障的复原能力

应用配置提供本机异地复制功能，以支持区域中断期间的复原能力。 异地复制允许配置数据跨区域复制作为托管服务功能。

异地复制

使用异地复制，可以跨多个Azure区域复制存储。 每个商店可以在不同区域中具有多个副本。 原始商店本身也是副本。 此功能有助于保护应用程序免受区域范围的中断。

要求

• 区域支持：可以在应用配置支持的任何Azure区域中创建副本，即使区域未Azure配对区域也是如此。

• 层： 配置存储必须使用支持的层来启用异地复制。 有关详细信息，请参阅 “启用异地复制”。

注意事项

启用异地复制时，请考虑以下因素：

• 区域冗余副本： 在应用配置支持可用性区域的区域中创建的任何副本都是自动区域冗余的。

• Azure Front Door： 要启用通过 Azure Front Door 的地理冗余配置传输，应将应用程序配置副本配置为某个源组中的源。 Azure Front Door需要正确配置的源才能跨区域执行基于运行状况的路由、负载均衡和自动故障转移。 有关详细信息，请参阅 流量路由方法到源。

成本

每个异地复制区域根据相应层和区域的定价单独计费。 跨区域复制不收取任何数据出口费用。 有关定价详细信息，请参阅 应用配置定价。

配置多区域支持

若要为新建的配置存储设置复制，请参阅 “启用异地复制”。

当所有区域都正常时的行为

本部分介绍为异地复制配置应用配置存储时预期的情况，并且所有区域都正常运行。

• 跨区域操作： 每个副本可单独寻址，并具有自己的域名系统（DNS）名称。 所有副本都可以接受读取和写入操作。

  应用配置不会自动在区域之间路由流量。 使用 应用程序配置提供程序时，应用程序可以选择使用自动副本发现。 或者，可以指定副本的优先级列表，应用配置选择第一个正常的副本。 此方法使应用程序能够控制其使用的副本。

  注释

  如果使用Azure Front Door，流量路由行为会有所不同。 有关详细信息，请参阅 故障转移和负载均衡。

• 跨区域数据复制： 数据以异步方式复制，最终保持一致。 可以使用 Azure Monitor 中的 复制延迟指标 监视副本之间的当前复制延迟。

区域故障期间的行为

本部分介绍为地理复制配置应用程序配置存储时可能遇到的情况，以及某个副本区域出现中断时的应对措施。

• 检测和响应：Microsoft 负责检测区域或副本故障并启动恢复进程。

  当您将 App Configuration 配置提供程序 与 自动副本发现或多个副本列表一起使用时，您的应用会自动检测故障，并切换到正常工作的副本。

  如果不使用应用程序配置提供程序，你就需要负责将应用程序切换到一个健康实例。

• Notification： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。

• 活动请求： 针对区域中副本的活动请求可能会失败。 客户端应用程序应针对其他副本重试请求。

• 预期数据丢失： 如果副本失败，则对该副本所做的最近更改可能尚未复制到其他副本。 在副本恢复之前，这些更改可能保持不可用。 若要估计潜在的数据丢失，请监视 Azure Monitor 中的复制延迟指标。

• 预期的停机时间： 当副本变得不可用时，它将保持脱机状态，直到其区域恢复。 其他副本继续处理请求。 应用程序在检测到故障并切换到正常副本时可能会遇到短暂的停机时间。 持续时间取决于每个应用程序执行此检测和故障转移的速度。

• 分配： 发生故障时，应用程序必须将流量路由到正常运行的副本。

  如果使用 App Configuration 配置提供程序，提供程序会自动处理副本选择和故障转移。

  如果将Azure Front Door放置在数据存储前面，将多个副本配置为故障转移的源组，Azure Front Door会自动将请求重新路由到正常的副本。

区域恢复

区域恢复后，应用配置会将副本与其他副本同步，而无需干预。

你负责重新配置应用程序，以将流量路由回恢复的区域实例。 使用应用配置提供程序的应用程序会自动开始再次使用该副本。

针对区域故障进行测试

无法在应用配置中直接模拟副本故障转移。 但是，由于应用程序控制副本选择，因此可以通过强制应用程序进入必须切换副本的状态来测试故障转移行为。

若要验证应用程序的副本故障转移行为，可以在非生产环境中引入受控连接故障，并观察应用程序响应方式。

一种方法是使用本地计算机或其他具有管理访问权限的环境。 执行以下步骤：

1. 为Azure SDK启用详细日志记录。 在.NET中，使用 AzureEventSourceListener 类配置记录器。 有关详细信息，请参阅记录和监视。

2. 手动配置您的 hosts 文件，以便将对您的应用配置存储的请求路由到无法接收它们的 IP 地址，例如 127.0.0.1 （localhost）。

   警告

   此步骤有效地阻止从计算机访问应用配置存储区。 仅在非生产环境中执行这些步骤。

3. 监视日志中是否存在类似于以下示例的消息：

   [Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh:
   Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.
   

   此消息指示应用程序已成功故障转移以使用存储的另一个副本。

4. 完成测试后，撤消对hosts文件的更改。

备份和还原

可以使用应用配置从存储 导出配置数据 ，并将其用作更广泛的备份策略的一部分。

对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅什么是冗余、复制和备份？。

对意外删除的抵抗力

应用配置提供两个关键恢复功能，以防止意外或恶意删除：

• 软删除： 启用软删除时，可以在可配置的保留期内恢复已删除的存储和设置。 软删除的功能类似于应用程序配置资源的回收站。

• 清除保护： 启用清除保护时，服务会阻止对存储及其设置进行永久删除，直至保留期结束为止。 此安全措施可防止恶意参与者永久销毁设置。

将这两个功能用于生产环境。 有关详细信息，请参阅 软删除和清除保护。

服务维护期间的系统弹性能力

Microsoft定期执行服务更新和其他维护。 该服务会自动处理这些活动，从而使维护无缝透明。 除非Azure 服务运行状况提供计划内维护通知，否则在维护事件期间不会造成停机。

对配置问题的复原能力

错误或意外的配置更改可能会导致应用程序停机。 使用 配置快照 安全地实施配置更改。 在发生任何配置更改后监视应用程序运行状况，如果更改导致问题，请还原到最后一个已知良好的配置快照。

服务级别协议

Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 SLa for 联机服务。

相关内容

• Azure 的可靠性
• 应用配置文档