Nacos Config

对于微服务框架而言，微服务的数量肯定是越来越多的，相同的微服务使用的配置文件都相同。如果要更改配置文件内容时，就需要进行大量的修改，修改所有的微服务配置文件。

微服务架构下关于配置文件的一些问题：

1. 配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。

2. 配置文件无法区分环境--开发环境  测试环境  线上环境。微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环

境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动

维护，这比较困难。

3. 配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。

基于上面这些问题，我们就需要配置中心的加入来解决这些问题。

配置中心的思路是：

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

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

一：使用nacos配置微服务的配置

引入依赖

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

将微服务的配置写入nacos中

 将原来微服务的配置文件删除，创建新的配置文件，文件名必须是 bootstrap.properties或者bootstrap.yaml/yml

编写配置新的配置文件

# 给微服务在nacos中指定服务名，这个服务名必须要和对应微服务的配置文件的前缀名相同
spring.application.name=order
# 指定naocs配置中心的地址
spring.cloud.nacos.config.server-addr=127.0.0.1:8848
# 配置中心中对应此为服务配置文件的后缀，默认就是properties，如果配置中心中的文件是properties可以不加，如果是yml或者yaml，则必须加
spring.cloud.nacos.config.file-extension=properties

重启微服务，进行测试

二：配置额外的配置文件

对于微服务而言，肯定会有多个微服务的配置文件中有相同的内容，例如对于数据源的配置，以及对于zipkin的配置，虽然为服务不相同，但是其中的内容是完全一样的。我们可以将相同的内容提取出来，创建成一个新的配置文件，然后所有的微服务都可以直接引用这个配置文件中的内容。

将配置文件中的关于DataSource的配置提取，创建一个新的datasource.properties。

 

然后将所有微服务的配置文件中的关于datasource配置删除，在配置文件中，引入datasource.properties配置文件

重启微服务，进行测试，可以正常进行请求的提交。

三：对于各种环境的配置 

一个项目从生产到测试再到发布，肯定是有不同的运行环境的，开发环境和测试环境，对应的配置文件内容肯定也不相同。如果我们直接将原本的配置文件删除，替换成新的配置文件这样是很麻烦的，所以我们可以在 nacos中，针对不同的环境，设置不同的配置文件，这样在项目的配置文件中，我们只需要引用就可以，在开发的时候，引用开发环境的配置文件，在测试的时候，引用测试的配置文件。

 

 创建好空间之后，将配置文件引入到空间中

    

 引入后，对应的命名空间的配置就会增加

 在项目的配置文件中引入命名空间，使用命名空间的ID号

重启微服务进行测试。

四：使用不同的组名 

在进行开发的时候，我们肯定不会一直都只写一个项目，我们就可以将项目的配置文件就可以进行分类，属于同一个项目的配置文件就放在同一个组下。然后在项目的配置文件中，声明要引入那个组的配置文件即可。

在nacos创建配置的时候，就需要将组指定，创建完成之后是不允许进行修改的