一、配置中心的必要性
当代码中有一些变量可能会动态变化时，或者一些变量使用的地方比较多，此时就可以采用配置的方式来动态读取，而不是将变量的值写死在代码里，否则难以维护，所以应用程序就有了配置文件。单机应用程序的配置通常就是配置文件，集群程序的配置就需要配置中
心。如果没有配置中心，那么在以下场景就会带来不便。
场景一：程序运行时修改配置
采用配置文件的方式，程序启动时读取配置文件并将配置读取赋值到程序变量中，此时修改配置文件已经无法修改程序中的变量值，只能重启应用程序才可以修改
场景二：集群部署修改配置
采用配置文件的方式，如果需要修改配置文件，那么在集群模式下就需要依次修改所有集群节点的配置文件，当集群规模较大时，修改配置文件的工作量会很大
场景三：多环境下修改配置
项目从开发到发布，会依次经历开发->测试->预发->生产等环境，不同环境的配置不尽相同，采用配置文件的话就需要同时维护多份配置文件或者频繁修改配置文件，无论哪一种都比较繁琐。
总结：
采用配置中心可以保证配置的安全性、时效性和动态扩展性。所以有一套能够服务于集群部署、多环境部署、能动态调整的配置中心就显得尤为重要，虽然不能给程序带来性能提升，但是能够大大提高项目运行的灵活性以及提高开发和运维的工作效率。
二、配置中心的功能
配置中心基本功能
1、配置维护：配置的增删改查
2、配置持久化：配置中心存储配置信息，需要保证添加的配置不会丢失，通常会存储在数据库
3、环境隔离：不同环境的配置之间相互隔离，互不影响
4、可视化管理：通过管理后台方便的进行配置管理
配置中心高级功能
5、版本管理：配置有不同版本，可随时查询不同版本的配置，并且可以根据版本进行回滚操作
6、实时更新：配置更新后，应用程序及时感知并更新本地缓存
7、灰度发布：当配置的变更影响比较大的时候，需要先在部分应用实例中验证配置的变更是否符合预期，然后再推送到所有应用实例
8、数据一致性：当配置中心是集群部署时，需要保证数据的一致性
9、高可用性：配置中心需要保证高性能、高稳定性，确保应用程序随时获取配置
三、配置中心整体架构
配置中心整体架构比较简单，只需要提供API给客户端，然后采用数据库存储配置信息即可。而基于配置的实时更新可以采用客户端长轮训查询的方式，也可以采用配置中心服务器推送的方式。
对于获取配置是pull还是push的方式，两种方式都各有利弊，所以需要看具体的配置中心是如何权衡来实现。
基于pull方式：实时性不高，需要客户端不断轮训查询最新配置，决定权在于客户端，服务器可以采用集群提供性能；
基于push方式：实时性高，但是客户端需要和服务器保持长连接，当服务器集群部署时，客户端需要和每一台服务器保持长连接，连接的维护比较复杂；
四、配置中心选型
目前开源的配置中心有很多，如Diamond、XDiamond、disconf、springcloud config、apollo、nacos等等，而目前热门的有disconf、springcloud config、apollo、nacos，这几种配置中心对比如下：
| disconf | springcloud config | apollo | nacos | |
| 开源 | 百度开源 | Spring开源 | 携程开源 | 阿里开源 |
| 配置存储 | 数据库 | git | 数据库 | 数据库 |
| 时效性 | 实时推送，基于ZK的watch机制 | 手动拉取，需要配合spring cloud bus来实现消息通知 | 轮训查询，定时调用HTTP接口 | 轮训查询，定时调用HTTP接口 |
| 版本管理 | 不支持 | 支持 | 支持 | 支持 |
| 灰度发布 | 不支持 | 不支持 | 支持 | 支持 |
| 回滚 | 不支持 | 支持 | 支持 | 不支持 |
| 支持语言 | Java | Java | 多语言 | 多语言 |
| 通信协议 | HTTP | HTTP、AMQP | HTTP | HTTP |
| 多环境 | 支持 | 支持 | 支持 | 支持 |
| 多集群 | 支持 | 支持 | 支持 | 支持 |
| 读写性能 | 不高 | 低 | 比较高 | 非常高 |
| 管理平台 | 有 | 无 | 有 | 有 |
| 优缺点 |
时效性好；停止维护；功能支持较少；需要依赖Zookeeper |
和spring cloud体系契合度较高，且依赖git、MQ等组件，运维成本最高 | 部署组件较多，功能支持全面 | 部署简单，运维成本低，且并发读写性能最好 |
综合来看，apollo和nacos从实现逻辑和功能支持上都比较类似，比disconf、springcloud config而已功能更丰富，生态支持要更好。所以选用时可以优先选择apollo或nacos。
apollo比nacos功能支持更多，但是使用和运维比nacos要更复杂，而nacos除了可以当作配置中心，还可以用于服务注册与发现，nacos使用和部署简单，且读写性能要更好。
具体应用时选择哪种配置中心可以根据项目的实际情况进行选择，如果是需要功能支持更丰富的专业的配置中心就可以选用apollo；如果是需要高性能，部署简单且同时使用到服务发布与订阅时就可以考虑采用nacos。
相关文档：