使用JNDI进行分布式配置
我们正在研究如何在主要基于 Java 的部署中进行分布式配置。我们有许多应用程序，集中应用程序的配置是有意义的。 JNDI 似乎是标准选择，可能会退回到 ApacheDS 之类的东西（这样我们也可以在其中存储非 Java 配置）。以下是我考虑过的一些事情。有人尝试过类似的东西吗？有什么建议吗？：
分布式
这适用于多台机器上的多个应用程序，某些应用程序将是集群的。理想情况下，目录服务器也应该是集群的。
轻量级
JNDI 有一点 J2EE 的感觉。任何人都可以使用替代的分布式配置机制。应用程序本身往往是相对轻量级的，而不是完整的 Java EE 应用程序（好吧，Java EE 是否仍然被认为是重量级的并且需求肯定是重量级的，这是有争议的）。
支持回退
通常相同的配置适用于多个应用程序（例如，多个应用程序可能连接到同一个数据库）。另一方面，某些应用程序可能需要特定的配置。有时很难提前知道应用程序是否将使用“全局”配置或特定配置，因此能够首先搜索应用程序/主机特定配置然后回退会很好。我正在考虑这样的结构：
/global/host/application/instance 或 /global/application/host/instance：
因此，首先检查是否有特定于该应用程序实例的任何配置主机，然后检查该主机是否有特定于该应用程序的任何配置，然后检查是否有特定于该应用程序的任何配置，然后尝试全局设置。对于这种事情有什么最佳实践吗？
实时配置更改
Spring 允许使用 jee:jndi-lookup 进行配置，并且您可以选择不缓存该值，这意味着每个请求都会查找该值。我不确定这对于“String”类型配置值是否有意义。它似乎也没有使用 NamingListener 方式来检测 DS 中的更改。如果能够更新目录服务器上的值并将该更改广播到使用它的所有应用程序，那就太好了。
其他注意事项
- 管理不同环境
- 将配置添加到源代码管理，以便可以应用更改管理
- 管理不同版本
- 回滚
We're looking at how to do distributed configuration within our primarily Java based deployment. We have a number of applications and it makes sense to centralise the configuration of the applications. JNDI appears to be the standard choice, probably backing off to something like ApacheDS (that way we can store non Java config in there as well). Here are some of the things that I've considered. Has anyone tried something similar? Any recommendations?:
Distributed
This would be for multiple applications on multiple machines, some of the applications would be clustered. The Directory Server should also ideally be clustered.
Lightweight
JNDI has a bit of a J2EE feel to it. Anyone use an alternative distributed configuration mechanism. The applications themselves tend to be relatively lightweight rather than full Java EE applications (ok controversial whether Java EE is still considered heavyweight and requirements are certainly heavyweight).
Supports fallbacks
Often the same configuration applies to multiple applications (e.g. multiple applications may connect to the same database). One the other hand, some applications may need specific configuration. Sometimes it is difficult to know in advance whether an application will use a 'global' configuration or something specific, so being able to first search for application / host specific configuration and then falling back would be good. I'm thinking of a structure something like this:
/global/host/application/instance or /global/application/host/instance:
so, start by checking to see if there is any configuration specific to this instance of the application on this host, then check if there is any configuration specific to this application for this host, then check to see if there is anything specific for this application, then try the global setting. Are there any best practices for this kind of thing?
Live configuration changes
Spring allows configuration with a jee:jndi-lookup and you can choose not to cache the value which means it is looked up each request. I'm not sure that makes sense for "String" type configuration values. It also doesn't appear to use the NamingListener way of detecting changes in the DS. It would be good to be able to update a value on the Directory Server and have that change broadcast to all of the applications that use it.
Other considerations
- Managing different environments
- Adding the configuration to source control so that it can have change management applied to it
- Managing different versions
- Rolling back
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您是否考虑过使用数据库来存储应用程序配置？
Apache Commons 有一个 DatabaseConfiguration 类，它将您的表公开为 java.util.Properties 实例（请参阅
Have you considered using a database to store the application configuration?
Apache Commons has a DatabaseConfiguration class that exposes your table as a java.util.Properties instance (see http://commons.apache.org/configuration/apidocs/org/apache/commons/configuration/DatabaseConfiguration.html).