基本介绍
概述
Nacos除了可以做注册中心，同样可以做配置管理来使用。
所谓配置中心：一般SpringBoot项目都使用在resources下创建类似
application.yml之类的配置文件来管理整个项目的一些配置信息
当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理所有实例的配置。
采用本地静态配置，无法保证实时性：修改配置不灵活且需要经过较长的测试发布周期，无法尽快通知到客户端，还有些配置对实时性要求很高，比方说主备切换配置或者碰上故障需要修改配置，这时通过传统的静态配置或者重新发布的方式去配置，那么响应速度是非常慢的，业务风险非常大
动态配置服务
- 动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
- 动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
- 配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。 Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
多配置格式编辑器
Nacos支持 YAML、Properties、TEXT、JSON、XML、HTML 等常见配置格式在线编辑、语法高亮、格式校验，帮助用户高效编辑的同时大幅降低格式错误带来的风险。
Nacos支持配置标签的能力，帮助用户更好、更灵活的做到基于标签的配置分类及管理。同时支持用户对配置及其变更进行描述，方便多人或者跨团队协作管理配置。
微服务拉取配置流程
微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。但如果尚未读取application.yml，又如何得知nacos地址呢？
因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取
springboot中配置文件的加载是存在优先级顺序的，bootstrap优先级高于application
Data ID
公式：${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
- prefix 默认为 spring.application.name 的值
- spring.profile.active 即为当前环境对应的 profile，可以通过配置项 spring.profile.active 来配置。
- file-exetension 为配置内容的数据格式，可以通过配置项 spring.cloud.nacos.config.file-extension 来配置
通俗一点就是 “前缀-环境-扩展名”
spring: application: name: studentservice # 服务名称 profiles: active: dev #开发环境，这里是dev cloud: nacos: server-addr: localhost:8848 # Nacos地址 config: file-extension: yaml # 文件后缀名
@RefreshScope
SpringCloud 使用 @RefreshScope注解，实现配置文件的动态加载。 @RefreshScope 注解是一个基于 Spring Cloud Config 的注解。它允许 Spring Boot 应用程序在运行时动态地刷新配置，而无需重启应用程序。使用 @RefreshScope 注解，可以在不停止应用程序的情况下修改配置。
在 Spring Boot 中，@RefreshScope 注解是基于 Spring Cloud Config 实现的。Spring Cloud Config 是一个用于集中化配置管理的工具。它可以将配置存储在 Git、SVN 或本地文件系统中，并将其提供给多个应用程序。
当应用程序中使用了 @RefreshScope 注解时，Spring Boot 将会监控配置文件的变化。当配置文件发生变化时，Spring Boot 将会重新加载配置并重新初始化相关的 Bean。这样，就可以在应用程序运行时动态地修改配置。
配置共享的优先级
当nacos、服务本地同时出现相同属性时，优先级有高低之分：
实战使用
简单的共享配置
不区分工作环境，即不设置profiles.active，则在Nacos中的配置文件只需要spring.application.name.spring.cloud.nacos.config.file-extension
代码示例：
pom主要依赖
<!--nacos配置管理依赖--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency>
bootstrap.yaml
spring: application: name: studentservice # 服务名称 cloud: nacos: server-addr: localhost:8848 # Nacos地址 config: file-extension: yaml # 文件后缀名
application.yaml
server: port: 8002 version: kk
controller配置类
@RestController @RefreshScope public class StudentController implements Serializable { @Value("${version}") String version; @GetMapping("/version") public String version(){ return version; } }
启动项目以后可以访问下/version得到的是kkk
在Nacos中创建一个配置文件名为：
发布以后再次访问/version得到是yy
开发环境的共享配置
实际开发中，通常一个系统会准备
- dev开发环境
- test测试环境
- prod生产环境。
如何保证指定环境启动时服务能正确读取到Nacos上相应环境的配置文件呢？
我们只要区分工作环境，这次需要设置profiles.active。
修改bootstrap.yaml文件
spring: application: name: studentservice # 服务名称 profiles: active: dev #开发环境，这里是dev cloud: nacos: server-addr: localhost:8848 # Nacos地址 config: file-extension: yaml # 文件后缀名
在Nacos中创建一个配置文件名为：
发布以后再次访问/version得到是wwww
环境隔离-命名空间Namespace
一个大型分布式微服务系统会有很多微服务子项目，每个微服务项目又都会有相应的开发环境、测试环境、预发环境、正式环境，那怎么对这些微服务配置进行管理呢？
Nacos 引入命名空间 Namespace 的概念来进行多环境配置和服务的管理及隔离。例如，你可能存在本地开发环境dev、测试环境test、生产环境prod 三个不同的环境，那么可以创建三个不同的 Namespace 区分不同的环境。
成功创建新命名空间后，就可以在 springboot 的配置文件配置命名空间的 id 切换到对应的命名空间，并获取对应空间下的配置文件，但在没有指定命名空间配置的情况下，默认的配置都是在 public 空间中，指定命名空间的方式如下：
cloud: nacos: config: namespace:483bb765-a42d-4112-90bc-50b8dff768b1
业务隔离-Group分组
Group 也可以实现环境隔离的功能，但 Group 设计的目的主要是做同一个环境中的不同服务分组，把不同的微服务的配置文件划分到同一个分组里面去，Nacos 如果不指定 Group，则默认的分组是 DEFAULT_GROUP。
spring: cloud: nacos: config: group: xxxx
