在一个分布式环境中，同类型的服务往往会部署很多实例。这些实例使用了同一套配置，为了更好地维护这些配置就产生了配置管理服务。通过配置管理可以解决分布式环境下多台服务实例的配置统一管理问题。
目前我们使用的测试框架中包含配置文件与配置信息，所带来的问题是很容易导致敏感信息泄露。同时对于测试框架应用的不同环境，配置信息也会需要做相应的修改，所以需要有个中间层来屏蔽这个区别。在调研现有的开源配置管理平台后决定试点 disconf 将部分业务的配置文件和配置信息从代码中剥离。通过 disconf 来方便管理多个服务实例的配置，也可以针对不同的环境设置不同的配置文件。
1、Disconf 是百度开源的分布式配置管理平台（Distributed Configuration Management Platform），可以为各种业务平台提供统一的配置管理服务。
特点：
2、测试框架 hydra 介绍：我们的测试框架分为两个部分：框架 hydra+ 测试用例 hydra_case（设计框架见下图）。测试脚本用 javascript 编写，框架用 java 实现。通过 nashorn 引擎做到测试框架与测试用例分离，运行测试用例时只需调用框架封装好的第三方库即可（将第三方库上传远端，运行 case 时自动拉取最新的库）。通过 testlink 绑定对应的测试用例，执行测试用例后生成测试结果直接上传 redmine。其中测试用例所需的接口 url 等数据文件与框架所需的配置文件都存储在 disconf 配置管理平台，运行 case 时会自动获取。我们的框架底层也集成了各种测试服务包，包括 webdriver、appium、restful 等。
当然，未使用 disconf 前配置文件与数据文件是直接写在框架与测试用例文件中的。
disconf 具体的安装步骤在作者的 github 和文档中写的很清楚了，这里不再重复
安装依赖软件：Mysql、Tomcat、Nginx、Zookeeper、Redis。
使用：为了 client 能使用 disconf 中配置文件，通过研究发现需要强依赖 java 的 Spring 框架，依靠注解的方式获取 disconf 远端存储的配置文件。然而我们现有的测试框架中未使用 spring，再结合 dev 使用的是 python，如果强制引入 spring 的话代价有点大。好在通过 disconf 作者给出的文档和查看源代码发现 disconf 可以对配置进行持久化管理并对外提供 restful 接口。通过调用部分接口并对返回 result 进行解析很容易就可以获取到 disconf 上的配置文件或者配置项信息（此处我们对配置文件和数据文件分别作了解析：如 properties 和 json）。当然调试过程中也遇到一些问题，比如调用配置列表接口发现还需要登录认证。好在作者也提供了登录 api，只要调用登录接口记住 cookie 即可。
挑选 1 个 api 做解释：
/api/web/config/list：
描述：根据 app, env , version 获取所有的 配置列表，含有 machine size, machine list,error num 等信息
请求类型: GET
参数
| # | name | desc | 是否必要 |
|---|---|---|---|
| 1 | appId | app | 是 |
| 2 | envId | 环境 | 是 |
| 3 | version | 版本 | 是 |
返回示例:
{
"message": {},
"sessionId": "10df60bc-adfg-dggrg77159929",
"success": "true",
"page": {
"result": [
{
"configId": 152,
"appName": "app_test",
"appId": 1,
"version": "0.0.1",
"envId": 2,
"envName": "qa",
"type": "配置文件",
"typeId": 0,
"key": "test.properties",
"value": "auto=bbdxxjdccdcccdxdcdc\nauto2=cd",
"createTime": "20170703170620",
"modifyTime": "201707031706",
"machineSize": 0,
"machineList": null,
"errorNum": 0
}，
"pageNo": null,
"pageSize": null,
"orderBy": "name",
"totalCount": 1,
"footResult": null,
"order": "asc"
}
}
/api/account/signin：
描述：登录
请求类型: POST
参数
| # | name | desc | 是否必要 |
|---|---|---|---|
| 1 | name | 用户名 | 是 |
| 2 | password | 密码 | 是 |
| 3 | remember | 是否记住自己 | 是 |
失败示例：
{
"sessionId": "5b9270-7149-4c55-af96-3bf60741b",
"message": {
"field": {
"password": "密码不正确"
}
},
"success": "false",
"status": 2000
}
成功示例
{
"message": {},
"sessionId": "029efac2d-fec1-40c7-b0d2-8433fb8a8c2c76",
"success": "true",
"result": {
"visitor": {
"id": 6,
"name": "admin",
"role": null
}
}
}
创建/获取单个配置项、配置文件等也都可以通过 api 接口实现，即使想对 disconf-web 进行改造和接口封装也是比较容易实现的。为了结合 disconf 作为我们测试框架的配置管理中心，我们不仅支持了 java 版本的配置文件解析，python 版本的接口实现之后也会支持方便更多的服务使用 disconf。
以上是我们测试框架与 disconf 结合使用的简单介绍。
使用 disconf 存储配置信息带来的好处是 1、可以做到敏感信息与代码分离，而使用 api 方式接入获取配置信息简单方便不需要引入任何额外的依赖。2、解决了测试用例部署到不同环境运行时配置文件的不同问题（无需在代码中对不同环境分别写入各自的配置信息）。3、变更配置或者测试数据只需平台操作即可，无需更改代码。
暂时由于 api 的获取配置方式，我们还没有做到支持依赖 zk 获得实时更新配置信息的推送。这也是接下来我们需要去做的事情~
