1. 配置
应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参 数等。
配置的特点：
- 配置是独立于程序的只读变量
-
配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为
-
其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置
- 配置伴随应用的整个生命周期
配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。比如：启动时需要读取服务的端口 号、系统在运行过程中需要读取定时策略执行定时任务等。
- 配置可以有多种加载方式
常见的有程序内部硬编码，配置文件，环境变量，启动参数，基于数据库等
- 配置需要治理
-
权限控制：由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制
-
不同环境、集群配置管理：同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理
2 配置中心
在传统的单体应用架构下，多个服务在同一主机上运行，多服务之间产生了强耦合性，导致在修改程序时需要全局修改并且需要整体发布，并且不同服务的承载量不同难以进行水平扩容，排错难度大不适合现实需要，因此发展出服务分离的分布式架构。
正如每一个应用程序在运行时都需要相应的配置（目前配置主流应用配置文件的形式），而在分布式架构下多个服务器和应用服务面临着多个配置文件，在修改和发布上难度较大，需要有一个管理中心来统一管理，优雅的解决了配置的动态变更、持久化、运维成本等问题。综上所述，配置中心就是一种统一管理各种应用配置的基础服务组件。
image-20200703172458675
一个配置中心的基本要求包括：
-
配置项容易添加、读取和修改
-
支持对配置的修改的检视以把控风险
-
可以查看配置修改的历史记录
-
不同部署环境支持隔离
3 主流配置中心
目前市面上用的比较多的配置中心有：（按开源时间排序）
1.Disconf
2014年7月百度开源的配置管理中心，专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」。目前已经不再维护更新。
https://github.com/knightliao/disconf
2.Spring Cloud Config
2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
https://github.com/spring-cloud/spring-cloud-config
3.Apollo
2016年5月，携程开源的配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
https://github.com/ctripcorp/apollo
4.Nacos
2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。
https://github.com/alibaba/nacos
由于Disconf不再维护，下面主要对比一下Spring Cloud Config、Apollo和Nacos。
| 功能点 | Spring Cloud Config | Apollo | Nacos |
|---|---|---|---|
| 配置实时推送 | 支持(Spring Cloud Bus) | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
| 版本管理 | 支持(Git) | 支持 | 支持 |
| 配置回滚 | 支持(Git) | 支持 | 支持 |
| 灰度发布 | 支持 | 支持 | 不支持 |
| 权限管理 | 支持(依赖Git) | 支持 | 不支持 |
| 多集群 | 支持 | 支持 | 支持 |
| 多环境 | 支持 | 支持 | 支持 |
| 监听查询 | 支持 | 支持 | 支持 |
| 多语言 | 只支持Java | 主流语言，提供了Open API | 主流语言，提供了Open API |
| 配置格式校验 | 不支持 | 支持 | 支持 |
| 单机读(QPS) | 7(限流所致) | 9000 | 15000 |
| 单击写(QPS) | 5(限流所致) | 1100 | 1800 |
| 3节点读(QPS) | 21(限流所致) | 27000 | 45000 |
| 3节点写(QPS) | 5限流所致() | 3300 | 5600 |
总的来看，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面，Nacos则使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。但对于一个开源项目的选型，项目上的人力投入（迭代进度、文档的完整性）、社区的活跃度（issue的数量和解决速度、Contributor数量、社群的交流频次等），这些因素也比较关键，考虑到Nacos开源时间不长和社区活跃度，所以从目前来看Apollo应该是最合适的配置中心选型。
网友评论