本文解答有关 Azure 应用程序配置的常见问题。
“应用程序配置”与 Azure Key Vault 有什么不同？
应用程序配置可帮助开发人员管理应用程序设置和控制功能可用性。 它旨在简化处理复杂配置数据的许多任务。
应用程序配置支持：
- 分层命名空间
- 标记
- 广泛的查询
- 批量检索
- 专用管理操作
- 功能管理用户界面
应用程序配置对 Key Vault 进行补充，而它们应在大多数应用程序部署中并行使用。
我应该在应用程序配置中存储机密吗？
尽管应用程序配置提供了强化的安全性，但 Key Vault 仍然是存储应用程序机密的最佳位置。 Key Vault 提供硬件级加密、粒度访问策略和管理操作（如证书轮换）。
你可以创建引用 Key Vault 中存储的机密的应用程序配置键值。 有关详细信息，请参阅在 ASP.NET Core 应用中使用 Key Vault 引用。
应用程序配置是否加密我的数据？
是。 应用程序配置始终加密所有传输中的数据和静态数据。 所有网络通信都通过 TLS 1.2 或 TLS 1.3 进行。 应用配置支持使用 Azure 管理的密钥或客户管理的密钥进行静态加密。
应用程序配置与 Azure 应用服务有什么不同？
通过 Azure 应用服务，可以为每个应用服务实例定义应用设置。 这些设置作为环境变量传递给应用程序代码。 如果需要，可以将设置与特定部署槽关联。 有关详细信息，请参阅配置应用设置。
而通过 Azure 应用程序配置，你能够定义可在多个应用之间共享的设置。 这包括在应用服务中运行的应用以及其他平台。 应用程序代码通过面向 .NET 和 Java 的配置提供程序、通过 Azure SDK 或直接通过 REST API 访问这些设置。
可以在应用服务的应用程序设置中添加对应用程序配置数据的引用。 还可以在应用服务与应用程序配置之间导入和导出设置。 利用此功能，可以根据现有的应用服务设置快速设置新的应用程序配置存储区。 还可以与依赖于应用服务设置的现有应用共享配置。
应用程序配置中存储的键和值是否有任何大小限制？
单个键值的限制为 10 KB，包括标签、内容类型、标记和其他元数据等属性。
对于大多数应用程序中的单个设置，此限制应该足够了。 如果你发现设置大于此限制，可以考虑将数据存储在其他地方，并在应用程序配置中添加对该数据的引用。
有关详细信息，请参阅 Azure 订阅和服务限制。
我应该如何存储多个环境（测试、暂存、生产等）的配置？
你可以控制谁可以在每存储级别（按存储）访问应用程序配置。 对于需要不同权限的每个环境，请使用单独的存储区。 此方法可提供最佳的安全隔离。
如果不需要环境之间的安全隔离，可以使用标签来区分配置值。 使用标签为不同环境启用不同配置提供一个完整的示例。
建议的应用程序配置使用方法有哪些？
请参阅最佳做法。
应用程序配置的成本是多少？
目前有两种定价层：
- 免费层
- 标准层
如果你在引入标准层之前创建了存储，则它会在功能正式可用后自动转入免费层。 可以选择升级到标准层，也可以继续使用免费层。
你不能将存储从标准层降级到免费层。 你可以在免费层中创建新存储，然后将配置数据导入该存储。
我应该使用哪个应用程序配置层？
两个应用程序配置层都提供核心功能，包括配置设置、功能标志、Key Vault 引用、配置快照、基本管理操作、指标和日志。
以下是有关选择层的注意事项。
每个订阅的资源数：资源由单个配置存储区组成。 每个区域的每个订阅在免费层中只能有一个配置存储区。 订阅在标准层中可以有无限数量的配置存储区。
每个资源的存储：在免费层中，每个配置存储的常规存储上限为 10MB，快照存储上限为 10MB。 在标准层中，每个配置存储最多可以使用 1GB 的常规存储，以及额外 1GB 的快照存储。
修订历史记录：“应用程序配置”会存储对键所做的所有更改的历史记录。 在免费层中，会存储七天的历史记录。 在标准层中，此历史记录存储 30 天。
请求配额：免费层存储限每日 1,000 个请求。 当存储达到 1,000 个请求时，它会针对所有请求返回 HTTP 状态代码 429，直到 UTC 午夜时间。
标准层存储限制为每小时 30,000 个请求。 每小时的配额用尽后，请求可能返回 HTTP 状态代码 429，指示请求过多，直到该小时结束。 随着发送的请求数超过配额，百分比升高，可能会返回状态代码 429。
服务级别协议：标准层具有 99.9% 可用性的服务级别协议，启用异地复制时，可用性为 99.95%。 免费层没有 SLA。
功能：这两层都包含功能，包括使用 Azure 托管密钥进行加密、通过访问密钥或 Microsoft Entra ID 进行身份验证、Azure 基于角色的访问控制 (RBAC)、托管标识、服务标记和可用性区域冗余。 标准层提供的功能更多，其中包括专用链接支持、使用客户管理的密钥进行加密、软删除保护和异地复制功能。
成本：标准层存储每日收取使用费。 每日前 200,000 个请求包含在每日费用中。 对超过每日配额的请求也收取超额费用。 免费层的存储可免费使用。
我可以将存储从免费层升级到标准层吗？ 我可以将存储从标准层降级到免费层吗？
你可以随时从免费层升级到标准层。
你不能将存储从标准层降级到免费层。 你可以在免费层中创建新存储，然后将配置数据导入该存储。
应用配置中存储的数据位于何处？
应用程序配置中存储的客户数据位于创建客户应用程序配置存储的区域中。 仅当客户为另一个区域启用了异地复制时，客户数据才会复制到该区域。 这适用于所有可用区域。 客户可从全球任何位置移动、复制或访问其数据。
应用配置如何确保数据的高可用性？
Azure 应用程序配置支持异地复制，以提高应对区域性服务中断的复原能力。
Azure 应用配置支持 Azure 可用性区域，可以保护应用程序和数据免受单个数据中心故障的影响。 所有启用可用性区域的地区至少包含 3 个可用性区域，其中每个可用性区域都是物理意义上独立的数据中心。 为实现复原能力，可为所有客户启用应用配置中的此支持，而无需额外付费。 下面是应用程序配置启用了可用性区域支持的区域。 有关详细信息，请参阅 Azure 中的区域和可用性区域。
下面是应用配置启用了可用性区域支持的区域。
| 亚太区 |
|---|
| 中国北部 3 |
对应用程序配置发出的请求数有任何限制吗？
免费层中的配置存储区限每日 1,000 个请求。 请求速率超过每小时 30,000 个请求时，标准层中的配置存储可能会遇到临时限制。
存储达到其在标准层中的限制时，它可能会对发出的某些请求返回 HTTP 状态代码 429，直至该小时结束。 响应中的 retry-after-ms 标头在重试请求之前会给出建议的等待时间（以毫秒为单位）。
如果应用程序经常遇到 HTTP 状态代码 429 响应，请考虑重新设计它以减少发出的请求数。 有关详细信息，请参阅如何减少应用程序配置请求数。
我的应用程序接收到 HTTP 状态代码 429 响应。 为什么？
在以下情况下，会收到 HTTP 状态代码 429 响应：
- 超出了免费层中存储量的每日请求限额。
- 超出了标准层中存储量的每小时请求限额。
- 由于请求大量突发而出现暂时性限制†。
- 由于带宽使用量过高而导致的暂时性限制†。
- 在超过存储配额时尝试创建或修改密钥。
检查 429 响应的正文，以了解请求失败的具体原因。
†如果某个配置存储收到大量突发性请求或传输了大量数据，则可能会面临暂时性限制。 应用程序配置客户端（如 Azure SDK、配置提供程序库和 Azure Pipelines 任务）会自动重试受限制的请求。 对于使用这些客户端之一的任何应用程序，或会重试受限请求的自定义客户端，如果发生此暂时性限制，应不会受影响。
如何估算我的应用程序可以向应用程序配置发送的请求数？
让我们举个例子，假设你的应用程序具有 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) 个请求将使用可用的每小时配额。 更新此示例中的数字以相应地匹配特定的设置和设计，以便有足够的缓冲区来应对每小时的限制。 有关详细信息，请参阅如何减少应用程序配置请求数。
†免费层存储不从其每日限制中排除频繁、重复的请求。
为何无法创建与我刚刚删除的应用程序配置存储同名的应用程序配置存储？
标准层中的所有应用程序配置存储都自动启用了软删除功能。 删除标准层应用程序配置存储后，该存储的名称会在保持期内保留。 若要在保持期到期之前重新创建同名的存储，需要先清除软删除的存储，前提是该存储未启用清除保护。 如果启用了清除保护，则必须等待保持期结束。 如果经常需要重新创建同名的存储，请使用清除功能或设置较短的保持期。 需要重新创建具有相同名称的存储的工作流应在清除配置存储和执行后续创建之间留出一小时的时间。 之所以有此建议，是因为请求清除后，配置存储资源的实际清理会异步执行，这需要一些额外的时间才能完成。 为避免等待，建议为创建临时配置存储的工作流使用唯一名称。
如何还原不小心删除的应用程序配置存储？
能否以编程方式创建和更新功能标志或 Key Vault 引用？
是的。 可以通过 Azure 门户或 CLI 在应用程序配置中管理功能标志和 Key Vault 引用，同时也可以使用应用程序配置 SDK 以编程方式创建和更新它们。 因此，可以写入自定义管理门户，或者以编程方式在 CI/CD 中管理它们。 功能标志和 Key Vault 参引用 API 在所有受支持语言的 SDK 中都可用。 查看示例链接，获取每种受支持语言的示例。
在应用程序中评估和使用功能标志需要应用程序配置提供程序和功能管理库，这些库在 .NET 和 Java Spring 中提供。 查看快速入门和教程下的“功能管理”部分，了解更多信息。
如何在应用程序配置中使用 Java Spring 配置文件？
Spring 配置文件提供了一种分离应用程序部分（包括配置）的方法，并使其仅在特定环境或使用特定库时可用。
建议设置键值的标签以匹配 Spring 配置文件。 默认情况下，如果未显式设置标签筛选器，应用程序配置 Spring 提供程序库将加载带有标签与当前活动的 Spring 配置文件匹配的键值 (${spring.profiles.active})。 如果未设置活动的 Spring 配置文件，则将加载具有“无标签”的键值。
例如，对于配置文件 dev 和 prod，可以相应地使用以下标签创建键值。
| 密钥 | Label | 值 |
|---|---|---|
| /application/config.message | 开发人员 | Hello from dev |
| /application/config.message | prod | Hello from 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 配置文件匹配的键。 找到重复键时，优先选择最右边的标签。
如何在 Blazor 应用程序中启用功能管理，或者在 .NET 应用程序中作为范围服务启用？
从版本 3.1.0 开始，Microsoft.FeatureManagement 库支持将功能管理服务（包括功能筛选器）作为基于依赖项注入的 .NET 应用程序中的范围服务运行。 只需将代码中的 AddFeatureManagement 调用替换为 AddScopedFeatureManagement 即可利用此功能，如以下代码片段所示：
services.AddScopedFeatureManagement();
功能筛选器可以根据 HTTP 请求的属性评估功能标志。 这通常是通过单一实例 IHttpContextAccessor 模式检查 HttpContext 来执行的。 但是，此模式不适用于 Blazor 服务器应用程序，在这些应用程序中，应转而使用范围服务。 在这种情况下，应使用 AddScopedFeatureManagement 方法。
如何接收有关新版本的公告以及与应用程序配置相关的其他信息？
订阅我们的 GitHub 公告存储库。
如何报告问题或提供建议？
可以直接在 GitHub 上联系我们。