将配置信息从应用程序部署包移出,移到一个集中的位置。 这可以提供用于简化管理和控制配置数据,以及用于在应用程序和应用程序实例之间共享配置数据的机会。
应用程序运行时环境的大部分包括随应用程序部署的文件中保留的配置信息。 在某些情况下,可以编辑这些文件,以在部署应用程序之后更改应用程序行为。 但是,对配置的更改需要重新部署应用程序,常常导致不可接受的停机和其他管理开销。
本地配置文件也将配置限制到单个应用程序,但有时在多个应用程序之间共享配置设置会很有用。 示例包括数据库连接字符串、UI 主题信息或一组相关应用程序使用的队列和存储的 URL。
跨多个正在运行的应用程序实例管理本地配置的更改具有挑战性,特别是在云托管方案中。 它可能导致在部署更新的过程中实例使用不同的配置设置。
此外,应用程序和组件的更新可能需要更改配置架构。 许多配置系统不支持不同版本的配置信息。
将配置信息存储在外部存储中,并提供可用来快速、高效地读取和更新配置设置的接口。 外部存储的类型取决于应用程序的托管和运行时环境。 在云托管方案中,它通常是一种基于云的存储服务,但可能是托管数据库或其他系统。
为配置信息选择的后备存储应有一个接口,该接口提供一致和易于使用的访问。 它应以正确类型化和结构化的格式公开信息。 实现可能还需要授予用户的访问权限,以便保护配置数据,并有足够的灵活性以允许存储多个版本的配置(如开发、过渡或生产,包括每一个的多个发行版)。
许多内置配置系统在应用程序启动时读取数据并在内存中缓存数据,以提供快速访问并最大程度减少对应用程序性能的影响。 根据所使用的后备存储的类型以及此存储的延迟,在外部配置存储中实现一种缓存机制可能会有用。 有关详细信息,请参阅缓存指南。 该图说明了具有可选本地存储的外部配置存储模式的概述。
在决定如何实现此模式时,请考虑以下几点:
选择提供可接受的性能、高可用性、可靠性,并可以作为应用程序维护和管理过程的一部分进行备份的后备存储。 在云托管应用程序中,使用云存储机制通常是满足这些需求的不错选择。
设计后备存储的架构,以使它可保留的信息类型具有灵活性。 确保它提供所有配置要求,如类型化的数据、设置的集合、多个版本的设置以及应用程序使用它需要的任何其他功能。 架构应该易于扩展,以在需求发生变化时支持其他设置。
请考虑后备存储的物理容量、它与存储配置信息的方式的关系,以及对性能的影响。 例如,存储包含配置信息的 XML 文档将需要配置界面或应用程序分析文档,以便读取各个设置。 它将使更新设置变得更复杂,尽管缓存设置可有助于抵消较慢的读取性能。
请考虑配置界面将如何允许控制配置设置的作用域和继承。 例如,可能要求将配置设置限定在组织、应用程序和计算机级别。 它可能需要对不同作用域的访问支持控制委派,并阻止或允许各个应用程序替代设置。
确保配置界面可以所需的格式(如类型化的值、集合、键/值对或属性包)公开配置数据。
请考虑当设置包含错误,或不存在于后备存储中时,配置存储接口的行为方式。 可能返回默认设置并记录错误比较合适。 此外,考虑配置设置密钥或名称的区分大小写、二进制数据的存储和处理以及处理 null 值或空值的方法等方面。
考虑如何保护配置数据以允许仅访问相应的用户和应用程序。 这可能是配置存储接口的一项功能,但还需要确保在没有适当权限的情况下不能直接访问后备存储中的数据。 确保严格分离读取配置数据和写入配置数据所需的权限。 还要考虑是否需要加密部分或全部配置设置,以及将如何在配置存储接口中实现这一操作。
在运行过程中会更改应用程序行为的集中存储的配置至关重要,应该使用与部署应用程序代码相同的机制部署、更新和管理它们。 例如,可能会影响多个应用程序的更改必须使用完整的测试和暂存部署方法执行,以确保更改适合使用此配置的所有应用程序。 如果管理员编辑某项设置以更新一个应用程序,则它可能对使用该同一设置的应用程序产生负面影响。
如果应用程序缓存配置信息,则需要在配置更改时警告应用程序。 可以对缓存的配置数据实现过期策略,以便定期自动刷新此信息和选取(以及操作)任何更改。
此模式适合用于: