JavaEE 解决方案配置最佳实践

java jakarta-ee jboss glassfish apache-tomee

2022-09-04 04:19:10

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

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

我很有希望，但并不乐观，认为会有更好的方法。我们考虑/使用过的一些选项，每个选项都有其优点和缺点：

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

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

答案 1

Сonsider 将自定义配置对象绑定到。然后在应用中查找此对象以对其进行配置。优点 - 您可以使用自定义配置对象，而不是相当通用的或.JNDIMapProperties
另一种方法是用于配置所需的应用程序。优点 - 您可以将必须配置的对象直接绑定到，然后使用此类众所周知的工具或来配置应用程序的组件。JMXMBean Serverjconsolevisualvm

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

答案 2

我经历了几个寻找方法来做到这一点的周期。我仍然没有一个明确的答案。

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

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

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

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

它最终变得非常复杂。太复杂了，我想。但它确实有效，并且确实使以受控方式影响许多服务器的更改变得非常非常容易。我们甚至合并了一组来自开发的输入文件，以及另一组来自操作的输入文件，其中包含敏感信息。这是一个非常灵活的方法。