Leer en inglés

Compartir a través de

Azure 应用程序配置最佳做法

本文介绍了使用 Azure 应用程序配置时的常见模式和最佳做法。

键分组

应用程序配置提供了两个用于组织键的选项:

  • 键前缀
  • 标签

可以使用一个或两个选项对键进行分组。

键前缀 允许你在其名称中使用通用前缀对相关键进行分组。 前缀可以包含由分隔符分隔的多个段,例如/:,或构成分层命名空间。 在单个应用程序配置存储中存储多个应用程序或微服务的配置密钥时,此方法非常有用。

请务必记住,应用程序代码直接引用密钥以检索相应的值。 因此,密钥应保持稳定,以避免代码更改。 如果需要,可以使用应用配置提供程序在运行时剪裁密钥前缀。

使用标签 可以创建密钥的变体,例如不同版本或特定于环境的设置。 通过分配标签,可以维护同一键的多个值。 然后,应用程序可以通过指定相应的标签来检索不同的键值集,从而允许代码中的密钥引用保持一致。

键-值组合

应用配置将存储在其中的每个密钥视为独立实体。 它不会根据密钥层次结构推断键之间的关系或继承值。 但是,通过使用标签与应用程序中的配置堆叠相结合,可以有效地聚合多个密钥集。

假设有一个名为 TestApp:MySetting 的配置设置,其值因环境而异。 可以创建两个具有相同名称的键,但分配不同的标签,其中一个没有标签(默认值)和另一个标记为 “开发”。 未标记的键保留默认值,而标记的键包含特定于环境的值。

在应用程序代码中,首先加载默认(未标记)键值,然后使用 开发 标签加载特定于环境的键值。 加载第二个集时,任何匹配的键将覆盖以前加载的值。 此方法允许“堆叠”多个配置集,最后一个加载的值优先。 支持的语言和平台中的应用配置提供程序提供这种堆叠功能。

以下示例演示如何在 .NET 应用程序中实现键值组合:

configBuilder.AddAzureAppConfiguration(options => {
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and compose with two different labels
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .Select(keyFilter: "TestApp:*", labelFilter: "Development");
});

使用标签为不同环境启用不同配置提供一个完整的示例。

配置刷新

Azure 应用配置支持动态配置刷新,而无需重启应用程序。 应用配置提供程序可以使用两种方法监视配置更改:

监视所有选定的密钥

在此方法中,提供程序监视所有选定的密钥。 如果在任何选定的键值中检测到更改,则会重新加载整个配置。 此方法可确保即时更新,而无需进行其他密钥修改。

下面是使用 .NET 的示例:

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh when any selected key changes.
               refreshOptions.RegisterAll();
           });
});

监视哨兵密钥

或者,您可以监控单个键,这通常被称为 sentinel 键。 更新多个键值时,此方法非常有用。 只有在完成所有其他配置更改后才会更新 sentinel 密钥,可确保应用程序仅重新加载配置一次,从而保持一致性。

下面是使用 .NET 的示例:

configBuilder.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
           // Load all keys that start with `TestApp:` and have no label
           .Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
           .ConfigureRefresh(refreshOptions =>
           {
               // Trigger full configuration refresh only if the `SentinelKey` changes.
               refreshOptions.Register("SentinelKey", refreshAll: true);
           });
});

这两种方案可以通过在各种语言和平台上支持的应用配置提供商获得。

若要降低配置不一致的风险,请使用 配置快照 来确保配置完整性。

对外部数据的引用

应用程序配置旨在存储通常保存在配置文件或环境变量中的任何配置数据。 但是,某些类型的数据可能更适合驻留在其他源中。 例如,将机密存储在 Key Vault 中,将文件存储在 Azure 存储中,将成员资格信息存储在 Microsoft Entra 组中,或者将客户列表存储在数据库中。

可以通过以键值方式保存对外部数据的引用,仍然利用应用程序配置。 可以使用内容类型来区分每个数据源。 当应用程序读取引用时,它会从引用的源中加载实际数据,前提是该应用程序具有对源的必要权限。 如果更改外部数据的位置,只需在应用程序配置中更新引用,而无需更新并重新部署整个应用程序。

应用程序配置 Key Vault 引用功能就是这样一个例子。 它允许在必要时更新应用程序所需的机密,而基础机密本身仍保留在 Key Vault 中。

应用程序配置启动

若要访问 Azure 应用配置存储区,可以使用连接字符串或Microsoft Entra ID 进行身份验证。 虽然连接字符串在 Azure 门户中随时可用,但它们包含凭据信息,并且必须被视为机密。 如果选择此方法,请将连接字符串安全地存储在 Azure Key Vault 中,并确保应用程序向 Key Vault 进行身份验证以检索它。

更安全和建议的方法是使用 Microsoft Entra ID 身份验证。 如果应用程序托管在 Azure 中,例如 Azure Kubernetes 服务、应用服务或 Azure Functions,则可以使用由 Microsoft Entra ID 提供的托管标识。 托管标识消除显式管理机密的需要。 使用此方法,应用程序只需要应用程序配置终结点 URL,该 URL 可以安全地嵌入应用程序代码或配置文件中。

有关详细信息,请参阅使用托管标识访问应用配置

Azure Kubernetes 服务对应用配置的访问权限

托管在 Azure Kubernetes 服务 (AKS) 中的工作负荷可使用以下选项访问 Azure 应用程序配置。 这些选项通常也适用于 Kubernetes。

  • Azure 应用程序配置 Kubernetes 提供程序添加到 AKS 群集。 Kubernetes 提供程序在群集中作为 Pod 运行。 它可以根据应用程序配置商店中的键值和 Key Vault 引用来构建 ConfigMap 和机密。 ConfigMap 和机密可作为环境变量或装载的文件使用,无需修改应用程序代码。 如果有多个应用程序在同一 AKS 群集中运行,则它们都可以访问生成的 ConfigMap 和机密,无需分别对应用配置发出请求。 Kubernetes 提供程序还支持动态配置更新。 如果可行,建议使用此选项。

  • 更新应用程序以使用 Azure 应用程序配置提供程序库。 提供程序库在许多框架和语言中可用,例如 ASP.NET.NETJava SpringJavaScript/Node.jsPython。 此方法使你能够完全访问应用配置的功能,其中包括动态配置和功能管理。 可以精细控制每个应用程序要加载哪些数据,以及从哪个应用配置存储加载数据。

  • 使用 Helm 来与 Kubernetes 部署集成 如果不想更新应用程序或向 AKS 群集添加新 Pod,可以选择使用 Helm 通过部署将数据从应用配置引入 Kubernetes 群集。 此方法使应用程序能够继续从 Kubernetes 变量和机密访问配置。 每当希望应用程序合并新的配置更改时,都可以运行 Helm 升级。

通过应用服务或 Azure Functions 访问应用配置

使用应用配置提供程序或 SDK 库直接在应用程序中访问应用配置。 此方法使你能够完全访问应用配置的功能,其中包括动态配置和功能管理。 在应用服务或 Azure Functions 上运行的应用程序可以通过以下任一方法获取对应用配置存储的访问权限:

  • 在应用服务或 Azure Functions 上启用托管标识,并向其授予对应用配置存储的访问权限。 有关详细信息,请参阅使用托管标识访问应用配置
  • 在应用服务或 Azure Functions 的“应用程序设置”中存储应用配置存储的连接字符串。 为了增强安全性,请将连接字符串存储在 Key Vault 中,并从应用服务或 Azure Functions 引用它

还可以将应用配置数据作为“应用程序设置”或环境变量,使之可供应用程序访问。 使用此方法,可以避免更改应用程序代码。

减少对应用程序配置发出的请求

对应用程序配置的请求过多可能会导致限制或超额费用。 若要减少发出的请求数,方法如下:

  • 增加刷新间隔,尤其是在配置值不频繁更改时。 使用 SetRefreshInterval 方法指定新的刷新间隔。

  • 集中监视一个 sentinel 键,而不是监视独立的多个键。 仅当 sentinel 键更改时才刷新所有配置。 有关示例,请参阅在 ASP.NET Core 应用中使用动态配置

  • 如果在 Kubernetes 群集中运行多个工作负荷,并且每个工作负荷都单独从应用配置中拉取数据,请使用应用配置 Kubernetes 提供程序。 Kubernetes 提供程序从应用配置中检索数据并将其作为 Kubernetes ConfigMaps 和机密提供。 这样工作负荷就可以通过 ConfigMaps 和机密访问数据,无需单独从应用配置中拉取数据。

  • 启用应用程序配置存储的异地复制,并将请求分散到多个副本。 例如,为全局部署的应用程序使用每个地理区域的不同副本。 每个应用程序配置副本都有各自的请求配额。 此设置提供了一个模型,可针对暂时性和区域性中断提供可伸缩性和增强的复原能力。

将配置数据导入到应用程序配置中

应用程序配置提供了使用 Azure 门户或 CLI 从当前配置文件批量导入配置设置的选项。 还可以使用相同的选项从应用程序配置中导出键值,例如在相关存储之间导出键值。 如果你已采用“配置即代码”并在 GitHub 或 Azure DevOps 中管理配置,则可以使用 GitHub Actions,设置正在进行的配置文件导入。

应用程序配置中的多区域部署

如果应用程序部署在多个区域中,建议启用应用程序配置存储的异地复制。 可以让应用程序主要连接到与部署应用程序实例的区域匹配的副本,并允许它们故障转移到其他区域中的副本。 此设置可最大程度地减少应用程序和应用程序配置之间的延迟,在每个副本具有单独的限制配额时分散负载,并增强应用程序对暂时性和区域性中断的复原能力。 有关详细信息,请参阅 复原和灾难恢复

构建具有高复原能力的应用

应用通常依赖配置来启动,这使得 Azure 应用程序配置的高可用性至关重要。 为了提高复原能力,应用程序应使用应用配置的可靠性功能,并考虑根据具体要求采取以下措施。

  • 在具有 Azure 可用性区域支持的区域中进行设置。 可用性区域使应用程序能够恢复数据中心中断。 应用程序配置为所有客户提供区域冗余,无需任何额外费用。 建议在具有可用性区域支持的区域创建应用程序配置存储区。 可以找到应用程序配置已启用可用性区域支持的区域列表
  • 启用异地复制,并允许应用程序在副本之间进行故障转移或分发负载。 此设置提供了可伸缩性模型,并增强了针对临时失败和区域性中断的复原能力。 有关详细信息,请参阅 复原和灾难恢复
  • 使用安全部署做法部署配置。 不正确或意外的配置更改经常会导致应用程序故障时间。 应该尽可能避免直接从 Azure 门户进行影响生产的配置更改。 在安全部署实践 (SDP) 中,使用渐进暴露部署模型来最大限度地减少部署引发问题的潜在爆炸半径。 如果采用 SDP,可以在将配置快照部署到生产环境之前构建并测试它。 在部署期间,可以更新应用程序的实例以逐渐获取新快照。 如果检测到问题,可以通过重新部署最后一个已知良好 (LKG) 快照来回滚更改。 快照是不可变的,保证了所有部署的一致性。 可以将快照与动态配置一起使用。 使用快照进行基础配置,使用动态配置进行紧急配置替代和功能标志。
  • 将配置包含在应用程序中。 如果希望确保应用程序始终可以访问配置的副本,或者如果希望完全避免应用程序配置上的运行时依赖项,可以在构建或发布期间从应用程序配置中拉取配置,并将其包含在应用程序中。 要了解更多信息,请查看将应用程序配置与 CI/CD 管道Kubernetes 部署集成的示例。
  • 使用应用程序配置提供程序。 应用程序在实现高复原能力方面发挥着关键作用,因为它们可以解决运行时出现的问题,如网络问题,并更快地对失败做出响应。 应用程序配置提供程序提供了一系列内置的复原能力功能,包括自动副本发现、副本故障转移、具有可自定义超时的启动重试、配置缓存以及用于可靠配置刷新的自适应策略。 强烈建议使用应用程序配置提供程序以从这些功能中获益。 如果不能这样做,则应考虑在自定义解决方案中实现类似的功能,以实现最高级别的复原能力。

应用配置中的客户端应用程序

在客户端应用程序中使用应用配置时,请确保考虑两个主要因素。 第一,如果要在客户端应用程序中使用连接字符串,则存在向公众公开应用配置存储的访问密钥的风险。 第二,客户端应用程序的典型规模可能会导致向应用配置存储发出的请求过多,这可能会导致费用超额或导致限制。 有关限制的详细信息,请参阅常见问题解答

为了解决这些问题,建议在客户端应用程序和应用配置存储之间使用代理服务。 该代理服务可以安全地向应用配置存储进行身份验证,而不会有泄露身份验证信息的安全问题。 可以通过使用应用配置提供程序库之一来生成代理服务,这样就可以利用内置缓存和刷新功能来优化发送到应用配置的请求量。 若要详细了解如何使用应用配置提供程序,请参阅快速入门和教程中的文章。 该代理服务会将其缓存中的配置提供给客户端应用程序,这样你就可以避免此部分介绍的两个潜在问题。

应用配置中的多租户应用程序

多租户应用程序基于一个体系结构构建,其中应用程序的共享实例服务于多个客户或租户。 例如,你可能有一个电子邮件服务,可为用户提供单独的帐户和自定义体验。 应用程序通常为每个租户管理不同的配置。 以下是有关在多租户应用程序中使用应用配置的一些体系结构注意事项。

配置即代码

配置即代码是一种管理源代码控制系统(例如 git 存储库)下的配置文件的操作。 使用它可提供很多好处:可跟踪性和任何配置更改的批准流程等。 如果你采用配置作为代码,应用程序配置具备工具,可用于帮助管理文件中的配置数据,并将这些数据部署为你的内部版本、发行版本或 CI/CD 流程的一部分。 这样,应用程序就可以从应用配置存储访问最新数据。

  • 对于 GitHub,可以使用 GitHub Actions 将配置文件从 GitHub 存储库导入到应用配置存储中
  • 对于 Azure DevOps,可以在生成或发布管道中包含 Azure 应用程序配置推送(Azure 管道任务)以进行数据同步。
  • 对于其他人,可以使用 Azure CLI 将配置文件导入到应用配置,作为 CI/CD 系统的一部分。 有关详细信息,请参阅 az appconfig kv import

使用此模型,你可以在将数据提交到应用程序配置之前添加验证和测试步骤。 如果使用多个应用程序配置存储,则还可以将配置数据以增量方式或一次性全部推送给它们。

后续步骤