通常我们在项目中会有很多参数需要配置到项目中去，应用程序在启动和运行的时候往往需要读取一些配置信息，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。
配置的几个特点： 1、配置是独立于程序的只读变量配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置
2、配置伴随应用的整个生命周期配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。
比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。
常见的有程序内部hard code，配置文件，环境变量，启动参数，基于数据库等
4、配置需要治理同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的
配置，所以需要有完善的环境、集群配置管理
在微服务架构中，当系统从一个单体应用，被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移，这样配置就分散了，不仅如此，分散中还包含着冗余，而配置中心的作用就是将配置从各应用中剥离出来，对配置进行统一管理，应用自身不需要自己去管理配置。
配置中心的服务流程：1、用户在配置中心更新配置信息。
2、服务A和服务B及时得到配置更新通知，从配置中心获取配置。
总得来说，配置中心就是一种统一管理各种应用配置的基础服务组件。
在系统架构中，配置中心是整个微服务基础架构体系中的一个组件，如下图。它的功能看上去并不起眼，无非就是
配置的管理和存取，但它是整个微服务架构中不可或缺的一环。
1、配置项容易读取和修改
2、分布式环境下应用配置的可管理性，即提供远程管理配置的能力
3、支持对配置的修改的检视以把控风险
4、可以查看配置修改的历史记录
5、不同部署环境下应用配置的隔离性
目前市面上用的比较多的配置中心有：Spring Cloud Config、Apollo、Nacos，下面是比对情况。
从配置中心角度来看，性能方面Nacos的读写性能最高，Apollo次之，Spring Cloud Config依赖Git场景不适合开
放的大规模自动化运维API。功能方面Apollo最为完善，nacos具有Apollo大部分配置管理功能，而Spring Cloud
Config不带运维管理界面，需要自行开发。Nacos的一大优势是整合了注册中心、配置中心功能，部署和操作相比
Apollo都要直观简单，因此它简化了架构复杂度，并减轻运维及部署工作。
首先在nacos发布配置，nacos-restful-consumer服务从nacos读取配置。
浏览器访问 http://127.0.0.1:8848/nacos ，打开nacos控制台，并点击菜单配置管理->配置列表：
在Nacos添加如下的配置：
nacos-restful-consumer:
注：如发布失败，按以下思路去排除错误。
1、nacos的版本和mysql的版本是否对应。 如果mysql是8.0以上，则nacos需1.4版本以上。
2、如果版本兼容，则需考虑mysql的url连接，用户名，密码是否正确。
要想从配置中心获取配置需添加nacos-config的依赖：
com.alibaba.cloud spring‐cloud‐starter‐alibaba‐nacos‐config
在bootstrap.yml添加配置：
spring: cloud: nacos: config: server‐addr: 127.0.0.1:8848 # 配置中心地址 file‐extension: yaml group: DEFAULT_GROUP
注意：要使用配置中心就要在bootstrap.yml中来配置，bootstrap.yml配置文件的加载顺序要比application.yml要优先。
在nacos-restful-consumer工程的controller中增加获取配置的web访问端点/configs，通过标准的spring @Value方式。
@Value("${common.name}")
private String common_name;
@GetMapping(value = "/configs")
public String getvalue(){
return common_name;
}
基于上面的例子，若要实现配置的动态更新，只需要进行如下改造：
// 注入配置文件上下文
@Autowired
private ConfigurableApplicationContext applicationContext;
@GetMapping(value = "/configs")
public String getConfigs(){
return applicationContext.getEnvironment().getProperty("common.name");
}
我们通过nacos控制台更新common.name的配置值，再次访问web端点/configs，发现应用程序能够获取到最新的配置值，说明spring-cloud-starter-alibaba-nacos-config 支持配置的动态更新。
注：Note 可以通过配置spring.cloud.nacos.config.refresh.enabled=false来关闭动态刷新
配置模型管理对于Nacos配置管理，通过Namespace、group、Data ID能够定位到一个配置集。
在系统中，一个配置文件通常就是一个配置集，一个配置集可以包含了系统的各种配置信息，例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。每个配置集都可以定义一个有意义的名称，就是配置集的ID即Data ID。
配置项配置集中包含的一个个配置内容就是配置项。它代表一个具体的可配置的参数与其值域，通常以 key=value 的形式存在。例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。
配置分组(Group)配置分组是对配置集进行分组，通过一个有意义的字符串（如 Buy 或 Trade ）来表示，不同的配置分组下可以有相同的配置集（Data ID）。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：可用于区分不同的项目或应用，例如：学生管理系统的配置集可以定义一个group为：STUDENT_GROUP。
命名空间(Namespace)命名空间（namespace）可用于进行不同环境的配置隔离。例如可以隔离开发环境、测试环境和生产环境，因为它们的配置可能各不相同，或者是隔离不同的用户，不同的开发人员使用同一个nacos管理各自的配置，可通过namespace隔离。不同的命名空间下，可以存在相同名称的配置分组(Group) 或 配置集。
如果想了解的更加深入，请看下图：
Namespace：代表不同环境，如开发、测试、生产环境。
Group：代表某项目，如XX医疗项目、XX电商项目
DataId：每个项目下往往有若干个工程，每个配置集(DataId)是一个工程的主配置文件
下面演示下获取某配置集的代码：
获取配置集需要指定：
1、nacos服务地址，必须指定
2、namespace，如不指定默认public
在config中指定namespace，例子如下：
config: server‐addr: 127.0.0.1:8848 # 配置中心地址 file‐extension: yaml namespace: a1f8e863‐3117‐48c4‐9dd3‐e9ddc2af90a8 # 开发环境 group: DEFAULT_GROUP # xx业务组
3、group，如不指定默认 DEFAULT_GROUP 见上边第2点的例子。
4、dataId，必须指定，名称为应用名称+配置文件扩展名
