0. 环境
-
nacos版本:1.4.1
-
Spring Cloud : 2020.0.2
-
Spring Boot :2.4.4
-
Spring Cloud alibaba: 2.2.5.RELEASE
-
Spring Cloud openFeign 2.2.2.RELEASE
测试代码:github.com/hsfxuebao/s…
1. 配置中心基础
1.1 为什么要用配置中心?
-
配置实时生效:传统的静态配置方式要想修改某个配置只能修改之后重新发布应用,要实现动态性,可以选择使用数据库,通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长,轮询频率高,感知配置变化的延时就短,但比较损耗性能,需要在实时性和性能之间做折中。配置中心专门针对这个业务场景,兼顾实时性和一致性来管理动态配置;
-
配置管理流程:配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性,也是配置中心不可获取的一部分;
-
分布式场景:随着采用分布式的开发模式,项目之间的相互引用随着服务的不断增多,相互之间的调用复杂度成指数升高,每次投产或者上线新的项目时苦不堪言,需要引用配置中心治理。
1.2 配置中心支持功能
-
灰度发布:配置的灰度发布是配置中心比较重要的功能,当配置的变更影响比较大的时候,需要先在部分应用实例中验证配置的变更是否符合预期,然后再推送到所有应用实例。
-
权限管理:配置的变更和代码变更都是对应用运行逻辑的改变,重要的配置变更常常会带来核弹的效果,对于配置变更的权限管控和审计能力同样是配置中心重要的功能。
-
版本管理&回滚:当配置变更不符合预期的时候,需要根据配置的发布版本进行回滚。
-
配置格式校验:应用的配置数据存储在配置中心一般都会以一种配置格式存储,比如Properties、Json、Yaml等,如果配置格式错误,会导致客户端解析配置失败引起生产故障,配置中心对配置的格式校验能够有效防止人为错误操作的发生,是配置中心核心功能中的刚需。
-
监听查询:当排查问题或者进行统计的时候,需要知道一个配置被哪些应用实例使用到,以及一个实例使用到了哪些配置。
-
多环境:在实际生产中,配置中心常常需要涉及多环境或者多集群,业务在开发的时候可以将开发环境和生产环境分开,或者根据不同的业务线存在多个生产环境。如果各个环境之间的相互影响比较小(开发环境影响到生产环境稳定性),配置中心可以通过逻辑隔离的方式支持多环境。
-
多集群:当对稳定性要求比较高,不允许各个环境相互影响的时候,需要将多个环境通过多集群的方式进行物理隔离。
2. 常用配置中心
如果只要能作为分布式存储的服务都作为配置中心,那选择途径就太多了, 比如Zookeeper和ETCD,所以需要提前说明一下。
但是我们选择配置中心时,为什么不优先考虑Zookeeper和ETCD,因为以下两点原因:
-
没有方便的UI管理工具,且缺乏权限、审核、灰度发布、审核机制等;
-
最重要的是,Zookeeper和ETCD通常定义为服务注册中心,统一配置中心的事情交给专业的工具去解决。
所以给大家介绍的配置中心,主要是以下4种,分别为 Disconf、Spring Cloud Config、Apollo 和 Nacos。
2.1 Apollo
GitHub:github.com/apolloconfi…
Apollo(阿波罗)是携程框架部门研发的开源配置管理中心,具备规范的权限、流程治理等特性。
2.1.1 Apollo框架
Apollo的框架有点复杂,如果不考虑分布式微服务架构中的服务发现问题,Apollo的最简架构如下图所示:
这里面包含Apollo框架的4个核心模块:
-
ConfigService:提供配置获取接口,提供配置推送接口,服务于Apollo客户端。
-
AdminService:提供配置管理接口,提供配置修改发布接口,服务于管理界面Portal。
-
Client:为应用获取配置,支持实时更新,通过MetaServer获取ConfigService的服务列表,使用客户端软负载SLB方式调用ConfigService。
-
Portal:配置管理界面,通过MetaServer获取AdminService的服务列表,使用客户端软负载SLB方式调用AdminService。