JavaEE解决方案配置最佳实践

Question

我们构建 3 层企业解决方案，通常由多个 webapp 和 ejbjar 模块组成，这些模块都与​​数据库通信并具有多个外部集成点。

每个模块通常需要自己的配置，这些配置可以在解决方案的生命周期内发生变化。 部署它变成了一场噩梦，因为现在我们有 18 个属性文件，必须记住复制和配置这些文件，还设置数据源、队列、内存要求等。

我对有更好的方法充满希望但并不乐观。 我们考虑/使用了一些选项，每个选项都有其优点和缺点：

1. 使用多个 Maven 项目和持续集成（例如 hudson 或 jenkins）来构建一个配置 jar，其中包含每个环境的所有属性文件（dev、qa、prod） ）然后将所有内容打包为 EAR。但当需要时，在生产中就无法轻易改变事情了。
2. 将大部分设置放在数据库中，并有一个简单的屏幕来修改它。在内部，我们可以拥有一个可以读取和修改值的通用配置服务 EJB。每个模块都可以有一个自定义扩展版本，该版本具有特定的 getter 和 setter。
3. 对所有属性文件进行版本控制，然后在生产中将其检出，并在进行更改后将其检入生产分支。

有了所有这些，您仍然需要以容器特定的方式配置数据源和队列等:(

Answer 1

1. 考虑将自定义配置对象绑定到 JNDI。然后在您的应用程序中查找此对象以配置它们。优点 - 您可以使用自定义配置对象，而不是相当通用的 Map 或 Properties。
2. 另一种方法是使用 JMX 来配置您需要的应​​用程序。好处 - 您可以将需要配置的对象直接绑定到 MBean Server，然后使用 jconsole 或 visualvm 等知名工具进行配置您的应用程序的组件。

两种方式都支持在运行时动态重新配置应用程序。我更喜欢使用 JMX。

Answer 2

我已经经历了几个寻找方法来做到这一点的循环。我仍然没有确定的答案。

上一个周期以基于属性文件的过程结束。这个想法是每个服务器实例都配置有一个配置所有内容的属性文件。该文件由启动脚本读取，以设置内存参数、由应用程序服务器和应用程序本身读取。

但关键是该文件不是直接管理的。相反，它是构建过程的产物。我们有一系列用于不同目的的文件，保存在版本控制中，以及合并适当文件的构建步骤。这可以让您找出沿各个轴共享的共性。

例如，我们有开发、持续集成、QA、UAT、登台和生产环境，每个环境都有自己的数据库。不同环境中的服务器需要不同的数据库设置，但给定环境中的每台服务器都使用相同的设置。因此，就有了诸如development-db.properties、qa-db.properties 之类的东西。在每个环境中，我们都有多种服务器 - Web 服务器、内容管理服务器、批处理服务器等。每种服务器都有 JVM 设置、堆大小等，这些设置与其他类型的服务器不同，但跨服务器之间保持一致环境。因此，我们有 web-jvm.properties、cms-jvm.properties、batch-jvm.properties 等内容。我们还有一种方法可以覆盖特定系统 - production-cms-jvm.properties 之类的东西。我们还有一个 common.properties 来设置公共属性，以及可以在需要时覆盖的合理默认值。

我们的构建过程实际上比仅仅从每组中选择正确的选项要复杂一些；我们为每个环境中的每个服务器都有一个主文件，其中指定了要包含哪些其他文件。我们允许文件指定要包含的其他文件，因此我们可以构建导入图以最大限度地重用。

结果变得相当复杂。我认为太复杂了。但它确实有效，并且确实使得以受控方式进行影响许多服务器的更改变得非常非常容易。我们甚至合并了一组来自开发的输入文件和一组来自运营的输入文件，其中包含敏感信息。这是一种非常灵活的方法。

Answer 3

我知道这个问题已经得到了回答，我的答案不一定是通用的，但这是我的看法：

注意，这里我只考虑系统/资源属性，而不是应用程序设置。在我看来，应用程序设置（例如支付阈值或其他设置应存储在数据库中，以便可以重新配置系统，而无需重新启动服务或通过重新部署或重新读取属性文件而导致停机） 。

对于影响系统不同部分如何相互连接的设置（例如 Web 服务端点等），我将使用 JNDI 树。

然后，数据库连接和 JMS 连接将使用 Websphere 控制台进行设置，并可由 Websphere 管理员进行管理。这些也可以创建为 JACL 脚本，如有必要，可以将其放入版本控制中。

除了 JNDI 资源之外，对于其他属性，例如对后端的 Web 服务调用的用户名等，我将使用 Websphere“名称空间绑定”。这些绑定可以使用 Websphere 控制台进行编辑，并使用“cell/persistent/mypassword”名称通过 JNDI 进行访问。

因此，我可以创建“mypassword”绑定（一个字符串），并且它的管理权由 Websphere 管理员负责（远离开发人员或其他不应访问生产系统的人），同时可以使用相同的 EAR 文件开发、测试、预生产和生产（最好为不同的系统使用不同的 EAR 文件，因为其他差异渗透的可能性会降低）。

然后，Java 代码将使用简单的 JNDI 查找（并可能将值缓存在内存中）。

相对于属性文件的优点：

• 没有因为系统属性包含密码而需要保护的“易受攻击”文件。
• 无需添加 Java 安全策略来允许访问该文件位置

相对于数据库属性的优点：

• 不依赖于将一个数据库与应用程序服务器绑定。

希望有帮助

Answer 4

使用多个 Maven 项目和持续集成（例如 hudson 或
jenkins) 构建一个包含所有属性的配置 jar
每个环境（dev、qa、prod）的文件，然后捆绑所有内容
作为 EAR。但在生产中事情就不能轻易改变
当需要时。

我认为配置应该位于应用程序实例的数据库中。您的本地计算机配置可能与开发、QA、PROD、DR 等不同。

您需要的是一种以简单的方式从数据库中获取配置的方法。

我创建了一个单独的项目，并提供了 Apache commons-configuration 的依赖项
它有很多存储数据的方式，但我喜欢数据库，并且配置存在于数据库环境中。

    import javax.sql.DataSource;
    import org.apache.commons.configuration.DatabaseConfiguration;

    public class MYConfig extends DatabaseConfiguration {

        public MYConfig(DataSource datasource) {
            super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");
        }
    }

将大部分设置放在DB中并有一个简单的屏幕可以修改
它。在内部我们可以有一个通用的配置服务 EJB
可以读取和修改数值。每个模块都可以有一个自定义扩展
具有特定 getter 和 setter 的版本。

Commons 配置作为一个简单的 API，然后您可以根据需要编写 GUI。
您可以按照您希望的任何方式制作界面。或者作为快速获胜没有界面。

对所有属性文件进行版本控制，然后在生产中检查它
并在进行更改后将其签入生产分支。

版本控制很棒。使用组合添加另一个 DatabaseConfiguration。您扩展的类是活动配置，而组合类是审核。还有另一个构造函数可以有一个版本。只需重载正确的方法即可获得所需的效果。

    import javax.sql.DataSource;
    import org.apache.commons.configuration.DatabaseConfiguration;

    public class MYConfig extends DatabaseConfiguration {
        final DatabaseConfiguration audit;

        public MYConfig(DataSource datasource) {
            super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");

            audit = new DatabaseConfiguration("TABLE_CONFIG_AUDIT", "PROP_KEY", "PROP_VALUE");
        }
        @Override
        public void addProperty(String key, Object value) {
            Object wasValue = super.getProperty(key);
            super.addProperty(key, value); 
            audit.put(key,wasValue);//add version code
        }
    }

http://commons.apache.org/proper/commons-configuration/

Answer 5

用户一个简单的数据库表（部分、键、值）。如果需要，添加“Version”，然后使用 getInt(String section, String key) 等方法将整个内容包装在一个简单的 ConfigurationService 类中。

工作量不大，而且它使应用程序代码非常简单。整洁，并且很容易调整配置。

Answer 6

有趣的替代配置文件格式：编写 scala 特征。然后，您的配置文件可以只是一个 scala 文件，您可以在服务器启动时对其进行编译和评估。
http://robey.lag.net//2012/03/26 /为什么-config.html