java - Java 的 Multi-Tenancy /条件配置有哪些库？

Question

我试图找到一种配置服务器端 Java 应用程序的解决方案，以便系统的不同用户与系统交互，就好像它的配置不同( Multitenancy )。例如，当我的应用程序为来自 user1 的请求提供服务时，我希望我的应用程序以克林贡语进行响应，但对于所有其他用户，我希望它以英语进行响应。 (我故意选择了一个荒谬的例子，以避免细节:重要的是我希望应用程序对不同的请求有不同的表现)。

理想情况下有一个通用的解决方案(即允许我添加
用户特定的覆盖我的配置的任何部分而无需更改代码)。

我看过 Apache Commons Configuration，它有 built in support for multitenant configuration ，但据我所知，这是通过将一些基本配置与一些覆盖集相结合来完成的。这意味着我有一个配置指定:

application.lang=english

并且，说一个 user1.properties覆盖文件:

application.lang=klingon

不幸的是，如果我们的支持团队可以在一个地方查看所有相关配置，并以某种方式内联指定覆盖，而不是为基础与覆盖分别设置单独的文件，那么对他们来说会容易得多。

我认为Commons Config的 Multi-Tenancy +类似 Velocity template的某种组合描述底层配置中的条件元素是我的目标——Commons Config 便于与我的配置交互，Velocity 在单个配置中非常有表现力地描述任何覆盖，例如:

#if ($user=="user1")
 application.lang=klingon
#else
 application.lang=english
#end

人们使用什么解决方案来解决此类问题？

Answer 1

您可以像下面这样对每个服务器操作进行编码吗？

void op1(String username, ...)
{
    String userScope = getConfigurationScopeForUser(username);
    String language = cfg.lookupString(userScope, "language");
    int    fontSize = cfg.lookupInt(userScope, "font_size");
    ... // business logic expressed in terms of language and fontSize
}

(上面的伪代码假设用户名作为参数传递，但您可以通过另一种机制传递它，例如线程本地存储。)

如果以上可以接受，那么 Config4*能满足你的要求。使用 Config4*， getConfigurationScopeForUser()上面伪代码中使用的方法可以实现如下(这里假设 cfg是一个Configuration对象，之前已经通过解析配置文件进行了初始化):

String getConfigurationScopeForUser(String username)
{
    if (cfg.type("user", username) == Configuration.CFG_SCOPE) {
        return Configuration.mergeNames("user", username);
    } else {
        return "user.default";
    }

}

这是一个与上述内容一起使用的示例配置文件。大多数用户从“u​​ser.default”范围获取他们的配置，但 Mary 和 John 对其中一些默认值有自己的覆盖:

user.default {
    language = "English";
    font_size = "12";
    # ... many other configuration settings
}

user.John {
    @copyFrom "user.default";
    language = "Klingon"; # override a default value
}

user.Mary {
    @copyFrom "user.default";
    font_size = "18"; # override a default value
}

如果以上听起来可能满足您的需求，那么我建议您阅读“入门指南”的第 2 章和第 3 章，以对 Config4* 语法和 API 有足够的了解，从而能够确认/反驳其适用性Config4* 满足您的需求。您可以在 Config4* website 上找到该文档。 .

免责声明:我是 Config4* 的维护者。

编辑:我提供更多细节以回应 bacar 的评论。

我没有将 Config4* 放在 Maven 存储库中。但是，使用其捆绑的 Ant 构建文件构建 Config4* 是微不足道的，因为 Config4* 对第三方库没有任何依赖性。

在带有 Config4* 的服务器应用程序中使用 Config4* 的另一种方法(由 bacar 的评论提示)如下...

像下面的伪代码一样实现每个服务器操作:

void op1(String username, ...)
{
    Configuration cfg = getConfigurationForUser(username);
    String language = cfg.lookupString("settings", "language");
    int    fontSize = cfg.lookupInt("settings", "font_size");
    ... // business logic expressed in terms of language and fontSize
}

getConfigurationForUser()上面使用的方法可以实现如下伪代码所示:

HashMap<String,Configuration>  map = new HashMap<String,Configuration>();

synchronized String getConfigurationForUser(String username)
{
    Configuration cfg = map.get(username);
    if (cfg == null) {
        // Create a config object tailored for the user & add to the map
        cfg = Configuration.create();
        cfg.insertString("", "user", username); // in global scope
        cfg.parse("/path/to/file.cfg");
        map.put(username, cfg);
    }
    return cfg;    
}

这是一个与上述内容一起使用的示例配置文件。

user ?= ""; // will be set via insertString()
settings {
    @if (user @in ["John", "Sam", "Jane"]) {
        language = "Klingon";
    } @else {
        language = "English";
    }
    @if (user == "Mary") {
        font_size = "12";
    } @else {
        font_size = "10";
    }
    ... # many other configuration settings
}

我对这两种方法的主要评论如下:

第一种方法(一个 Configuration 对象包含许多变量和作用域)可能比第二种方法(许多 Configuration 对象，每个对象都有少量变量)使用的内存略少。但我的猜测是，两种方法的内存使用量都将以 KB 或数十 KB 为单位，与服务器应用程序的整体内存占用量相比，这微不足道。

我更喜欢第一种方法，因为只有一个 Configuration对象只初始化一次，然后通过只读访问 lookup()式操作。这意味着您不必担心同步访问 Configuration对象，即使您的服务器应用程序是多线程的。相比之下，第二种方法要求您同步对 HashMap 的访问。如果您的服务器应用程序是多线程的。

lookup() 的开销-style 操作大约是纳秒或微秒，而解析配置文件的开销大约是毫秒或几十毫秒(取决于文件的大小)。第一种方法只对配置文件执行一次相对昂贵的解析，这是在应用程序初始化时完成的。相比之下，第二种方法对配置文件执行“N”次相对昂贵的解析(对“N”个用户中的每个用户进行一次)，并且在服务器处理来自客户端的请求时会发生重复的费用。对于您的应用程序来说，性能下降可能是也可能不是问题。

我认为易用性比易于实现更重要。所以，如果你觉得第二种方法会更容易维护配置文件，那么我建议你使用这种方法。

在第二种方法中，您可能想知道为什么我将大部分变量放在命名范围( settings )而不是全局范围内以及“注入(inject)” user变量。我这样做的原因超出了您的问题范围:将“注入(inject)”变量与应用程序可见变量分开，可以更轻松地对应用程序可见变量执行架构验证。