1.Nacos配置中心
什么是配置
应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个声明周期,比如数据库连接参数、启动参数、定制化业务参数等。
配置的特点
-
配置是独立于程序的制度变量
配置对于程序是只读的,程序通过读取配置来改变自己的行为,但是程序不改变配置 -
配置伴随应用的整个声明周期
配置贯穿于应用的整个生命周期,应用在启动时通过读取配置来初始化,在运行中根据配置调整行为。
比如:启动时读取服务的端口号,数据库连接信息,系统在运行中读取定时策略执行定时任务等。 -
配置的多种加载方式
-
hard code 硬编码,也就是代码中写死参数
-
配置文件
-
DB 配置表
-
and so on...
- 配置治理
同一份程序在不同的环境(开发、测试、生产)、不同的集群(上海数据节点中心、深圳数据节点中心等)需要不同的配置,所以需要有完善的环境和集群配置管理
什么是配置中心
在微服务架构中,当系统从一个单体应用,被拆分成分布式系统成为一个个服务节点后,配置文件也必须跟着迁移(分割),这样配置就分散了,不仅如此,分散中还包含着冗余,如下图:
下图显示了配置中心的功能,配置中心将配置从各应用中剥离出来,对配置进行统一管理,应用自身不需要自己去管理配置。
配置中心对比介绍
目前互联网中用的比较多的配置中心有:Spring Cloud Config、Apollo、Nacos和Disconf等
由于Disconf不再维护,故下面主要对比Spring Cloud Config、Apollo、Nacos。
对比项目 | Spring Cloud Config | Apollo | Nacos |
---|---|---|---|
所属源 | Spring Could 官方的配置中心 | 携程开源的项目 | 阿里开源的项目 |
配置实时推送 | 支持(Spring Cloud Bus) | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
版本管理 | 支持(Git) | 支持 | 支持 |
配置回滚 | 支持(Git) | 支持 | 支持 |
灰度发布 | 支持 | 支持 | 不支持 |
权限管理 | 支持(依赖Git) | 支持 | 1.2.0版本开始支持 |
多集群 | 支持 | 支持 | 支持 |
多环境 | 支持 | 支持 | 支持 |
监听查询 | 支持 | 支持 | 支持 |
多语言 | 只支持java | 主流语言,提供了Open API | 主流语言,提供了Open API |
配置格式校验 | 不支持 | 支持 | 支持 |
单击读(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。
- 配置中心>x功能方面
-
Apollo最为完善
-
nacos具有Apollo大部分配置管理功能,
-
Spring Cloud Config不带运维管理界面,需要自行开发。
- Nacos的一大优势是整合了注册中心、配置中心功能,部署和操作相比Apollo都要直观简单,因此简化了架构复杂度,并减轻运维及部署工作。
综合来看,Nacos的特点和优势还是比较明显的。
参考资料:灰度发布
灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式。灰度发布属于增量发布。
服务升级的过程中,新旧版本会同时为用户提供服务。让一部分用户继续用老功能,一部分用户开始用新功能,如果用户对新功能没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到新功能上面来。
灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证影响力度。