Azure App Configuration常见问题解答

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

App Configuration支持：

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

App Configuration补充Key Vault，这两者应在大多数应用程序部署中并排使用。

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

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

是。 App Configuration始终对在传输过程中的数据及静止状态下的数据进行加密。 所有网络通信都通过 TLS 1.2 或 TLS 1.3 进行。 App Configuration支持使用 Microsoft 托管密钥或客户管理的密钥进行静态加密。

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

相比之下，Azure App Configuration允许定义可在多个应用之间共享的设置。 这包括在App Service中运行的应用以及其他平台。 应用程序代码通过.NET和 Java 的配置提供程序、Azure SDK 或直接通过 REST API 访问这些设置。

可以在App Service的应用程序设置中向App Configuration数据添加 引用。 还可以在App Service和App Configuration之间导入和导出设置。 通过此功能，可以根据现有的 App Service 设置快速设置新的 App Configuration 存储库。 还可以与依赖于App Service设置的现有应用共享配置。

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

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

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

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

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

请参阅最佳做法。

有四个定价层：免费、开发人员、标准和高级。 有关详细的定价信息，请参阅 App Configuration 定价页面。

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

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

• 用途：免费层非常适合在非生产环境中评估服务，让你无需任何费用即可探索其功能。

  开发人员层对于低容量、非生产用例具有成本效益，并配备了专为开发和测试需求定制的特性和功能。

  标准层专为中等量生产和非生产用例而设计，可在性能和成本效益之间提供平衡。

  对于大容量或企业级生产需求，高级层提供最高级别的性能和可伸缩性，确保应用程序即使在负载过大的情况下也能顺利运行。

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

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

• 重新设置历史记录：App Configuration存储对密钥所做的所有更改的历史记录。 在免费层和开发人员层中，此历史记录存储 7 天。 在标准层和高级层中，此历史记录存储 30 天。

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

  开发者级别存储限制为每小时 6,000 个请求。 一旦每小时配额耗尽，其他请求将返回 HTTP 状态代码 429，指示请求过多，直到一小时结束。

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

  高级层商店对请求没有配额限制，确保不会阻止对商店的访问。

• Throughput：所有层中的 App Configuration 存储都具有吞吐量配额。 超出此限制的请求会收到 HTTP 状态代码为 429 的响应。

  免费层和开发人员层中的存储无法保证吞吐量。

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

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

  †运行率通常定义为在特定时间段内，App Configuration 存储不受限流条件下处理的请求的平均数量。

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

• Features：所有层都包含功能，包括使用 Microsoft 管理的密钥进行加密、通过访问密钥或 Microsoft Entra ID 进行身份验证、Azure 基于角色的访问控制（RBAC）、托管标识、服务标记和可用性区域冗余性。

  开发人员层还包括对Private Link的支持。

  标准和高级层提供更多功能，包括Private Link支持、使用客户管理的密钥进行加密、软删除保护和异地复制功能。

• 成本：使用免费层店铺无需任何费用。

  开发者等级存储每天收取使用费，其中包括当天前3,000个请求。 超出此每日分配的请求会产生超额费用。

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

  高级商店也收取每日使用费，并包括一个副本。 每日费用中包含每天前 800,000 个针对原始版本的请求和前 800,000 个针对副本版本的请求。 超出此每日分配的请求会产生超额费用。

你可以随时将应用配置存储升级，例如，从免费层级升级到开发人员层、标准层或高级层，或者从开发人员层或标准层升级到高级层。

您可以将应用配置存储从高级版降级到标准版，因为这两个版本都适合用于生产环境。 但是，不支持降级到非生产层，例如免费层。 为此，可以在所需的层中创建新存储，然后将 配置数据导入到该存储中。

在将 App Configuration 存储从高级层降级到标准层之前，请确保常规存储和快照存储的使用低于标准层的限制。 可以通过 Azure 门户中的 Azure 监视指标查看您的应用配置存储的“每日存储使用量”和“快照存储大小”来验证当前的使用情况。

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

Azure App Configuration支持 geo-replication，以提高区域中断的复原能力。

Azure App Configuration支持Azure availability zones来保护应用程序和数据免受单个数据中心故障的影响。 所有启用可用区的区域至少包含三个可用区，其中每个可用区都是物理独立的数据中心。 为提高复原能力，App Configuration中的此支持为所有客户启用，无需额外付费。 以下是App Configuration已启用可用性区域支持的区域。 有关详细信息，请参阅支持可用性区域的 Azure 区域。

以下是App Configuration已启用可用性区域支持的区域。

App Configuration 的存储根据其层具有不同的请求配额。 免费层的请求限制为每天 1,000 次，开发人员层限制为每小时 6,000 次，标准层限制为每小时 30,000 次，而高级层没有请求限制，确保不间断访问。

App Configuration 存储根据其所属层级具有吞吐量限制。 免费层和开发人员层存储无法保证吞吐量。 标准层存储支持的读取操作速率最高可达每秒 300 个请求 (RPS)，写入操作速率最高可达 60 RPS。 高级层存储支持的读取操作速率最高可达每秒 450 RPS，写入操作速率最高可达 100 RPS。

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

首先，让我们估算配置监视的请求数。 应用程序的每个实例都会每30秒向应用程序配置发送一次哨兵密钥请求，因此在一小时内会发送120（=3600/30）次请求。 假设有 50 个应用程序实例，那么应用程序每小时将发送 6,000 (=120x50) 个配置监视请求。 请注意，由于 Sentinel 键请求频繁且大多数保持不变，因此大部分不会计入标准层存储的每小时配额限制†。

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

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

*功能标志不使用 sentinel 密钥监视更改，并且独立于配置进行监视。 每次刷新间隔需要一个请求来监视每个 100 个功能标志。

†免费层存储的日请求限额中包括频繁和重复的请求，不会将其排除在外。

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

• 超出免费层级中商店的每日请求配额。
• 超出开发者层级中商店的每小时请求配额。
• 超出标准层商店的每小时请求配额。
• 超过任何层级中商店的吞吐量配额。
• 超出任意层中存储的带宽限制。
• 当存储配额超出时，尝试创建或修改键值。

检查 429 响应的正文，以了解请求失败的具体原因。 您还可以在 Azure Monitor 中收集 App Configuration 存储的日志，并为请求配额使用情况指标设置警报。

接收短暂的 HTTP 状态代码 429 响应通常不会造成任何伤害，因为 App Configuration 客户端能够正常处理它们。 但是，如果应用程序经常遇到 HTTP 状态代码为 429 的响应，请考虑采取以下措施：

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

请参阅 应用配置中客户端应用程序的最佳做法

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

标准层和高级层中的所有 App Configuration 存储都支持 soft-delete 功能，该功能无法禁用。 你可以在保持期内恢复已删除的存储。 按照以下说明恢复错误删除的 App Configuration 存储。

使用 活动日志查看谁访问或修改了您的 App Configuration 存储的控制平面。 使用 资源日志 标识访问数据平面的人员。

是。 虽然可以通过Azure portal或 CLI 在App Configuration中管理功能标志和Key Vault引用，但也可以使用 App Configuration SDK 以编程方式创建和更新它们。 因此，可以写入自定义管理门户，或者以编程方式在 CI/CD 中管理它们。 功能标志和Key Vault参考 API 在所有受支持的语言的 SDK 中可用。 请查看 示例链接，了解每种支持的语言的示例。

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

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

建议设置键值的标签以匹配 Spring 配置文件。 默认情况下，如果未显式设置标签筛选器，App Configuration 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 请求的属性评估功能标志。 这通常是通过检查HttpContext单例模式来执行的。 但是，此模式不适用于 Blazor 服务器应用程序，在这些应用程序中，应转而使用范围服务。 在这种情况下，应使用 AddScopedFeatureManagement 方法。

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

可以直接通过 GitHub 联系我们。

• About Azure App Configuration