统一配置中心方案统一配置中心1中记录了我之前项目中如何处理多系统中的配置问题,对于统一配置中心组件一般分为两种做法:自建它的好外与缺点都非常明确。好处设计以及代码实现都由自己把控,可形成自己的知识积累设计可以足够简化,无需考虑过多场景能够快速适应项目的需求,无需考虑开源的是否支持 ...
统一配置中心方案
统一配置中心1中记录了我之前项目中如何处理多系统中的配置问题,对于统一配置中心组件一般分为两种做法:
自建
它的好外与缺点都非常明确。
好处
- 设计以及代码实现都由自己把控,可形成自己的知识积累
- 设计可以足够简化,无需考虑过多场景
- 能够快速适应项目的需求,无需考虑开源的是否支持
缺点
- 需要人力的投入,而且有重复造轮子的嫌疑,需要有足够的说服力
- 对技术有一定要求,如果写出来的组件问题多或者通用性不强会形成浪费的局面
- 缺少权威性,需要长时间的推进
开源
开源的配置中心,我之前有提到过百度的disconf,还有当当的config-toolkit,这些产品都有很多应用案例,功能也非常全。
好处
- 权威性相对好,成功案例多的组件往往在技术推进上很比较容易
- 不需要过多的人力投入,往往只需要一步一下按步骤来
- 通用性比较强,适用的场景相对广泛
缺点
- 可能并不完全与实际需求相符,需要通过一些扩展来支持
- 可能会是重量级组件,而你的需求只使用其中一小部分
- 可能存在BUG
- 组件升级不受使用者控制
自建的方案
场景
当系统越来越多后,每个系统的配置如果没有统一的管理机制那么会非常难管理,需要有一种侵入性小的方案来将这些原本在单项目中维护的配置工作统一管理起来。
配置存储
推荐使用zookeeper来存储项目中的配置项,也可以是其它的存储。下面设计的配置中心组件是可扩展,但实现暂时只实现了zookeeper。
核心思路
在系统加载时,想办法将存储在zookeeper中的配置内容加载到系统变量中,然后程序就可以像调用本地配置文件一样了,不需要改变现有系统引用变量的行为。至于本地配置文件直接使用Spring自带功能即可,当然也可以统一在组件中。
实际需求
- 配置存储在zookeeper
- 支持本地配置
- 有本地配置的情况下,以本地配置为准(本地调试)
- 支持zookeeper热更新,即在运行时当zookeeper信息发生变更时能够实时同步到程序中
不需要支持本地文件的热更新
设计实现
时序图
内容有点多,先看下配置加载的时序图,不包含事件通知以及热更新。
原标题:统一配置中心2
关键词:
*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们:
admin#shaoqun.com
(#换成@)。