为配置选择正确的存储

Question

我们有使用大量配置的应用程序和服务，其中大部分目前都是在java代码中硬编码的，并且分布在很多类中。显然，这种情况需要改变，我们希望将其集中在一个地方，并由其中一个服务(例如ConfigurationService)检索和公开该服务，该服务还将缓存配置用于其客户端以获得更好的性能。我们还需要为长期运行的应用程序动态重新加载配置，并避免重新启动。我想得到一些关于我应该用于这个目的的存储类型的评论-

某种数据-

数据不需要结构化。它可以是一个简单的键值对，也可以是多键、单值对.以下是一些随机配置的例子-

• "Client_Id“-> "ABC”(简单键值)
• "User_Type"：“管理”，“区域”：“孟买”，"User_rating"："9“-> “佣金”：10%
• "User_Id“-> "123”-> "WhitelistedRegions"->"Mumbai, Goa"

存储解决方案-

基本上，构成键的参数集和类型不是固定的，这给了我一个提示，即这个配置不是真正结构化的。整个配置的体积不会很大。与读取相比，写的内容将非常少。

• 数据库(RDBMS / NoSQL) --使用数据库表的优点可能是它提供的安全性和备份。因为这看起来不像关系数据，所以我会考虑一种NoSQL解决方案。我没有亲自使用过，请告诉我哪一个更适合这类数据。由于可能有很多不同的键，我们应该能够选择准确的键(某种索引)。数据库的使用会引入延迟，但是可以构建高效的缓存来克服这一点(因为对配置的写操作不会太多)。数据更容易查询。
• 文件(XML或其他平面文件)--我们可以使用这些文件保持简单。缓存也可以用于文件的情况。只要可以在内存(RAM)中导入整个配置，这也是一个选项(必须实现选择性缓存失效)。文件提供版本控制，必须检查权限/安全性。如果XML文件越来越大，它们尤其会变得更加混乱。如果我们使用的是文件，数据可能不容易查询。

假设动态重新加载和缓存失效分别实现，哪一种应该是更好的存储方案？这里还应考虑哪些其他因素？

如果要使用文件来存储这种配置，那么更好的用例文件格式是什么？

注意:我问了一个相似问题，但可能没有像我应该的那样清楚地提出这个问题，所以创建了一个新的问题，而不是做大量的编辑。

Answer 1

请帮自己一个忙，评估阿查乌斯或馆长是否适合你的需要。Archaius可能更适合应用程序和容器配置，而Curator可能更适合于机器级的配置。

Answer 2

您提供的示例表明您可能需要某种规则引擎。为了说明我的意思，我将您的示例解释为具有以下语义：

if (true) {
    Client_Id = "ABC";
}
if (User_Type == "Admin" && Region == "Mumbai" && "User_rating" == "9") {
    Commission = "10%";
}
if (User_Id == "123") {
    WhitelistedRegions" = ["Mumbai", "Goa"];
}

如果我的解释是错误的，那么也许你可以修改你的问题来澄清你的意图。另一方面，如果我的解释是正确的，那么我就不知道为您的需求量身定制的任何特定配置语法。相反，我怀疑您将不得不将所需内容的语义扩展到您决定使用的任何配置语法的约束中。

我可以尝试将您的示例理解为*的语法(免责声明:我是它的主要开发人员)，方法如下：

uid-rule {
    # unconditional
    client_Id = "ABC";
}
uid-rule {
    condition {
        User_Type = "Admin";
        Region = "Mumbai";
        User_rating = "9";
    }
    Commission = "10%%";
}
uid-rule {
    condition { User_Id = "123"; }
    WhitelistedRegions = ["Mumbai", "Goa"];
}

我建议您阅读Config4*入门手册(HTML，PDF格式)的第2章，以便您能够理解上面示例中使用的语法。

我最初尝试将示例添加到XML语法中是：

<rules>
    <rule>
        <property name="client_Id" value="ABC"/>
    </rule>
    <rule>
        <condition name="User_Type" value="Admin"/>
        <condition name="Region" value="Mumbai"/>
        <condition name="User_rating" value="9"/>
        <property name="Commission" value="10%"/>
    </rule>
    <rule>
        <condition name="User_Id" value="123"/>
        <property name="WhitelistedRegions" value="Mumbai, Goa"/>
    </rule>
</rules>

请注意，无论是Config4*解析器还是XML解析器都不会给出您想要的语义。相反，您应该编写一个名为RulesEngine的类。这样的类将：(1)解析配置文件以获取规则并将解析的表示缓存在内存中；(2)为查询内存中的规则集提供一个简单的API；(3)提供重新解析配置文件的reloadConfiguration()方法。您的应用程序将以某种方式触发reloadConfiguration()方法的调用(例如，每隔几分钟一次)。

如果您在配置语法中使用XML，那么我建议您通过将XML文件存储在web服务器上来实现您的集中化目标。XML解析器可以在那里检索文件表单。如果使用Config4*语法，那么Config4*与curl的集成就可以做同样的事情。

Answer 3

有不同的方法来看待这种情况。

1. 我决定在哪里存储数据的方式通常是基于数据类型的。 如果我正确地读取您的数据，它将指定客户id、基于用户位置和评级的佣金以及适用于特定用户的区域。对我来说，它更像是一种业务静态数据，而不是配置(尽管这种情况不会经常改变)。因此，我宁愿把它保存在数据库中。
2. 我是否需要为用户提供一个屏幕来更新这些数据。如果有一个UI，您不必在PROD中通过提高票证或发布过程来完成这一任务。但是拥有一个UI会将选择转移到数据库中。
3. 如果没有UI，那么文件配置可能是一个更好的选择。因为您可以在应用程序中使用文件监视器服务来查看此配置文件。一旦修改了该文件，此服务将读取该文件并在不重新启动的情况下更新配置。数据库情况下的动态重新加载可能不那么简单。您仍然可以提供一个管理屏幕来手动触发配置重新加载。
4. 对于文件类型，您可以选择由Ciaran提出，但这将需要一些额外的学习。考虑到您没有大量的配置，您可以坚持使用xml。
5. 我认为缓存数据不会对数据库和文件之间的选择产生任何影响，因为两者都很容易实现。但是，如果您正在使用诸如hibernate之类的ORM，您将从缓存数据的额外工作中节省下来，但是ORM带来了定义到数据库表的类映射的另一个复杂性。