开源周荐分布式配置管理神器Qihoo360/QConf入门指北(部署配置使用架构原理)
Posted 徐同学呀
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了开源周荐分布式配置管理神器Qihoo360/QConf入门指北(部署配置使用架构原理)相关的知识,希望对你有一定的参考价值。
文章目录
一、前言
在日常开发中,会涉及到很多配置信息,如数据库配置(ip、port、username、passwaord、最大连接数等),日志配置(输出路径、清理时间、level),以及自定义配置等,这些配置可能经常发生变化,如果写死在代码里,每次变更都需要修改到代码,并且提交、编译、上线等一套操作极其复杂,且容易出错。
所以将可变部分解耦,放到配置文件里(.yml
、.xml
),如springboot
、springmvc
等项目里会有一个resources
目录,该目录下可以放一些配置文件,编译打包时可以和源码一起打包成一个jar,此时有改配置也不需要修改到源码,但是还是需要重新打包上线。也有一些配置直接放在机器本地,通过绝对路径读取,一个服务可能部署在多台机器,一份配置可能分布在不同机器,同步和修改都加大了运维成本。
QConf
就是为了解决以上问题而诞生的。QConf
是Qihoo360的开源项目,其致力于将配置内容从代码中完全解耦,并提供可靠高效的配置访问和更新服务。QConf
在360内部主要承担配置管理和服务注册发现的角色,基本覆盖了公司大大小小业务,上万台机器,稳定运行至今。
二、部署和配置
学一门技术,首先就是用起来。QConf依赖ZooKeeper
存储配置,需要先部署ZooKeeper
,因为二者都是开箱即用的工具,所以部署过程很简单。
1、部署ZooKeeper
一般情况ZooKeeper
、QConf
等工具安装在/usr/local/
目录下。顺序执行如下命令即可安装ZooKeeper
:
cd /usr/lcoal
mkdir zookeeper
cd zookeeper
# 下载zookeeper,可访问https://mirrors.cnnic.cn/apache/zookeeper获取不同版本的下载链接
wget https://mirrors.cnnic.cn/apache/zookeeper/zookeeper-3.7.0/apache-zookeeper-3.7.0-bin.tar.gz
# 解压
tar -zxvf apache-zookeeper-3.7.0-bin.tar.gz
# cp一份配置
cd apache-zookeeper-3.7.0-bin/conf && cp zoo_sample.cfg zoo.cfg
# 启动zookeeper 默认启动端口2181,单机版
cd ../bin && sh zkServer.sh start
需要注意:
ZooKeeper
运行需要JDK环境。- 如果个人资源有限,只有一台服务器的话,可以部署伪集群
ZooKeeper
,奇数,至少3个实例。
2、连接zookeeper客户端
ZooKeeper
安装完毕后,需要加一些测试数据,同时也可以验证下刚才是否安装成功:
# 连接客户端,默认连接2181
sh zkCli.sh
连接客户端后,如果显示CONNECTED
,就说明安装成功了。
执行如下命令,创建一些测试数据:
create /demo demo
create /demo/confs confs
create /demo/confs/conf1 111111111111111111111
create /demo/confs/conf2 222222222222222222222
create /demo/confs/conf3 333333333333333333333
3、部署Qconf
Qconf
的部署方式有两种,一种源码方式,一种是下载已经编译好的rpm包,后者更简单。这里只介绍rpm方式:
访问该链接,获取最新rpm包https://github.com/Qihoo360/QConf/releases,顺序执行如下命令进行安装:
cd /usr/lcoal
mkdir qconf
cd qconf
# 下载
wgethttps://github.com/Qihoo360/QConf/releases/download/1.2.1/QConf-1.2.1-1.el6.x86_64.rpm
# 安装
rpm -ivh QConf-1.2.1-1.el6.x86_64.rpm
# 启动qconf-agent
cd /usr/local/qconf
cd bin && sh agent-cmd.sh start
# 环境配置,这样在各个目录都可以执行qonf的命令
vim /etc/profile
# 将如下配置复制到profile最后面即可
#qconf
QCONF_HOME=/usr/local/qconf
PATH=$QCONF_HOME/bin:$PATH
export QCONF_HOME
export PATH
4、测试获取配置
Qconf
提供了如下可选命令:
- qconf get_conf xxx ,获取xxx的配置内容。
- qconf get_batch_keys xxx,批量获取xxx的子项目。
- qconf get_host和qconf get_allhost 和服务发现有关。
qconf get_conf /demo/confs/conf1
qconf get_batch_keys /demo/confs
5、Qconf配置文件
Qconf
的配置比较少也相对简单:
(1)agent.conf,qconf_agent
的配置:
(2)idc.conf,配置zk集群(这里配置了两个集群环境,一个test,一个dev,那Qconf
是使用哪个集群呢?):
(3)localidc,指定qconf当前使用的zk集群环境:
三、SDK获取配置
Qconf
支持c/c++, shell, php, python, lua, java, go, node等语言获取配置,这里只介绍java方式,其他方式可参考官方文档:
<dependency>
<groupId>qconf-client</groupId>
<artifactId>qconf-client</artifactId>
<version>1.2.2</version>
</dependency>
// 导包
import net.qihoo.qconf.Qconf;
import net.qihoo.qconf.QconfException;
// 方法
// get configure value
String value = Qconf.getConf("demo/confs");
// get all children nodes'key
ArrayList keys = Qconf.getBatchKeys("demo/confs");
// get all children nodes' key and value
Map<String, String> confs = Qconf.getBatchConf("demo/confs");
//... ...
注意:
网上mvn仓库好像下载不到qconf-client
。如有需要,可通过如下百度网盘链接获取:
链接:https://pan.baidu.com/s/1bATv3Bqo2P5Ly3RfLPafjg
提取码:yyds
四、架构与原理
QConf
一开始对配置管理的定位,就是解耦配置和代码,让配置更简单高效,使得整个架构非常简单,且容易部署和使用。
QConf
使用ZooKeeper
服务器存储所有的配置信息。众所周知,ZooKeeper
的存储是树状的,类似于文件目录的形式,所以QConf
配置名为ZooKeeper
的节点名,配置项的值为ZooKeeper
的节点值。
而主要选择ZooKeeper
作为配置存储的原因是,ZooKeeper
的监听回调机制。客户端可以向ZooKeeper
服务端注册感兴趣的事件监听(watcher
),这些事件包括:节点被创建(ZOO_CREATED_EVENT
)、节点被删除(ZOO_DELETED_EVENT
)、节点值改变(ZOO_CHANGED_EVENT
)、子节点变化(ZOO_CHILD_EVENT
)、客户端断开或重新连接(ZOO_SESSION_EVENT
)等,一旦这些事件发生,ZooKeeper
服务端就会通知客户端,执行客户端注册的回调函数。
QConf
就是利用ZooKeeper
的监听回调机制,实现配置及时更新和同步。
1、QConf的特点
因为QConf
的定位和技术选型,它具备以下特点:
- 单条配置不宜太大,受
ZooKeeper
节点限制,最大为1MB。 - 读取配置低延迟,性能高。
- 配置更新,可以几秒内同步更新到所有机器。
- 适合读多写少场景。
- 安装部署方便,使用简单。
- 支持c/c++、shell、php、python、lua、java、go、node 等语言。
2、整体架构
如下图,是QConf
实际生产中的基本架构,包括顶端的QConf
管理端、部署Zookeeper
的服务端,以及QConf
的客户端。
从下往上说,QConf
客户端,已开源,基本无需改造,就是上面部署的qconf_agent
。主要负责与ZooKeeper
服务端交互,比如获取配置,监听配置更新缓存等。QConf
服务端,就是ZooKeeper
集群了,至少3台实例,保证高可用和数据强一致性(CP)。
QConf
的管理端,现开源的管理端比较简陋,可以根据实际情况自行开发,主要功能包括:配置的增删改查以及QConf
客户端的监控。配置可以双写mysql
和ZooKeeper
,配置的修改可以加版本控制(发布单),按流程发布更新配置,有问题就回滚,实现配置的平滑管理。同时管理端还需要提供HTTP获取配置的方式,使配置的使用更方便。(qconf_agent
获取配置只能本机获取)
3、QConf客户端qconf_agent
ZooKeeper
对外提供的接口非常原生简单,所以qconf_agent
主要封装了对ZooKeeper
的交互,监听配置更新同步,同时为了提高容错和性能,加了一层本地缓存(配置信息在共享内存里以哈希表的形式存储),使得配置获取为内存级别的访问速度。每次获取配置如果本地缓存中有就直接返回,没有才向ZooKeeper
发网络请求获取配置(这个过程也是异步的),并更新到共享内存,这样大大降低了ZooKeeper
的压力。即使网络中断,ZooKeeper
集群故障不可用,也可以短时间内读取QConf
的本地缓存对外提供服务。
4、获取配置更新同步流程
- 业务进程调用某一种语言的
QConf
接口,从共享内存(Share Memory
)中查找需要的配置信息。 - 如果存在,直接获取,否则会向消息队列(
Message Queue
)中加入该配置key。 qconf_agent
从消息队列中感知需要获取的配置key。qconf_agent
向ZooKeeper
查询数据并注册监听。qconf_agent
将获得的配置value
序列化后放入共享内存。- 业务进程等待,直到共享内存里出现所要读取的配置,然后从共享内存中获得最新值返回。
5、QConf如何保证数据正确性
qconf_agent
读写配置缓存是无锁的,那如何保证多线程下数据正确性呢?
(1)单点写
qconf_agent
涉及更新配置缓存的场景有:
- 用户进程获取配置缓存中没有,将配置key放到消息队列。
ZooKeeper
配置修改删除等触发Watcher
通知,需更新缓存。- 防止
Watcher
丢失造成数据不一致,需要定时对共享内存中所有配置重新注册Watcher
,此时可能会更新缓存。 - 发生
qconf_agent
重启、网络中断、ZooKeeper
会话过期等异常情况,需重新拉数据,此时可能需要更新缓存。(数据落盘,应对断网情况下共享内存被清空的状况)
写操作基本属于内部异步触发,并发不是很大,可以将所有的写操作放到一个队列里,让一个线程去执行,保证写操作的顺序性和原子性。这样会牺牲一些性能, 但问题不大,用户基本不会感知。
(2)读验证
无锁的读写方式,会存在读到未写入完全数据的危险,但考虑到在绝对的读多写少环境中这种情况发生的概率较低,所以允许其发生,通过读操作时验证来尽量避免。
配置在序列化存储到共享内存时会计算md5值,业务进程读取配置时,利用预存的md5值验证数据是否正确。由于计算md5开销比较大,所以最新实现方法对于将要放入共享内存的数据,如果小于某一值(当前设置为1500)就将数据本身复制一份作为验证码,如果大于设定值还是采用md5。
6、qconf_agent线程分工
(1)Send
线程:ZooKeeper
线程,处理网络数据包,进行协议包的解析与封装,并将Zookeeper
的事件加入WaitingEvent
队列等待处理。
(2)Event
线程:ZooKeeper
线程,依次获取WaitingEvent
队列中的事件,并进行相应处理,这里只需要关注节点删除、节点值修改、子节点变化、会话过期等事件。以节点值修改为例,qconf_agent
序列化该节点key,并将其加入到WaitingWriting
队列,等待Main
线程处理。
(3)Main
线程:共享内存的唯一写入线程,从Zookeeper
获得数据写入共享内存,维护共享内存中的内容。
(4)Msq
线程:用户进程从共享内存中找不到配置时,会向消息队列中加入该配置key,Msq
线程便是负责从消息队列中获取配置key,加入到WaitingWriting
队列发送给Main
线程;
(5)Scan
线程:扫描共享内存中的所有配置,发现与Zookeeper
不一致的情况时,将key值加入WaitingWriting
队列。Scan
线程会在ZooKeeper
重连或轮询期到达时进行上述操作;
(6)Trigger
线程:该线程负责一些周边逻辑的调用,包括:
-
dump
操作:将共享内存的内容同步一份到本地,QConf
采用的是gdbm。 -
feedback
操作:QConf
支持更新反馈的功能,可向用户指定web服务以一定的格式发送反馈。 -
script
操作:在某些情况下,业务希望当配置变化时,做一些自定义的操作,QConf
支持配置变化时调用用户脚本。
7、QConf简单实现服务发现
QConf
除了配置管理的基本功能外,还提供了一套简单的服务发现功能,该功能允许业务在QConf
上配置一组服务,QConf
会监控其服务的存活。当业务进程调用获取服务的接口时,会根据用户需求,返回全部可用服务(get_allhost
),或某一可用服务(get_host
)。
结构上多了一个Monitor的角色,来监控所有服务的存活:
开源的Monitor仅仅是通过查看服务端口的存活来判断的,实际生产环境中,判断因素较复杂,比如服务监控,异常数,流量等。
实际生产中可以利用Qconf
提供的简单服务发现功能基础上进行改造,也可以自行实现监控服务判活的服务,依然用QCconf
的简单配置,服务发现的集群标识解析成一个目录,这个目录下包含该集群的所有ip:port
,可作为配置key,服务的状态作为配置value。
五、要点总结
QConf
是一个不错的配置管理工具,容易部署,使用简单。其架构设计理念有很多值得学习的地方:
QConf
使用ZooKeeper
服务器存储所有的配置信息,配置名为zk的节点名,配置项的值为zk的节点值。QConf
利用ZooKeeper
的监听回调机制,注册感兴趣的事件监听(watcher
),实现配置及时更新和同步。QConf
高效和高可用设计思路体现在很多地方,比如无锁化读写、共享缓存、消息队列等。业务进程读取配置不会直接和zk或者qconf_agent
进行交互,完全异步,全权交由qconf_agent
的异步线程做配置监听和更新操作。- 无锁的读写方式,会存在读到未写入完全数据的危险,为了保证数据正确性,
qconf_agent
采用了两个措施:单点写,集中一个线程做写操作,保证写顺序性和原子性;读验证,共享内存数据在序列化时会带其md5值,业务进程从共享内存中读取时,利用预存的md5值验证是否正确读取。
因为QConf
是C语言写的,暂时看不懂源码,所以很多原理概念都是理解官方文档后整理,同时官方文档有些措辞上不太通顺,部署文档中给的安装包较旧,文档较乱、冗杂,所以通读后整理,有些地方写的很好,很精炼,就直接摘抄过来了,所有关于原理的图片均来自官方文档。非常感谢Qihoo360/QConf,学到很多优秀的架构理念。
官方文档:
如若文章有错误理解,欢迎批评指正,同时非常期待你的评论、点赞和收藏。
以上是关于开源周荐分布式配置管理神器Qihoo360/QConf入门指北(部署配置使用架构原理)的主要内容,如果未能解决你的问题,请参考以下文章
战斗民族开源神器!ClickHouse为什么能够征服各个大厂?
90后程序员开发“AI吵架神器”,专治女朋友各种不服!蚂蚁金服启动分布式中间件开源计划;MongoDB 3.7.5发布