【发布时间】：2011-01-04 06:21:36
【问题描述】：
我们正在研究如何在我们主要基于 Java 的部署中进行分布式配置。我们有许多应用程序，集中配置应用程序是有意义的。 JNDI 似乎是标准选择，可能会退回到 ApacheDS 之类的东西（这样我们也可以在其中存储非 Java 配置）。以下是我考虑过的一些事情。有没有人尝试过类似的东西？有什么建议吗？：
分布式
这将适用于多台机器上的多个应用程序，其中一些应用程序将被集群化。理想情况下，目录服务器也应该是集群的。
轻量级
JNDI 有一点 J2EE 的感觉。任何人都使用另一种分布式配置机制。应用程序本身往往是相对轻量级的，而不是完整的 Java EE 应用程序（好吧，Java EE 是否仍然被认为是重量级的并且需求肯定是重量级的存在争议）。
支持回退
通常相同的配置适用于多个应用程序（例如，多个应用程序可能连接到同一个数据库）。另一方面，某些应用程序可能需要特定的配置。有时很难提前知道应用程序是否会使用“全局”配置或特定配置，因此能够首先搜索应用程序/主机特定配置然后回退会很好。我正在考虑这样的结构：
/global/host/application/instance 或 /global/application/host/instance：
所以，首先检查是否有任何特定于此主机上的应用程序实例的配置，然后检查是否有任何特定于此主机的此应用程序的配置，然后检查是否有任何特定的配置对于这个应用程序，然后尝试全局设置。这种事情有什么最佳做法吗？
实时配置更改
Spring 允许使用 jee:jndi-lookup 进行配置，您可以选择不缓存该值，这意味着每次请求都会查找该值。我不确定这对“字符串”类型的配置值是否有意义。它似乎也没有使用 NamingListener 方法来检测 DS 中的更改。如果能够更新 Directory Server 上的值并将该更改广播到所有使用它的应用程序，那就太好了。
其他注意事项
- 管理不同的环境
- 将配置添加到源代码管理，以便对其应用更改管理
- 管理不同的版本
- 回滚
【问题讨论】：
-
我开始认为 Apache Zookeeper 可能是要走的路。
-
你最后做了什么？
-
目前还没有。我仍然只是使用chef / ansible静态添加配置。候选对象包括 Zookeeper、etcd、doozer。
标签： java configuration distributed jndi