Azure 应用配置中的可靠性

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

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

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

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

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

• Sku： 使用标准或高级 SKU。
• 软删除和清除保护： 启用软删除和清除保护，防止数据删除。
• 对于任务关键型方案： 使用高级 SKU 并配置包含的副本，以便跨多个区域进行复制，以提高对区域中断的高可用性和复原能力。

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

可靠性体系结构概述

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

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

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

暂时性故障的复原能力

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

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

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

• 配置提供程序： 使用的应用配置提供程序，这些提供程序具有内置重试和缓存功能，以及其他许多复原功能。
• Azure SDK： 如果应用程序需要发送写入请求，请使用应用配置 SDK。 SDK 会自动重试 HTTP 状态代码 429 响应和其他暂时性错误。
• 重试逻辑： 如果无法使用应用配置提供程序或 SDK，请在自定义客户端中包含重试逻辑。 retry-after-ms响应中的标头在重试请求之前提供建议的等待时间（以毫秒为单位）。
• 缓存： 尽可能在内存中进行缓存设置，以减少直接请求到存储系统的次数。

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

应对可用区故障的弹性

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

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

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

要求

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

美洲	欧洲	中东	非洲	亚太
Brazil South	法国中部	以色列中部		Australia East
加拿大中部	德国中西部	卡塔尔中部		印度中部
美国中部	意大利北部	阿拉伯联合酋长国北部		中国北部 3
美国东部	北欧			东亚
美国东部 2	挪威东部			日本东部
墨西哥中部	波兰中部			韩国中部
美国中南部	西班牙中部			东南亚
US Gov 弗吉尼亚州	瑞典中部
美国西部 2	瑞士北部
美国西部 3	英国南部
	西欧

成本

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

配置可用性区域支持

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

如果应用配置将可用性区域支持添加到现有区域，则无需执行任何作即可开始从可用性区域支持中受益。 你的应用商店将受益于区域支持，这些支持已可用于该区域中的应用配置存储区。

所有区域正常时的行为

当存储位于支持区域冗余且所有可用性区域都正常运行的区域时，可以预期出现以下行为：

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

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

区域故障期间的行为

本节介绍在商店位于支持区域冗余的地区且一个可用性区不可用时会发生什么情况：

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

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

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

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

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

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

区域恢复

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

测试区域故障

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

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

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

异地复制

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

要求

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

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

注意事项

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

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

• Azure Front Door： 若要使用 Azure Front Door 启用异地冗余配置传递，请将应用配置副本配置为源组中的源。 正确的源配置允许 Azure Front Door 跨区域管理基于运行状况的路由、负载均衡和自动故障转移。 有关详细信息，请参阅 流量路由方法到源。

成本

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

配置多区域支持

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

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

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

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

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

  注释

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

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

区域故障期间的行为

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

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

  使用 应用配置提供程序 并执行 自动副本发现 或包含多个副本的列表时，应用程序会自动故障转移到另一个正常运行的副本。

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

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

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

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

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

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

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

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

区域恢复

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

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

针对区域故障进行测试

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

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

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

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

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 文件的更改。

备份和还原

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

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

对意外删除的抵抗力

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

• 软删除： 启用后，软删除允许在可配置的保留期内恢复已删除的存储和设置。 将软删除视为应用配置资源的回收站。

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

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

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

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

对配置问题的复原能力

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

服务级别协议

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

相关内容

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