Azure 应用程序配置常见问题解答

应用程序配置可帮助开发人员管理应用程序设置和控制功能可用性。 它旨在简化处理复杂配置数据的许多任务。

应用程序配置支持：

• 分层命名空间
• 标记
• 广泛的查询
• 批量检索
• 专用管理操作
• 功能管理用户界面

应用程序配置对 Key Vault 进行补充，而它们应在大多数应用程序部署中并行使用。

尽管应用程序配置提供了强化的安全性，但 Key Vault 仍然是存储应用程序机密的最佳位置。 Key Vault 提供硬件级加密、粒度访问策略和管理操作（如证书轮换）。

你可以创建引用 Key Vault 中存储的机密的应用程序配置键值。 有关详细信息，请参阅在 ASP.NET Core 应用中使用 Key Vault 引用。

是。 应用程序配置始终加密所有传输中的数据和静态数据。 所有网络通信都通过 TLS 1.2 或 TLS 1.3 进行。 应用程序配置支持使用 Microsoft 管理的密钥或客户管理的密钥进行静态加密。

通过 Azure 应用服务，可以为每个应用服务实例定义应用设置。 这些设置作为环境变量传递给应用程序代码。 如果需要，可以将设置与特定部署槽关联。 有关详细信息，请参阅配置应用设置。

而通过 Azure 应用程序配置，你能够定义可在多个应用之间共享的设置。 这包括在应用服务中运行的应用以及其他平台。 应用程序代码通过面向 .NET 和 Java 的配置提供程序、通过 Azure SDK 或直接通过 REST API 访问这些设置。

可以在应用服务的应用程序设置中添加对应用程序配置数据的引用。 还可以在应用服务与应用程序配置之间导入和导出设置。 利用此功能，可以根据现有的应用服务设置快速设置新的应用程序配置存储区。 还可以与依赖于应用服务设置的现有应用共享配置。

单个键值的限制为 10 KB，包括标签、内容类型、标记和其他元数据等属性。 只要键和标签的总大小低于存储限制，键和标签的数量就没有限制。

对于大多数应用程序中的单个设置，此键值限制应该足够了。 如果你发现设置大于此限制，可以考虑将数据存储在其他地方，并在应用程序配置中添加对该数据的引用。

有关限制的完整列表，请参阅 Azure 订阅和服务限制。

你可以控制谁可以在每存储级别（按存储）访问应用程序配置。 对于需要不同权限的每个环境，请使用单独的存储区。 此方法可提供最佳的安全隔离。

如果不需要环境之间的安全隔离，可以使用标签来区分配置值。 使用标签为不同环境启用不同配置提供一个完整的示例。

请参阅最佳做法。

有三个定价层：免费、标准和高级。 有关详细定价信息，请参阅应用程序配置定价页。

所有应用程序配置层都提供核心功能，包括配置设置、功能标志、Key Vault 引用、配置快照、基本管理操作、指标和日志。

以下是有关选择层的注意事项。

• 用途：免费层非常适合在非生产环境中评估服务，让你无需任何费用即可探索其功能。 标准层专为中型生产用例定制，在性能和成本效益之间实现了平衡。 对于大型或企业级生产需求，高级层提供最高级别的性能和可伸缩性，确保应用程序即使在高负载下也能顺利运行。

• 每个订阅的资源数：资源由单个配置存储区组成。 在免费层中，每个订阅在每个区域中只能有一个配置存储区。 在标准层和高级层中，订阅可以有无限数量的配置存储区。

• 每个资源的存储：在免费层中，每个配置存储区的常规存储上限为 10 MB，快照存储上限为 10 MB。 在标准层中，每个配置存储区最多可以使用 1 GB 的常规存储，以及额外 1 GB 的快照存储。 在高级层中，每个配置存储区最多可以使用 4 GB 的常规存储，以及额外 4 GB 的快照存储。

• 修订历史记录：“应用程序配置”会存储对键所做的所有更改的历史记录。 在免费层中，此历史记录存储七天。 在标准层和高级层中，此历史记录存储 30 天。

• 请求配额：免费层存储限每日 1,000 个请求。 当存储达到 1,000 个请求时，它会针对所有请求返回 HTTP 状态代码 429，直到 UTC 午夜时间。

  标准层存储限制为每小时 30,000 个请求。 小时配额用尽后，附加请求可能会返回 HTTP 状态代码 429，表示请求过多，直到该小时结束。 随着发送的请求数超过配额，百分比升高，可能会返回状态代码 429。

  高级层存储对请求不实施配额限制，确保永远不会阻止对存储的访问。

• 吞吐量：所有层中的应用程序配置存储均有吞吐量限制。 超出此限制的请求会收到 HTTP 状态代码为 429 的响应。 免费层中的存储不提供吞吐量保证。

  标准层中的存储允许的读取请求速率†最高可达每秒 300 个请求 (RPS)，写入请求速率最高可达 60 RPS。

  高级层中的存储允许的读取请求速率†最高可达每秒 450 RPS，写入请求速率最高可达 100 RPS。

  †请求速率通常是指在不限制的情况下，应用程序配置存储在指定时间内平均处理的请求数量。

• 服务级别协议：免费层没有 SLA。 标准层具有 99.9% 可用性的 SLA，启用异地复制时，可用性为 99.95%。 高级层具有 99.9% 可用性的 SLA，启用异地复制时，可用性为 99.99%。

• 功能：所有层都包含多种功能，其中包括使用 Microsoft 管理的密钥进行加密、通过访问密钥或 Microsoft Entra ID 进行身份验证、Azure 基于角色的访问控制 (RBAC)、托管标识、服务标记，以及可用性区域冗余。 标准层和高级层提供的功能更多，包括专用链接支持、使用客户管理的密钥进行加密、软删除保护和异地复制功能。

• 成本：免费层的存储可免费使用。

  标准层存储每日收取使用费，该费用涵盖了每天前 200,000 个请求。 超出此每日分配的请求会产生超额费用。

  高级层存储也收取每日使用费，该费用涵盖了副本。 每日前 800,000 个针对来源的请求和前 800,000 个针对副本的请求包含在每日费用中。 超出此每日分配的请求会产生超额费用。

可以随时升级应用程序配置存储区，例如，从免费层升级到标准层或高级层，或从标准层升级到高级层。

无法降级应用程序配置存储区，例如，从高级层降级为标准层，或从标准层降级为免费层。 但是，可以在所需层中创建新存储区，然后将配置数据导入该存储区。

应用程序配置中存储的客户数据位于创建客户应用程序配置存储的区域中。 仅当客户为另一个区域启用了异地复制时，客户数据才会复制到该区域。 这适用于所有可用区域。 客户可从全球任何位置移动、复制或访问其数据。

Azure 应用程序配置支持异地复制，以提高应对区域性服务中断的复原能力。

Azure 应用配置支持 Azure 可用性区域，可以保护应用程序和数据免受单个数据中心故障的影响。 所有启用可用性区域的地区至少包含三个可用性区域，其中每个可用性区域都是物理意义上独立的数据中心。 为实现复原能力，可为所有客户启用应用配置中的此支持，而无需额外付费。 下面是应用程序配置启用了可用性区域支持的区域。 有关详细信息，请参阅 Azure 中的区域和可用性区域。

下面是应用配置启用了可用性区域支持的区域。

应用程序配置存储根据其层实施不同的请求配额。 免费层存储限制为每日 1,000 个请求，标准层存储限制为每小时 30,000 个请求，而高级层存储没有请求限制，确保访问不会中断。

应用程序配置存储根据其层实施吞吐量限制。 免费层存储不提供吞吐量保证。 标准层存储支持的读取操作速率最高可达每秒 300 个请求 (RPS)，写入操作速率最高可达 60 RPS。 高级层存储支持的读取操作速率最高可达每秒 450 RPS，写入操作速率最高可达 100 RPS。

让我们举个例子，假设你的应用程序具有 1,000 个配置设置。 该应用程序在启动时从应用程序配置加载所有这些设置。 之后，它每隔 30 秒检查配置更改的 Sentinel 键。 无论是在 Kubernetes、应用服务还是 VM 上运行，我们都假设有 50 个应用程序实例同时在运行。

首先，让我们估算配置监视的请求数。 每个应用程序实例每隔 30 秒向应用程序配置发送一个 Sentinel 键请求，因此它在一小时内会发送 120 (=3600/30) 个请求。 假设有 50 个应用程序实例，那么应用程序每小时将发送 6,000 (=120x50) 个配置监视请求。 请注意，因为 Sentinel 键请求频繁且大部分未更改，所以大部分不会计入标准层存储的每小时配额限制†。

接下来，让我们估算配置加载/重载的请求数。 应用程序会在启动时或每当检测到 Sentinel 键更改时加载所有设置。 对应用程序配置的每个请求最多可以检索 100 个键值，因此需要发送 10 (=1000/100) 个请求才能加载所有设置。 假设有 50 个应用程序实例，当应用程序重启或重载其配置时，你总共需要发送 500 (=10x50) 个请求。

最后，让我们总结一下。 假设在一小时内更新了 Sentinel 键两次，则应用程序配置存储在该小时内会收到 7,000 (=6,000+500x2) 个请求。 请注意，在这些请求中，只有大约 1,000 (=500x2) 个请求会使用标准层存储的每小时可用配额。 根据自己特定的设置来更新此示例中的数字，并进行相应的设计，以便有足够的缓冲区来应对每小时配额限制。

†免费层存储不排除频繁、重复的请求，这些请求会计入其每日限制。

在以下情况下，应用程序可能会收到 HTTP 状态代码为 429 的响应：

• 超出免费层中存储的每日请求配额。
• 超出标准层中存储的每小时请求配额。
• 超出任意层中存储的吞吐量限制。
• 超出任意层中存储的带宽限制。
• 在超出存储配额时尝试创建或修改键-值。

检查 429 响应的正文，以了解请求失败的具体原因。 你还可以在 Azure Monitor 中收集应用程序配置存储的日志，并针对“请求配额用量”指标设置警报。

收到 HTTP 状态代码为 429 的暂时性响应通常不会造成损害，因为应用程序配置客户端会妥善处理它们。 但是，如果应用程序经常遇到 HTTP 状态代码为 429 的响应，请考虑采取以下措施：

• 将存储升级到高级层：此层对请求不实施配额限制，并且增加了存储配额和吞吐量限额。
• 使用应用程序配置提供程序：提供程序具有内置的重试和缓存功能以及其他许多复原功能。 请务必更新到最新版本的提供程序，以获取所有最新增强功能。
• 如果应用程序需要发送写入请求，请使用应用程序配置 SDK。 尽管 SDK 的功能可能不如提供程序那样丰富，但它们会在收到 HTTP 状态代码为 429 的响应和其他暂时性错误时自动重试。
• 如果无法使用应用程序配置提供程序或 SDK，请在自定义客户端中包含重试逻辑。 响应中的 retry-after-ms 标头在重试请求之前会提供建议的等待时间（以毫秒为单位）。
• 在多个客户端实例之间分配请求：这有助于实现应用程序配置存储的最大吞吐量。
• 减少对应用程序配置的请求：按照指导最大程度地减少请求数量。
• 提高应用程序复原能力：考虑集成异地复制以实现故障转移和负载均衡。 查看有关生成具有高复原能力的应用程序的最佳做法。

标准层和高级层中的所有应用程序配置存储区都自动启用了软删除功能。 删除标准层或高级层应用程序配置存储区后，该存储区的名称会在保持期内保留。 若要在保持期到期之前重新创建同名的存储，需要先清除软删除的存储，前提是该存储未启用清除保护。 如果启用了清除保护，则必须等待保持期结束。 如果经常需要重新创建同名的存储，请使用清除功能或设置较短的保持期。 需要重新创建具有相同名称的存储的工作流应在清除配置存储和执行后续创建之间留出一小时的时间。 之所以有此建议，是因为请求清除后，配置存储资源的实际清理会异步执行，这需要一些额外的时间才能完成。 为避免等待，建议为创建临时配置存储的工作流使用唯一名称。

标准层和高级层中的所有应用程序配置存储区都支持软删除功能，该功能无法禁用。 你可以在保持期内恢复已删除的存储。 按照这些说明可恢复不小心删除的应用程序配置存储。

是的。 可以通过 Azure 门户或 CLI 在应用程序配置中管理功能标志和 Key Vault 引用，同时也可以使用应用程序配置 SDK 以编程方式创建和更新它们。 因此，可以写入自定义管理门户，或者以编程方式在 CI/CD 中管理它们。 功能标志和 Key Vault 参引用 API 在所有受支持语言的 SDK 中都可用。 查看示例链接，获取每种受支持语言的示例。

在应用程序中评估和使用功能标志需要应用程序配置提供程序和功能管理库，这些库在 .NET 和 Java Spring 中提供。 查看快速入门和教程下的“功能管理”部分，了解更多信息。

Spring 配置文件提供了一种分离应用程序部分（包括配置）的方法，并使其仅在特定环境或使用特定库时可用。

建议设置键值的标签以匹配 Spring 配置文件。 默认情况下，如果未显式设置标签筛选器，应用程序配置 Spring 提供程序库会加载标签与当前活动的 Spring 配置文件 (${spring.profiles.active}) 相匹配的键值。 如果未设置活动的 Spring 配置文件，则将加载具有“无标签”的键值。

例如，对于配置文件 dev 和 prod，可以相应地使用以下标签创建键值。

当 Spring 配置文件设置为 dev 时，config.message 的值将为 Hello from dev。 当 Spring 配置文件设置为 prod 时，config.message 的值将为 Hello from prod。

可以通过在启动文件中设置标签筛选器来重写此默认行为。 无论活动的 Spring 配置文件如何，Spring 提供程序库都会加载具有指定标签的键值。

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

若要选择其他标签和 Spring 配置文件，可以使用标签筛选器（例如 ',${spring.profiles.active}'），它将选择所有没有标签的键以及与 Spring 配置文件匹配的键。 找到重复键时，优先选择最右边的标签。

从版本 3.1.0 开始，Microsoft.FeatureManagement 库支持将功能管理服务（包括功能筛选器）作为基于依赖项注入的 .NET 应用程序中的范围服务运行。 只需将代码中的 AddFeatureManagement 调用替换为 AddScopedFeatureManagement 即可利用此功能，如以下代码片段所示：

services.AddScopedFeatureManagement();

功能筛选器可以根据 HTTP 请求的属性评估功能标志。 这通常是通过单一实例 IHttpContextAccessor 模式检查 HttpContext 来执行的。 但是，此模式不适用于 Blazor 服务器应用程序，在这些应用程序中，应转而使用范围服务。 在这种情况下，应使用 AddScopedFeatureManagement 方法。

订阅我们的 GitHub 公告存储库。

可以直接在 GitHub 上联系我们。

• 关于 Azure 应用配置