ZooKeeper 笔记(3) 实战应用之【统一配置管理】
2016-03-06 20:06
477 查看
原文出自:http://www.cnblogs.com/yjmyzz/p/4604947.html
大型应用通常会按业务拆分成一个个业务子系统,这些大大小小的子应用,往往会使用一些公用的资源,比如:需要文件上传、下载时,各子应用都会访问公用的Ftp服务器。如果把Ftp Server的连接IP、端口号、用户名、密码等信息,配置在各子应用中,然后这些子应用再部署到服务器集群中的N台Server上,突然有一天,Ftp服务器要换IP或端口号,那么问题来了?不要紧张,不是问 挖掘机哪家强:),而是如何快速的把这一堆已经在线上运行的子应用,通通换掉相应的配置,而且还不能停机。
要解决这个问题,首先要从思路上做些改变:
1、公用配置不应该分散存放到各应用中,而是应该抽出来,统一存储到一个公用的位置(最容易想到的办法,放在db中,或统一的分布式cache server中,比如Redis,或其它类似的统一存储,比如ZooKeeper中)
2、对这些公用配置的添加、修改,应该有一个统一的配置管理中心应用来处理(这个也好办,做一个web应用来对这些配置做增、删、改、查即可)
3、当公用配置变化时,子应用不需要重新部署(或重新启动),就能使用新的配置参数(比较容易想到的办法有二个:一是发布/订阅模式,子应用主动订阅公用配置的变化情况,二是子应用每次需要取配置时,都实时去取最新配置)
由于配置信息通常不大,比较适合存放在ZooKeeper的Node中。主要处理逻辑的序列图如下:
解释一下:
考虑到所有存储系统中,数据库还是比较成熟可靠的,所以这些配置信息,最终在db中存储一份。
刚开始时,配置管理中心从db中加载公用配置信息,然后同步写入ZK中,然后各子应用从ZK中读取配置,并监听配置的变化(这在ZK中通过Watcher很容易实现)。
如果配置要修改,同样也先在配置管理中心中修改,然后持久化到DB,接下来同步更新到ZK,由于各子应用会监听数据变化,所以ZK中的配置变化,会实时传递到子应用中,子应用当然也无需重启。
示例代码:
这里设计了几个类,以模拟文中开头的场景:
FtpConfig对应FTP Server的公用配置信息,
ConfigManager对应【统一配置中心应用】,里面提供了几个示例方法,包括:从db加载配置,修改db中的配置,将配置同步到ZK
ClientApp对应子系统,同样也提供了几个示例方法,包括获取ZK的配置,文件上传,文件下载,业务方法执行
ConfigTest是单元测试文件,用于集成测试刚才这些类
为了方便,还有一个ZKUtil的小工具类
FtpConfig代码如下:
ConfigManager代码如下:
ClientApp类如下:
最终测试一把:
输出如下:
ftpConfig => test/123456@192.168.1.1:21
正在上传文件...
test/123456@192.168.1.1:21
文件上传完成...
正在下载文件...
test/123456@192.168.1.1:21
文件下载完成...
...
正在上传文件...
test/123456@192.168.1.1:21
ftpConfig is changed !
node:/config/ftp
o:newUser/newPwd@10.6.12.34:23
文件上传完成...
正在下载文件...
newUser/newPwd@10.6.12.34:23
文件下载完成...
从测试结果看,子应用在不重启的情况下,已经自动感知到了配置的变化,皆大欢喜。最后提一句:明白这个思路后,文中的ZK,其实换成Redis也可以,【统一配置中心】修改配置后,同步到Redis缓存中,然后子应用也不用搞什么监听这么复杂,直接从redis中实时取配置就可以了。具体用ZK还是Redis,这个看个人喜好。
大型应用通常会按业务拆分成一个个业务子系统,这些大大小小的子应用,往往会使用一些公用的资源,比如:需要文件上传、下载时,各子应用都会访问公用的Ftp服务器。如果把Ftp Server的连接IP、端口号、用户名、密码等信息,配置在各子应用中,然后这些子应用再部署到服务器集群中的N台Server上,突然有一天,Ftp服务器要换IP或端口号,那么问题来了?不要紧张,不是问 挖掘机哪家强:),而是如何快速的把这一堆已经在线上运行的子应用,通通换掉相应的配置,而且还不能停机。
要解决这个问题,首先要从思路上做些改变:
1、公用配置不应该分散存放到各应用中,而是应该抽出来,统一存储到一个公用的位置(最容易想到的办法,放在db中,或统一的分布式cache server中,比如Redis,或其它类似的统一存储,比如ZooKeeper中)
2、对这些公用配置的添加、修改,应该有一个统一的配置管理中心应用来处理(这个也好办,做一个web应用来对这些配置做增、删、改、查即可)
3、当公用配置变化时,子应用不需要重新部署(或重新启动),就能使用新的配置参数(比较容易想到的办法有二个:一是发布/订阅模式,子应用主动订阅公用配置的变化情况,二是子应用每次需要取配置时,都实时去取最新配置)
由于配置信息通常不大,比较适合存放在ZooKeeper的Node中。主要处理逻辑的序列图如下:
解释一下:
考虑到所有存储系统中,数据库还是比较成熟可靠的,所以这些配置信息,最终在db中存储一份。
刚开始时,配置管理中心从db中加载公用配置信息,然后同步写入ZK中,然后各子应用从ZK中读取配置,并监听配置的变化(这在ZK中通过Watcher很容易实现)。
如果配置要修改,同样也先在配置管理中心中修改,然后持久化到DB,接下来同步更新到ZK,由于各子应用会监听数据变化,所以ZK中的配置变化,会实时传递到子应用中,子应用当然也无需重启。
示例代码:
这里设计了几个类,以模拟文中开头的场景:
FtpConfig对应FTP Server的公用配置信息,
ConfigManager对应【统一配置中心应用】,里面提供了几个示例方法,包括:从db加载配置,修改db中的配置,将配置同步到ZK
ClientApp对应子系统,同样也提供了几个示例方法,包括获取ZK的配置,文件上传,文件下载,业务方法执行
ConfigTest是单元测试文件,用于集成测试刚才这些类
为了方便,还有一个ZKUtil的小工具类
ftpConfig => test/123456@192.168.1.1:21
正在上传文件...
test/123456@192.168.1.1:21
文件上传完成...
正在下载文件...
test/123456@192.168.1.1:21
文件下载完成...
...
正在上传文件...
test/123456@192.168.1.1:21
ftpConfig is changed !
node:/config/ftp
o:newUser/newPwd@10.6.12.34:23
文件上传完成...
正在下载文件...
newUser/newPwd@10.6.12.34:23
文件下载完成...
从测试结果看,子应用在不重启的情况下,已经自动感知到了配置的变化,皆大欢喜。最后提一句:明白这个思路后,文中的ZK,其实换成Redis也可以,【统一配置中心】修改配置后,同步到Redis缓存中,然后子应用也不用搞什么监听这么复杂,直接从redis中实时取配置就可以了。具体用ZK还是Redis,这个看个人喜好。
相关文章推荐
- hdu 3068
- poj3750单向循环链表
- 关于自然数集N到素数集P的一个单射的三种构造
- 一个简单的文本编辑器
- POJ 3991 Seinfeld
- bzoj1412[狼和羊的故事]最小割
- java特种兵读书笔记(6-2)——数据库之主从
- ansible安装配置及实例
- MYSQL错误 NO.1130 ERROR的解决
- MySql的安装
- 软件工程课程记录01
- Unity3d外包—就找北京动点软件(长年承接Unity3d软件、游戏项目外包)
- bootstrap的初学之路—one day
- JAVA数据库连接池实现
- 技术的定义
- iOS 知识碎片记录
- Django URL传递参数的方法总结
- 文件索引节点
- TCP的三次握手(建立连接)和四次挥手(关闭连接)
- Kinect外包团队— 2016中国VR开发者论坛第一期