微服务改造实践(1)-配置中心

一、问题发现

之前使用配置文件的形式进行管理，比如MySQL配置文件分为:

• db.properties
• db.dev.properties
• db.test.properties
• db.prod.properties

在部署到对应环境的时候，比如到test环境，运维会执行类似mv db.test.properties db.properties的命令，将对应环境的文件覆盖到程序指定的文件db.properties。
除此之外，还有很多配置文件都与运行环境相关联，在不同的环境必须设置不同的值。

随着越来越多服务上线，陆续暴露了很多问题：

1. 配置文件过多，过于分散，开发人员稍不留意就容易出错,并且运维人员很难审核排错
2. 配置无法追溯，无法回滚
3. 修改配置需要重启，希望能够在程序运行时动态调整部分配置
4. 所有开发人员都能看到线上生产环境配置，安全性很差

二、找寻方案

所以我们希望能有这样一个组件或者一套系统，能够实现如下功能：

1. 集中管理配置
2. 与程序分离，避免开发误操作影响系统
3. 配置支持版本控制
4. 配置能够动态生效
5. 能有权限和审核机制
6. UI管理界面

那从2017年开始，陆续我们已经看到了不少开源配置中心的发布，所以开始调研了一下目前开源的一些配置中心。

• Consul（生态在国内并不好）
• Disconf （无UI，生态比Apollo差很多）
• Diamond （停止维护）
• Spring Cloud Config （配置重启才生效）
• Nacos
• Ctrip Apollo

最终能够满足需求的只有Apollo和Nacos, 而Apollo已经很成熟，经历过太多生产环境的实践，所以最终选择了Apollo.