设计层面详解Eureka配置部分源码

以看到，当我们更改了 property 时，监听器中的方法被触发了，利用这一点，我们可以实现动态配置。

后面就会发现， Eureka 底层使用 ConcurrentCompositeConfiguration 来对配置参数进行增删改查，并基于事件监听的机制来支持动态配置 。

另一个有意思的地方

我们再来看看一个 UML 图。上面例子中说到 ConcurrentCompositeConfiguration 的两个功能，是通过实现 Configuration 和继承 EventSource 来获得的，这一点没什么特别的，之所以深究它，是因为我发现了其他有趣的地方。们主要来关注下它的三个成员属性(它们都是 AbstractConfiguration 类型)：

1. configList ：持有的配置对象集合。 这个集合的配置对象存在优先级 ，举个例子，如果我添加了 Configuration1 和 Configuration2，当我们 getProperty(String) 时，会优先从 Configuration1 获取，实在找不到才会去 Configuration2 获取。
2. overrideProperties ： 最高优先级的配置对象 。当我们 getProperty(String) 时，会先从这里获取，实在没有才会去 configList 里找。
3. containerConfiguration ： 保底的配置对象 。一般是 configList 的最后一个(注意，不一定是最后一个1)，我们往 ConcurrentCompositeConfiguration 里增删改 property，实际操作的就是这个对象。

为了更好理解它们的作用，我写了个测试例子。这里补充一点，当我们创建 ConcurrentCompositeConfiguration 时，就会生成一个 containerConfiguration，默认情况下，它会一直在集合最后面，每次添加新的配置对象，都是往 containerConfiguration 前面插入。

谁来加载配置

通过上面的例子可以知道， ConcurrentCompositeConfiguration 并不会主动地去加载配置，所以，Eureka 需要自己往 ConcurrentCompositeConfiguration 里添加配置，而完成这件事的是另外一个类-- ConfigurationManager 。

（编辑：我爱制作网_潮州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!