处理大量结构化配置/属性文件的最佳实践

想象一下一个具有大量服务器的系统。它们每个都有许多设置：

• 一些特定于服务器的
• 一些特定于该地区的
• 他们之间有些共同点
• 也许您可以进行一些自定义分组，例如这组服务器仅用于读取
• 等等

我想到的当前实践是具有压倒性能力的简单属性结构。

让我们以Google服务器为例。其中每个都有一个要加载的设置列表。

例如，伦敦服务器可能具有：

rootsettings.properties，europesettings.properties，londonsettings.properties，searchengine.properties，等。

每个文件都包含一组属性，并且加载顺序使您可以覆盖属性，您可以走得更远。

举例来说：rootsettings.properties可有accessible=false作为默认，但重写在searchengine.properties与accessible=true

我在使用此结构时遇到的问题是，很容易失控。它根本不是结构化的，这意味着您可以在任何级别定义任何属性，并且许多项目可能会过时。

此外，随着网络的增长，更改中间级别变得不可能了，因为您现在影响了非常多的服务器。

最后但并非最不重要的一点是，每个单独的实例可能需要1个特殊属性，这意味着您的树最终还是为每个服务器配置了一个配置，这使其不是最佳解决方案。

如果您对更好的配置管理体系结构有任何建议/想法，将不胜感激。

我认为您需要先问自己一些问题，弄清楚一些要点，然后才能更好地决定如何解决问题。

第一：谁来控制服务器？

• 是要控制数百台服务器的单一管理员吗？然后，您需要尽可能集中配置。

• 还是每个服务器都可能受到单个管理员的控制，而管理员又不想让其设置被集中式配置所取代或控制？然后，您应该专注于分散式配置。如果每个管理员最多只能管理几个服务器，则仍然可以手动管理。

第二：您真的需要大量的配置选项吗？还是可以将数量减少到几个？与其将所有内容都配置为“以防万一”，还不如将自身限制为您知道系统真正需要的选项。例如，这可以通过

• 使您的软件更智能（例如，程序可以通过询问环境自动确定哪些内容）？

• 严格遵循“配置之上的约定”-例如，通过建立某些命名约定，或通过从其他选项派生一些选项作为默认选项

第三：您是否真的希望将层次结构的配置硬编码到软件中？想象一下，您事先不知道会有多少台服务器，如果树状的层次结构确实是它们的最佳结构，或者树需要具有多少级。我能想到的最简单的解决方案是，根本不提供集中式配置，每个服务器仅提供一个配置文件，然后让负责任的服务器管理员自行决定如何解决管理多个服务器的配置问题。

例如，管理员可以编写生成器脚本，该脚本将中央配置文件分发到一组不同的服务器，并对每个副本进行一些较小的修改。这样，您不必事先对“服务器分发拓扑”进行任何假设，可以随时根据实际需求调整拓扑。缺点是，您需要管理员具备一些如何使用Perl，Python，Bash或Powershell之类的语言编写脚本的知识。

我个人从不喜欢配置文件继承。您提到有加载顺序，但不确定如何定义或导出。通过将序列镜像到目录结构中（将文件放入文件名或将其包括在文件名中），可能有助于使序列变得明显。

rootsettings.properties
rootsettings.eurosettings.properties
rootsettings.eurosettings.londonsettings.properties

这将在某种程度上起作用，直到您具有不与区域对齐的配置值的集合。因此，您需要考虑选择的组织轴。

我更喜欢将配置值的聚合隔离到它们自己的文件中，并使（叶）配置文件指向一个。

一个例子：

bigcity.searchsettings.properties
regional.searchsettings.properties

在内部，londonsettings.properties您可能会有类似的值：

searchsettings:bigcity.searchsettings.properties

这允许更多的自由度或额外的自由度。

我遇到了同样的问题，并开源了我的解决方案。您可以在这里找到源代码https://github.com/Bikeman868/Urchin

我将其用于具有许多服务器，每个服务器上具有多个应用程序以及多个环境的大型系统。它包括用Dart编写的用于管理配置的UI。

如果您需要帮助，可以直接与我联系。

我实现的解决方案是基于规则的。通常，您首先使用一条适用于所有配置的规则，然后再添加规则，例如“此环境中的所有计算机都将日志文件创建到此UNC路径”。规则可以特定于环境，应用程序，机器或应用程序实例。规则也可以更具体，例如仅在此特定服务器上运行的此应用程序的特定实例中。

规则以从最小到最具体的顺序应用，以后的规则可以覆盖以前的规则中指定的值。例如，这意味着您可以创建适用于特定应用程序的规则，然后为特定计算机或应用程序的特定实例等用不同的值覆盖它。

该服务器具有REST + JSON接口，因此可与大多数开发系统一起使用，并且还具有用于.Net应用程序的便捷客户端库。

这些设置是管理的噩梦。最好通过让您的软件组件处理所有情况来尽可能地减少它们。

即，不为区域设置api服务器，而是通过api调用传递该区域，并让单个服务器设置处理所有区域。

但是，考虑到您所处的状态，我建议您不要设置用于生成配置设置的系统。它只会给已经很复杂的问题增加复杂性。

而是将每种服务器类型的设置存储在部署工具中。（章鱼部署设置，teamcity文件重写等），这使您可以确保部署与上次升级软件时相同的配置设置，并可以对更改进行精细控制。

您不希望更改元配置文件，然后必须测试在各个区域/服务器/自定义分组中生成的配置文件

没有研究；所有个人意见，超过30年的IT经验。听起来像一个复杂的数据结构，可以快速更改/修改，并具有大量用户。

考虑使用数据库存储库（例如SQL）来结构化数据，并使用自定义提取过程为每个用户生成单独的配置文件。您可以使用数据库查询来确定更改的影响，然后再实施。查找重复出现的事件等。单个平面文件是问题的一部分。另外，您可以获得更改日志和恢复/重建支持。使用数据库控制，您也许可以消除配置继承问题。这种类型的解决方案将需要其他数据库结构。正确的组合键结构非常重要。

那是我的建议。

您可能会研究实现此类服务的一些非常昂贵的供应商系统安全性和控制系统。考虑他们。通常，它们将取决于环境。