J2EE Cluster：是否有通用的方法来处理中央配置？
我们开发一个通常部署在单个网络服务器上的应用程序。现在我们检查它在集群环境中的运行情况，因为一些客户正在使用集群。
问题是应用程序创建了一个本地配置（在注册表/文件中），这在集群中没有任何意义。配置由应用程序更改。 是否有一种通用方法（如接口）来进行集中配置，以便当应用程序部署在集群中时，配置（文件）本身不会在每个节点上重复？还有其他推荐的选择吗？ （使用网络共享/数据库/某些 MBean 上的配置手动执行此操作？）
为什么是通用的？它必须运行在不同的应用程序服务器上（如 tomcat、jboss、Webspere、weblogic ...），因此我们无法使用某些特定于服务器的功能。
谢谢。
We develop an application which is normally deployed on a single webserver. Now we check how it runs in a clustered environment, as some customers are using clusters.
The problem is the app creates a local configuration (in registry/file) which does not make any sense in a cluster. The config is changed by the application.
Is there a generic way (like an interface) to make a central configuration, so the config(-file) itself is not duplicated on each node when the app in deployed in a cluster? Any other recommended options? (doing it manually with config on network-share/in database/some MBean?)
why generic? It must run on different application-servers (like tomcat, jboss, Webspere, weblogic ...) so we cannot use some server-specific feature.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
集中配置的最简单方法是将其放在文件系统上。通过这种方式，您可以将文件系统安装到您的操作系统，并使其可供您的应用程序服务器使用，无论品牌或版本如何。
我们对一些应用程序这样做。我们关心的共享库和/或属性文件（在我们的例子中）。我们设置 JVM 参数或 JNDI 环境变量（尝试转向这些变量），以便我们可以在运行时查找已安装驱动器的路径并从文件加载数据。
对我们来说工作得非常顺利。
现在，如果您正在编写信息，那就是另一回事了。然后，您必须担心如何运行集群（是否仅高可用？负载平衡？）。该应用程序是否像一个应用程序一样在两个集群中运行？还是在每个集群节点上独立运行？如果是这样，那么您可能需要担心并发写入。使用数据库或上述其他解决方案之一可能会更好。
但如果您所做的只是读取配置，那么我会选择安装的文件系统，因为它是最简单的。
Easiest way for central configuration is to put it on the file system. This way you can mount the file system to your OS and make it available to your app server no matter what the brand or version.
We do this for some of our applications. Shared libraries and/or properties files that we care about (in our case). We set up either JVM parms or JNDI environment variables (trying to move toward those) so we can look up the path to the mounted drive at runtime and load the data from the files.
Works pretty slick for us.
Now if you are writing information, that's a different story. As then you have to worry about how you are running your cluster (is it highly available only? load-balanced?). Is the app running in both clusters as if it was one app? Or is it running independently on each cluster node? If so, then you might have to worry about concurrent writes. Probably better to go with a database or one of the other solutions as mentioned above.
But if all you are doing is reading configuration, then I would opt for the mounted file system as it is simplest.
您可以使用 Commons Configuration 之类的库，并选择集群友好的实现，例如 JDBC 或 JNDI。
You may use a library like Commons Configuration and choose an implementation which is cluster-friendly like JDBC or JNDI.
我会首先考虑 JDBC 和 JDNI，但是如果您希望您的服务器能够独立运行，我建议使用像 subversion/git/mercurial 这样的文件分发系统，即如果您的中央配置服务器关闭或不可用，您不希望生产停止。
版本控制系统提供了谁在何时进行了哪些更改以及受控版本（以及版本回滚）的历史记录，
避免中央服务器添加另一个故障点的问题的一种方法是使用您已经依赖的数据库服务器（假设你有一个）的基础是，如果它不运行，你无论如何都不会工作。
I would consider JDBC and JDNI first, however if you want your servers to be able to run independantly, I would suggest a file distrubtion system like subversion/git/mercurial i.e. if your central configuration servers is down or unavailable, you don't want production to stop.
A version controlled system provides a history of who made what changes when and controlled releases (and roll back of releases)
One way to avoid the issue of the central server adding another point of failure is to use a databasse server which you already depend on (assuming you have one) on the basis that if its not running, you won't be working anyway.