【开源周荐】分布式配置管理神器Qihoo360/QConf入门指北（部署、配置、使用、架构原理）

短命女 2022-10-09 13:27 375阅读 0赞

### 文章目录 ###

*   *  一、前言
     *  二、部署和配置
     *   *  1、部署ZooKeeper
         *  2、连接zookeeper客户端
         *  3、部署Qconf
         *  4、测试获取配置
         *  5、Qconf配置文件
     *  三、SDK获取配置
     *  四、架构与原理
     *   *  1、QConf的特点
         *  2、整体架构
         *  3、QConf客户端qconf\_agent
         *  4、获取配置更新同步流程
         *  5、QConf如何保证数据正确性
         *  6、qconf\_agent线程分工
         *  7、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
    # 指定配置启动
    sh zkServer.sh start /usr/local/zookeeper/apache-zookeeper-3.7.0-bin/conf/zoo-3.cfg
    # 指定配置重启
    sh zkServer.sh restart /usr/local/zookeeper/apache-zookeeper-3.7.0-bin/conf/zoo-3.cfg
    # 其他可行命令
    stop、status、help  ...

需要注意：

*  `ZooKeeper`运行需要JDK环境。
 *  如果个人资源有限，只有一台服务器的话，可以部署伪集群`ZooKeeper`，奇数，至少3个实例。

### 2、连接zookeeper客户端 ###

`ZooKeeper`安装完毕后，需要加一些测试数据，同时也可以验证下刚才是否安装成功：

# 连接客户端，默认连接2181
    sh zkCli.sh
    # 指定服务端连接
    sh zkCli.sh -server 127.0.0.1:2191

连接客户端后，如果显示`CONNECTED`，就说明安装成功了。

![连接zk客户端][zk]

执行如下命令，创建一些测试数据：

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][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命令][qconf]

qconf get_conf /demo/confs/conf1
    qconf get_batch_keys /demo/confs

![测试qconf命令][qconf 1]

### 5、Qconf配置文件 ###

`Qconf`的配置比较少也相对简单：

![qconf配置文件][qconf 2]

（1）agent.conf，`qconf_agent`的配置：

![agent.conf][]  
`qconf_agent`启动时会自动给zk注册一个临时节点（`register_node_prefix=/qconf/__qconf_register_hosts`），`qconf_agent`停止了，对应的zk临时节点也会自动清除，所以可以根据这个特性，判断`qconf_agent`是否存活。

基本逻辑是，定时获取zk`/qconf/__qconf_register_hosts`下`hostname`列表和现有的`hostname`列表进行对比，不在`/qconf/__qconf_register_hosts`里则认为该机器上的`qconf_agent`未运行。

（2）idc.conf，配置zk集群（这里配置了两个集群环境，一个test，一个dev，那`Qconf`是使用哪个集群呢？）：

![idc.conf][]

（3）localidc，指定qconf当前使用的zk集群环境：  
![localidc][]

## 三、SDK获取配置 ##

`Qconf`支持c/c++, shell, php, python, lua, java, go, node等语言获取配置，这里只介绍java方式，其他方式可参考[官方文档][Link 1]：

<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 3]

从下往上说，`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`的本地缓存对外提供服务。  
![qconf\_agent架构][qconf_agent]

### 4、获取配置更新同步流程 ###

1.  业务进程调用某一种语言的`QConf`**接口**，从**共享内存**(`Share Memory`)中查找需要的配置信息。
2.  如果存在，直接获取，否则会向**消息队列**(`Message Queue`)中加入该配置key。
3.  `qconf_agent`从**消息队列**中感知需要获取的配置key。
4.  `qconf_agent`向`ZooKeeper`查询数据并注册监听。
5.  `qconf_agent`将获得的配置`value`序列化后放入**共享内存**。
6.  业务进程等待，直到共享内存里出现所要读取的配置，然后从共享内存中获得最新值返回。

![获取配置更新同步流程][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA_size_1_color_FFFFFF_t_70_pic_center]

### 5、QConf如何保证数据正确性 ###

`qconf_agent`读写配置缓存是无锁的，那如何保证多线程下数据正确性呢？

**（1）单点写**

`qconf_agent`涉及更新配置缓存的场景有：

*  用户进程获取配置缓存中没有，将配置key放到消息队列。
 *  `ZooKeeper`配置修改删除等触发`Watcher`通知，需更新缓存。
 *  防止`Watcher`丢失造成数据不一致，需要定时对共享内存中所有配置重新注册`Watcher`，此时可能会更新缓存。
 *  发生`qconf_agent`重启、网络中断、`ZooKeeper`会话过期等异常情况，需重新拉数据，此时可能需要更新缓存。（数据落盘，应对断网情况下共享内存被清空的状况）

写操作基本属于内部异步触发，并发不是很大，可以将所有的写操作放到一个队列里，让一个线程去执行，保证写操作的顺序性和原子性。这样会牺牲一些性能， 但问题不大，用户基本不会感知。

**（2）读验证**

无锁的读写方式，会存在读到未写入完全数据的危险，但考虑到在绝对的读多写少环境中这种情况发生的概率较低，所以允许其发生，通过读操作时验证来尽量避免。

配置在序列化存储到共享内存时会计算md5值，业务进程读取配置时，利用预存的md5值验证数据是否正确。由于计算md5开销比较大，所以最新实现方法对于将要放入共享内存的数据，如果小于某一值（当前设置为1500）就将数据本身复制一份作为验证码，如果大于设定值还是采用md5。

### 6、qconf\_agent线程分工 ###

![qconf\_agent中线程分工][qconf_agent 1]

（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的角色，来监控所有服务的存活：

![qconf简单实现服务发现][qconf 4]

开源的Monitor仅仅是通过查看服务端口的存活来判断的，实际生产环境中，判断因素较复杂，比如服务监控，异常数，流量等。

实际生产中可以利用`Qconf`提供的简单服务发现功能基础上进行改造，也可以自行实现监控服务判活的服务，依然用`QCconf`的简单配置，服务发现的集群标识解析成一个目录，这个目录下包含该集群的所有`ip:port`，可作为配置key，服务的状态作为配置value。

## 五、要点总结 ##

`QConf`是一个不错的配置管理工具，容易部署，使用简单。其架构设计理念有很多值得学习的地方：

1.  `QConf`使用`ZooKeeper`服务器存储所有的配置信息，配置名为zk的节点名，配置项的值为zk的节点值。
2.  `QConf`利用`ZooKeeper`的监听回调机制，注册感兴趣的事件监听(`watcher`)，实现配置及时更新和同步。
3.  `QConf`高效和高可用设计思路体现在很多地方，比如无锁化读写、共享缓存、消息队列等。业务进程读取配置不会直接和zk或者`qconf_agent`进行交互，完全异步，全权交由`qconf_agent`的异步线程做配置监听和更新操作。
4.  无锁的读写方式，会存在读到未写入完全数据的危险，为了保证数据正确性，`qconf_agent`采用了两个措施：单点写，集中一个线程做写操作，保证写顺序性和原子性；读验证，共享内存数据在序列化时会带其md5值，业务进程从共享内存中读取时，利用预存的md5值验证是否正确读取。

因为`QConf`是C语言写的，暂时看不懂源码，所以很多原理概念都是理解官方文档后整理，同时官方文档有些措辞上不太通顺，部署文档中给的安装包较旧，文档较乱、冗杂，所以通读后整理，有些地方写的很好，很精炼，就直接摘抄过来了，所有关于原理的图片均来自官方文档。非常感谢[Qihoo360/QConf][Link 1]，学到很多优秀的架构理念。

官方文档：

*  [https://github.com/Qihoo360/QConf][Link 1]
 *  [从配置文件到分布式配置管理QConf][QConf]

*如若文章有错误理解，欢迎批评指正，同时非常期待你的评论、点赞和收藏。*

[zk]: /images/20221005/636d1b8244f5428baeac15c7f620acf4.png
[https_github.com_Qihoo360_QConf_releases]: https://github.com/Qihoo360/QConf/releases
[qconf]: /images/20221005/af61eaa10fea485cb94c3916ba8c9b13.png
[qconf 1]: /images/20221005/1ff30a0cf56e447a83b114787ff7e758.png
[qconf 2]: /images/20221005/b9d7da439cce4911aaaa83d12090dd21.png
[agent.conf]: /images/20221005/218bdff9aca9475a90614218846bbe2b.png
[idc.conf]: /images/20221005/816079c11462415eb10b2e26af722c44.png
[localidc]: /images/20221005/cc7d761d415147a6b4ed8577cd0ae450.png
[Link 1]: https://github.com/Qihoo360/QConf
[qconf 3]: /images/20221005/5691ca302bb448f78e762eb7be140788.png
[qconf_agent]: /images/20221005/64ddda1b4434468dba6c8727e50d2411.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNjU4NjEyMA_size_1_color_FFFFFF_t_70_pic_center]: /images/20221005/fbb651b6cddb4bdc8c3b7ba02aec5428.png
[qconf_agent 1]: /images/20221005/988fcf56dfce434693b30879e0104017.png
[qconf 4]: /images/20221005/3828092b8e7c4fd592c25add84d87a64.png
[QConf]: http://catkang.github.io/2015/06/23/qconf.html