Nacos不但可以作为我们的注册中心,他还有一个功能,就是整合我们所有微服务中的配置文件.在企业开发中,一个springcloud项目会有很多小的微服务,对于那些特别常用的微服务来说,甚至还要搭建集群.那么设想一个场景,假如我们有一个支付系统的服务,并且这个服务搭建了很多集群,如果我们把配置文件写在服务里,那么未来有一天收款的账号换了,我们必须要手动一个一个去修改配置文件.但是如果我们把配置文件也添加到配置中心里,然后让每个微服务去引用配置中心里的配置,这样就可以很大程度上解决问题.

        配置中心的思路是：

1. 首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。
2. 当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。
3. 当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

当加入了服务配置中心之后，我们的系统架构图会变成下面这样：

        配置中心有很多种,不止有Nacos这一个版本.在业界常见的服务配置中心，有下面这些：

• Apollo------>很多使用apollo

Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料 也写的很详细。

• Disconf

Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效的。

• SpringCloud Config

这是Spring Cloud中带的配置中心组件。它和Spring是无缝集成，使用起来非常方便，并且它的配置存储支持Git。不过它没有可视化的操作界面，配置的生效也不是实时的，需要重启或去刷新。

• Nacos

这是SpingCloud alibaba技术栈中的一个组件，前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能，我们可以直接使用它作为服务配置中心。

这里我们主要讲解Nacos的配置中心.

一.引入依赖

在所有的服务中(但凡是需要写配置文件的)都添加上配置中心的依赖.

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
dependency>

二.在Nacos中添加配置

(1)找到Nacos的配置列表,点击 "+" 添加配置

 (2)编写配置

 举例:

 关于添加配置需要注意的一些地方:

1. 配置文件名称尽量要和微服务名称相同,且保证唯一性
2. Group在不修改的情况下默认为DEFAULT_GROUP
3. 配置格式不要选错
4. 可以添加命名空间来实现不同的场景下的不同配置.例如我们企业中一般都会有 开发环境(dev),测试环境(test)和线上环境(online). 命名空间可以理解为不同的环境

 建好以后会显示你已有的命名空间和对应的ID.未来我们在项目中引用配置文件需要的就是这个ID

当我们配置好命名空间以后,我们可以把配置文件写到对应的命名空间里.

 如果我们想把别的空间的配置文件复制一份到另外一个命名空间中,我们可以直接克隆.

 可以看到已经克隆成功:

 5.我们可以将公共的配置文件内容抽取出来.例如:数据源的配置,nacos的地址,sql日志等等

datasource.properties:

         需要注意的问题:

        公共配置的文件名,必须加上后缀名称.这是为了配合我们下一步在服务中引用配置文件做准备,如果不加后缀名,可能会造成引用失败.

三. 在服务中引入配置中心的配置文件.

① 在resource文件夹下新建文件:bootstrap.properties.

名称一定为bootstrap.properties,不能修改.

② 编写bootstrap.properties文件

#服务名称
spring.application.name=lrs-order
#引入lrs-order的配置文件
#配置文件名称
spring.cloud.nacos.config.name=lrs-order
#配置文件的地址
spring.cloud.nacos.config.server-addr=localhost:8848
#命名空间的ID
spring.cloud.nacos.config.namespace=12df4238-dfa6-4fa6-b26c-55ad5b1c30d0
 
#引入公共配置文件
#公共配文件的文件名
spring.cloud.nacos.config.extension-configs[0].data-id=datasource.properties
#公共配置文件所在分组
spring.cloud.nacos.config.extension-configs[0].group=DEFAULT_GROUP
#是否刷新公共配置文件
spring.cloud.nacos.config.extension-configs[0].refresh=true
 
spring.cloud.nacos.config.extension-configs[1].data-id=naocs.properties
spring.cloud.nacos.config.extension-configs[1].group=DEFAULT_GROUP
spring.cloud.nacos.config.extension-configs[1].refresh=true
 
spring.cloud.nacos.config.file-extension=yaml

 需要注意的地方:

1. 如果在nacos配置了命名空间,那么一定要在引用的时候配置好配置文件所在命名空间的ID
2. 如果配置文件的文件名和注册中心中服务的名称相同,那么引入时配置文件的名称可以省略不写,只写服务的名称
3. GROUP如果没有修改,那么可以不用配置,引入时默认就是DEFAULT_GROUP,如果修改了就一定要配置上修改后的名称
4. 前面第二步里第5点也提到,公共配置文件的名称一定要加上后缀名,在引用时得以体现其作用.
5. file-extension用来选择引入的配置文件的文件格式,默认为properties,如果时yml类型需要修改其类型为yaml
6. extension-configs负责引入公共配置文件,该属性需要的值为list结构:

NacosConfigProperties.Config中需要的属性有下面这三个,所以我们引入一个公共配置文件的时候也需要填写这三个属性.

 

 四.自定义配置属性实现自动刷新

当我们修改了配置中心里的某个配置,那么如果不重启我们的服务,更新后的配置无法读取已经更新后的内容.这时我们可以在控制层的类名上加上@RefreshScope注解从而实现自动刷新.

举个例子:

lrs-product中加入一条自定义配置:student.name=lrs001

在服务中用@Value的方式引入该属性的值,在controller层随便写个@GetMapping返回给前端这个值. 记得在类上加入@RefreshScope注解实现自动刷新.

@RestController
@RequestMapping("product")
@RefreshScope
public class ProductController {
    
    @Value("${student.name}")
    private String name;
 
    
 
    @GetMapping("get")
    public String get(){
        return name;
    }
}

 浏览器中访问:

 这时我们把配置中心的该属性值修改为lrs002并点击发布

 再访问:

 自动刷新配置成功