随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：
- 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏。
- 时效性：修改配置，需要重启服务才能生效。
- 局限性：无法支持动态调整：例如日志开关、功能开关。
因此，分布式配置中心应运而生！
开源配置中心
- spring-cloud-config：spring开源的配置中心，和spring cloud无缝配合，依赖Eureka。
- diamond： 淘宝开源产品，已经停止维护。
- disconf：百度开源产品，已经停止维护。
- ctrip apollo ：携程开源产品，具备规范的权限、流程治理等特性。
- nacos：阿里开源产品。
配置中心对比
| 功能点 | 优先级 | spring-cloud-config | ctrip apollo | nacos |
|---|---|---|---|---|
| 静态配置管理 | 高 | 基于file | 支持 | 支持 |
| 动态配置管理 | 高 | 支持 | 支持 | 支持 |
| 统一管理 | 高 | 无，需要github | 支持 | 支持 |
| 多环境 | 中 | 无，需要github | 支持 | 支持 |
| 本地配置缓存 | 高 | 无 | 支持 | 支持 |
| 配置生效时间 | 高 | 重启生效，或手动refresh生效 | 实时 | 实时 |
| 配置更新推送 | 高 | 需要手工触发 | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
| 版本管理 | 高 | 支持(Git) | 支持 | 支持 |
| 权限管理 | 中 | 支持(依赖Git) | 支持 | 不支持 |
| 灰度发布 | 中 | 支持 | 支持 | 不支持 |
| 配置回滚 | 高 | 支持(Git) | 支持 | 支持 |
| 监听查询 | 高 | 支持 | 支持 | 支持 |
| 多语言 | 低 | 只支持Java | 主流语言，提供了Open API | 主流语言，提供了Open API |
| 配置格式校验 | 高 | 不支持 | 支持 | 支持 |
| 配置界面 | 中 | 无，需要通过git操作 | 统一界面（ng编写） | 统一界面 |
| 业务系统侵入性 | 高 | 侵入性弱 | 侵入性弱 | 侵入性弱 |
| 单机读(QPS) | 高 | 7(限流所致) | 9000 | 15000 |
| 单击写(QPS) | 高 | 5(限流所致) | 1100 | 1800 |
| 3节点读(QPS) | 高 | 21(限流所致) | 27000 | 45000 |
| 3节点写(QPS) | 高 | 5(限流所致) | 3300 | 5600 |
从配置中心角度来看，性能方面Nacos的读写性能最高，Apollo次之，Spring Cloud Config依赖Git场景不适合开放的大规模自动化运维API。功能方面Apollo最为完善，nacos具有Apollo大部分配置管理功能，而Spring Cloud Config不带运维管理界面，需要自行开发。Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。
?综合来看，Nacos的特点和优势还是比较明显的。