详解Nacos的配置管理

前言

Nacos除了可以做注册中心，同样可以做配置管理来使用。

1. 统一配置管理

当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理实现所有实例的配置。

Nacos一方面可以将配置集中管理，另一方面在配置变更时，及时通知微服务，实现配置的热更新。

1.1 在nacos中添加配置文件

如何在nacos中管理配置呢？

然后再弹出的表单中，填写配置信息：

分布之后，可以在配置列表里看到我们刚刚配置的yaml：

注意：项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。 

1.2 从微服务拉取配置

接下来，我都会用我的cloud-demo为例，在没有引入nacos配置之前，项目的启动过程如下：

现在引入了nacos配置功能，微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。但如果尚未读取application.yml，又如何得知nacos地址呢？

因此spring引入了一种新的配置文件：bootstrap.yml文件，会在application.yml之前被读取，流程就变更为：

1. 引入nacos-config依赖

首先，在user-service服务中，引入nacos-config的配置管理依赖

<!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

注意：因为我的父工程里引入了nacos的管理依赖，所以这里我不用加版本号，如果你的父工程里没有引入nacos的管理依赖，记得加上配置的版本号

2.  添加bootstrap.yml

然后，在user-service中添加一个bootstrap.yml文件，内容如下：

spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

这里会根据spring.cloud.nacos.server-addr获取nacos地址，再根据${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}作为文件id，来读取配置。

本例中，就是去读取userservice-dev.yaml：

3. 读取nacos配置

在user-service中的UserController中添加业务逻辑，读取pattern.dateformat配置：

在页面访问，可以看到效果：

1.3 总结

将配置交给Nacos管理的步骤：

• 在Nacos中添加配置文件
• 在微服务中引入Nacos的config依赖
• 在微服务中添加bootstrap.yml，配置nacos地址、当前环境、服务名称、文件后缀。这些决定了程序启动时去nacos读取哪个文件

 2. 配置热更新

我们最终的目的，是修改nacos中的配置后，微服务中无需重启即可让配置生效，也就是配置热更新。

要实现配置热更新，可以使用两种方式：

2.1 方式一

在@Value注入的变量所在类上添加注解@RefreshScope：

2.2 方式二 

使用@ConfigurationPerproties注解代替@Value注解。

在user-service服务中，添加一个类，读取pattern.dateformat属性：

package cn.itcast.user.config;

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Data
@Component
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}

在UserController中使用这个类代替@Value：

2.3 总结

Nacos配置更改后，微服务可以实现热更新，方式：

• 通过@Value注解注入，结合@RefreshScope来刷新
• 通过@ConfigurationProperties注入，自动刷新

注意事项：

• 不是所有的配置都适合放在配置中心，维护起来比较麻烦
• 建议将一些关键参数，需要运行时调整的参数放在nacos配置中心，一般都是自定义配置

3. 配置共享

其实微服务启动时，回去nacos读取多个配置文件，例如： 

• [spring.application.name]-[spring.profiles.active].yaml，例如：userservice-dev.yaml

• [spring.application.name].yaml，例如：userservice.yaml

而 [spring.application.name].yaml不包含环境，因此可以被多个环境共享。

下面我们通过案例配置共享

1. 添加一个环境共享配置

我们在nacos中添加一个userservice.yaml文件：

2. 在user-service中读取共享配置

在user-service服务中，修改PatternProperties类中，读取新添加的属性：

在user-service服务中，修改UserController，添加一个方法：

 

3. 运行两个UserApplication，使用不同的profile

修改UserApplication2这个启动项，改变其profile值：

这样，UserApplication(8081)使用的profile是dev，UserApplication2(8082)使用的profile是test。

启动UserApplication和UserApplication2，访问 http://localhost:8081/user/prop，结果：

访问 http://localhost:8082/user/prop，结果：

可以看出来，不管是dev，还是test环境，都读到了envSharedValue这个属性的值。

 4. 配置共享的优先级

现在我们来思考一个问题，如果之前在nacos添加的两个配置文件和idea的本地配置文件里都有一个相同的属性，那么这个属性值会以谁的为准呢？

我们先在idea的配置文件中新增一个属性：

在PatternProperties类中增加这个属性：

 

重启服务UserApplication(8081)，可以得到如下结果：

 

因为只有本地环境有这个值，远端（Nacos配置文件）是没有的，所以这个结果没问题。接下来，我们修改nacos的userservice.yaml文件：

然后刷新请求，得到结果如下：

这时候，结果变了。也就是说，当我的本地代码中有，nacos的userservice.yaml中也有时，以 userservice.yaml为准。接下来，我们修改nacos的userservice-dev.yaml文件：

结果如下：

 

由此可见， 多种配置的优先级是：

 5. 总结

微服务会从nacos读取的配置文件：

• [服务名]-[spring.profile.active].yaml，环境配置
• [服务名].yaml，默认配置，多环境共享

微服务读取配置的优先级：

• [服务名]-[环境].yaml > [服务名].yaml > 本地配置