一、引言
因为新公司没有采用独立的配置中心,每次修改配置参数只能通过手动修改配置文件的方式,然后再重启重启重启,而且机器又是多台,这种方式无疑是非常低下的,而且极容易出错,所以才有了下面的配置中心选型。
二、分布式配置中心需要重点考虑的几个点
其实自己开发一个简单的配置中心也是非常容易的,基于redis+DB就能简单实现。但是要设计一个合格的配置中心还需要考虑如下几点:
- 1 修改配置实时生效
就是修改配置不要依赖于定时调度,即使调度控制在很小的频率下还是会造成一定程度上的延迟. - 2 只需加载被修改的配置
什么意思？就是只同步那些在配置中心改变的参数值。如果使用定时任务去不停的同步DB中的配置数据,无疑是大批量的,没有必要。 - 3 考虑系统容灾,保证高可用
即当配置中心挂的时候，或者DB不可用时不影响系统正常运行。 - 4 具备基本的权限管理。
限制用户登录,防止被恶意修改。 - 5 可以针对不同环境配置多套配置。
一般稍微大点的公司都有很多环境,像dev、test、pre、gray、pro.有可能不同的环境配置不同,需要做到灵活配置。 - 6 要提供多种配置方式,比如说properties配置,key-value配置
所以要自己开发一个独立的配置中心,还是要考虑得比较全面的。而且项目还是以业务为主,也没有足够人力来重新开发一套配置中心,所以就打算借助于开源的力量来满足目前的使用场景。
三、为啥选择Disconf
因为现在的配置中心还是有一些开源实现的。像百度的Disconf,阿里的Diamond,携程的Apollo,还有基于Github的pull模式来实现。我为什么选择Disconf,主要有下面几个点的考量:
- 1 Apollo比较复杂,虽然功能全面,涉及到机房、分区域做配置管理。但是对我们来说有点大材小用了。
- 2 阿里的Diamond开源版本太过简陋了,前端还是黑白界面,内心是拒绝的,而且阿里早就不维护了。
- 3 Github的这种方式虽然比较简单,但是要在生产环境下开放Github的权限会过多吸引安全部门的同事,怕会引发漏洞,而且要达到真正意义上的实时是不是也需要在客户端定时去或者配置呢？带着这个疑问去看看Disconf.
- 4 行业内使用Disconf的比较多,而且对百度有一定的好感。
Disconf是百度的一个分布式配置中心,目前已经开源。而且它是基于java实现的,有简单的配置页面，而且官方还提供了一个相对完善的文档.开发者只需按照它上面的步骤来即可安装,但是官网的安装文档比较扯淡,总结起来就是如下几点:
- 1 直接去Github下载Disconf,修改disconf-web/resources下的jdbc/zk配置地址，将application-demo.properties改名成application.properties配置自己的邮箱信息
- 2 然后进入disconf目录,make install一下
- 3 把disconf-web/target下的disconf-web.war复制到指定目录下,解压。然后再tomcat下配置虚拟映射指向disconf-web这个目录,path设置为"/",然后启动tomcat。
- 4 复制disconf-web下的html到一个指定目录,然后在nginx中配置指向该html目录,upstream指向tomcat的ip和端口如下:
upstream disconf {
server 127.0.0.1:8080;//你的tomcat ip和端口
}
location / {
root xxx/html;//修改到指定目录
if ($query_string) {
expires max;
}
}
location ~ ^/(api|export) {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_pass http://disconf;
}
然后启动Nginx.
- 5 在mysql中创建一个disconf库,初始化/disconf-web/sql/目录下的两个脚本。
-
6 访问nginx。大功告成,admin/admin登录即可！
Disconf.png
是不是有点小清新呢？嘿嘿,还是回到正题上来,要想使用一个开源的产品,必须要掌握其重要机制方可,让我们来分析一下。
四、Disconf的实现原理
4.1 Disconf怎么做到实时修改？
Disconf主要是依靠zookeeper的Watch机制来做配置实时修改的,我们都知道ZK是通过目录挂载的方式来做服务的自动注册与发布。客户端启动时注册了一个回调接口,当zk目录发生变化时会回调所有客户端节点,从而做到"实时"更新配置的目的。
4.2 Disconf怎么做到数据持久化？
在配置中心添加的配置数据都被持久化到了DB中,每次客户端启动的时候会调用Disconf的Http接口获取最新的配置数据,如果网络不通,默认会重试三次,如果还不通,则抛出异常。如果第一次拉取配置就有问题,作为配置中心来讲是肯定是无解的,需要客户端去解决（一般这种情况是网络问题或者配置中心服务不可用导致）。
我们这里不需要考虑第一次加载配置就失败的情况.那么问题来了：
- 1.如果第一次加载配置后,配置中心不可用,会影响到客户端吗？答案：不会。因为动态修改的配置已经加载到内存了,是不影响的。
- 2.如果配置中心宕机,加上客户端需要发布新版本面临重启呢？答案：不影响,因为第一次从配置中心拉取配置后会持久化到磁盘固定目录上,如果配置中心不可用,会读取缓存文件的数据(需要做文件防篡改操作)
4.3 如果ZK宕机会影响配置中心使用吗？
答案:不会,因为disconf会单独起一个线程做重连操作。
4.4 Disconf怎么保证同一项目、环境所在节点都修改配置成功。
答案:没有做这方面的保证。因为客户端连接到配置中心上以后会将机器名挂载到zk目录下,可以通过界面查看配置使用的机器数。
五、Disconf自定义功能扩展
- 1 客户端接入功能增强,增加默认配置属性。
- 2 Disconf针对key-value配置属性没有做持久化,当配置中心宕机、客户端重启时无法拉取历史配置信息。
- 3 增强Disconf节点之间配置不同步的问题
- 4 去掉修改配置同步发送功能,改成异步(它采用的是同步发送,非常卡慢)
六、总结
所以要使用一个开源产品,还是要尽可能的掌握它,如果有太多未知因素在里面的话,出了问题很难被发现,对自己也是一个提升。
