外部配置存储模式

将配置信息从应用程序部署包移出，移到一个集中的位置。 这可以提供用于简化管理和控制配置数据，以及用于在应用程序和应用程序实例之间共享配置数据的机会。

上下文和问题

应用程序运行时环境的大部分包括随应用程序部署的文件中保留的配置信息。 在某些情况下，可以编辑这些文件，以在部署应用程序之后更改应用程序行为。 但是，对配置的更改需要重新部署应用程序，常常导致不可接受的停机和其他管理开销。

本地配置文件也将配置限制到单个应用程序，但有时在多个应用程序之间共享配置设置会很有用。 示例包括数据库连接字符串、UI 主题信息或一组相关应用程序使用的队列和存储的 URL。

跨多个正在运行的应用程序实例管理本地配置的更改具有挑战性，特别是在云托管方案中。 它可能导致在部署更新的过程中实例使用不同的配置设置。

此外，应用程序和组件的更新可能需要更改配置架构。 许多配置系统不支持不同版本的配置信息。

解决方案

将配置信息存储在外部存储中，并提供可用来快速、高效地读取和更新配置设置的接口。 外部存储的类型取决于应用程序的托管和运行时环境。 在云托管方案中，它通常是基于云的存储服务或专用配置服务，但也可以是托管数据库或其他自定义系统。

为配置信息选择的后备存储应有一个接口，该接口提供一致和易于使用的访问。 它应以正确类型化和结构化的格式公开信息。 实现可能还需要授予用户的访问权限，以保护配置数据，并有足够的灵活性以允许存储多个版本的配置（如开发、过渡或生产，包括每个版本的多个发行版）。

许多内置配置系统在应用程序启动时读取数据并在内存中缓存数据，以提供快速访问并最大程度减少对应用程序性能的影响。 根据所使用的后备存储的类型以及此存储的延迟，在外部配置存储中实现一种缓存机制可能会有用。 有关详细信息，请参阅缓存指南。 该图说明了具有可选本地存储的外部配置存储模式的概述。

问题和注意事项

在决定如何实现此模式时，请考虑以下几点：

选择提供可接受的性能、高可用性、可靠性，并可以作为应用程序维护和管理过程的一部分进行备份的后备存储。 在云托管应用程序中，使用云存储机制或专用配置平台服务通常是满足这些要求不错的选择。

设计后备存储的架构，以使它可保留的信息类型具有灵活性。 确保它提供所有配置要求，如类型化的数据、设置的集合、多个版本的设置以及应用程序使用它需要的任何其他功能。 架构应该易于扩展，以在需求发生变化时支持其他设置。

请考虑后备存储的物理容量、它与存储配置信息的方式的关系，以及对性能的影响。 例如，存储包含配置信息的 XML 文档将需要配置界面或应用程序分析文档，以便读取各个设置。 它将使更新设置变得更复杂，尽管缓存设置可有助于抵消较慢的读取性能。

请考虑配置界面将如何允许控制配置设置的作用域和继承。 例如，可能要求将配置设置限定在组织、应用程序和计算机级别。 它可能需要对不同作用域的访问支持控制委派，并阻止或允许各个应用程序替代设置。

确保配置界面可以所需的格式（如类型化的值、集合、键/值对或属性包）公开配置数据。

请考虑当设置包含错误，或不存在于后备存储中时，配置存储接口的行为方式。 可能返回默认设置并记录错误比较合适。 此外，考虑配置设置密钥或名称的区分大小写、二进制数据的存储和处理以及处理 null 值或空值的方法等方面。

考虑如何保护配置数据以允许仅访问相应的用户和应用程序。 这可能是配置存储接口的一项功能，但还需要确保在没有适当权限的情况下不能直接访问后备存储中的数据。 确保严格分离读取配置数据和写入配置数据所需的权限。 还要考虑是否需要加密部分或全部配置设置，以及将如何在配置存储接口中实现这一操作。

在运行过程中会更改应用程序行为的集中存储的配置至关重要，应该使用与部署应用程序代码相同的机制部署、更新和管理它们。 例如，可能会影响多个应用程序的更改必须使用完整的测试和暂存部署方法执行，以确保更改适合使用此配置的所有应用程序。 如果管理员编辑某项设置以更新一个应用程序，则它可能对使用该同一设置的应用程序产生负面影响。

如果应用程序缓存配置信息，则需要在配置更改时警告应用程序。 可以对缓存的配置数据实现过期策略，以便定期自动刷新此信息和选取（以及操作）任何更改。

虽然缓存配置数据有助于解决应用程序运行时外部配置存储的暂时性连接问题，但如果应用程序首次启动时外部存储已关闭，这通常无法解决问题。 如果应用程序启动时无法检索实时值，请确保应用程序部署管道可以在配置文件中提供最后一组已知配置值作为回退。

何时使用此模式

此模式适合用于：

• 在多个应用程序和应用程序实例之间共享的配置设置，或必须在多个应用程序和应用程序实例之间实施标准配置的情况。

• 不支持所有所需配置设置的标准配置系统，如存储图像或复杂数据类型。

• 作为应用程序的某些设置的互补存储，可能允许应用程序重写部分或全部集中存储的设置。

• 记录配置存储的部分或全部访问类型，可作为简化管理多个应用程序的一种方法，也可选用于监视配置设置的使用情况。

工作负荷设计

架构师应评估如何在其工作负荷的设计中使用“外部配置存储模式”，以解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

自定义后备存储示例

在 Microsoft Azure 托管应用程序中，在外部存储配置信息的一种可能选择是使用 Azure 存储。 这是弹性的、提供高性能，并通过自动故障转移复制三次，以提供高可用性。 Azure 表存储提供键/值存储以及对值使用灵活架构的功能。 Azure Blob 存储提供分层的、基于容器的存储，可在单独命名的 blob 中存储任何类型的数据。

实现此模式时，你将负责抽象 Azure Blob 存储并在应用程序中公开设置，包括检查运行时更新并解决如何响应这些更新的问题。

以下示例展示了如何通过 Blob 存储假设简单的配置存储来存储和公开配置信息。 BlobSettingsStore 类可以抽象 Blob 存储来保存配置信息，并实现一个简单的 ISettingsStore 接口。

public interface ISettingsStore
{
    Task<ETag> GetVersionAsync();
    Task<Dictionary<string, string>> FindAllAsync();
}

此接口定义了用于检索配置存储中保存的配置设置的方法，并包括一个版本号，该版本号可用于检测最近是否修改了任何配置设置。 BlobSettingsStore 类可使用 Blob 的 ETag 属性实施版本控制。 每次写入 Blob 时会自动更新 ETag 属性。

根据设计，这个简单的插图将所有配置设置公开为字符串值而不是键入值。

然后，ExternalConfigurationManager 类可以为 BlobSettingsStore 实例提供包装器。 应用程序可以使用此类来检索配置信息。 此类可能会使用 Microsoft 响应式扩展之类的内容来发布系统运行时对配置所做的任何更改。 它还将负责为设置实现 缓存端模式，以提供额外的复原能力和性能。

使用情况可能如下所示。

static void Main(string[] args)
{
    // Start monitoring configuration changes.
    ExternalConfiguration.Instance.StartMonitor();

    // Get a setting.
    var setting = ExternalConfiguration.Instance.GetAppSetting("someSettingKey");
    …
}

使用 Azure 应用程序配置

在某些情况下，虽然可能需要构建自定义配置存储，但许多应用程序可以改为使用 Azure 应用程序配置。 Azure 应用程序配置支持可以作为命名空间的键值对。 键是键入的，并单独进行版本控制。 Azure 应用程序配置还支持配置的时间点快照，以便可以轻松检查甚至回滚到以前的配置值。 可以导出配置值，以便在应用程序启动时无法访问服务的情况下，可以随应用程序一起提供配置副本。

客户端库

其中许多功能是通过与应用程序运行时集成的客户端库公开的，以便于提取值和缓存值、在更改时刷新值，甚至处理应用程序配置服务的暂时性中断。

除了客户端库，还有 Azure 应用程序配置同步 GitHub Action 以及 Azure 应用程序配置拉取和 Azure 应用程序配置推送 Azure DevOps 任务，用于将配置步骤集成到生成过程中。

后续步骤

• 请参阅其他应用程序配置示例
• 了解如何将 Azure 应用程序配置与 Kubernetes 部署集成
• 了解 Azure 应用程序配置如何帮助管理功能标记