聊一聊微服务常见配置中心工作原理

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。