Nacos Config 配置中心支持配置共享

---

一、什么是配置中心

微服务架构下关于配置文件的存在以下问题：

1. 配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统⼀配置和管理。
2. 配置文件无法区分环境。微服务项目可能会有多个环境，例如：测试环境、预发布环境、⽣产环境。每⼀个环境所使用的配置理论上都是不同的，⼀旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。
3. 配置文件⽆法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置⽣效，这对一个正在运行的项目来说是非常不友好的。

配置中心的思路是：
首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。
当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。
当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来，同步最新的信息，动态更新。
当加入了服务配置中心之后，我们的系统架构图会变成下面这样：

---

二、Nacos Config

Nacos 作为 SpingCloud Alibaba 技术栈中的一个组件，除了可以作为服务中心以外，也可直接服务的配置中心。

2.1 Nacos Config 工作原理 （★）

  使用 nacos 作为配置中心，就是将 nacos 当做一个服务端，将各个微服务看成是客户端，我们将各个微服务的配置文件统一存放在 nacos 上，然后各个微服务从 nacos 上拉取配置即可。具体的工作详情如下图所示：

  bootstrap 配置和 application 都是 SpringBoot 的配置文件，bootstrap 一般存储系统级别的参数，application 一般用于定义应用级别的参数，并且 bootstrap 加载的时间相比于application更早。

优先级：
在同一级目录下，会先比较前缀 bootstrap、application，其中 bootstrap 比 application 的优先级高，其次再去比较后缀.properties .yml，其中.properties 比 .yml 优先级高。

所以它们的执行顺序如下：bootstrap.properties > bootstrap.yml > application.properties > application.yml

配置覆盖：

1. 当同一个配置属性在 bootstrap.properties 和 bootstrap.yml 文件中都存在时，那么 properties 中的配置会被加载，而忽略 yml 文件中的配置，即优先级高的配置覆盖优先级低的配置，不同配置相互互补。此处application(.properties/yml) 同理。
2. 当同一配置在 bootstrap 和 application 中都存在时，那么虽然优先加载 bootstrap 但是会被 applicatioin 中的配置 覆盖，此时则变成了低优先级覆盖高优先的配置。
3. 当同一个配置属性在四种配置（bootstrap.properties、bootstrap.yml、application.properties、application.yml ）都存在，application.properties 里的配置一定是会覆盖其他配置文件。首先遵循第二点：虽然优先加载bootstrap但是会被 applicatioin 中的配置覆盖，这时候就只剩 application.yml、application.properties了，此时遵循第一点：即优先级高的配置覆盖优先级低的配置，所以 application.properties 的配置文件会覆盖其他配置文件。

参考：https://blog.csdn.net/qq_60264381/article/details/130248941

---

2.2 Nacos Config 的使用

1、搭建 nacos 注册中心环境
2、在商品微服务中引入nacos Config的依赖

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

3、在微服务中添加 bootstrap.yml 配置文件，不用原来的 application.yml

spring:application:name: product-servicecloud:nacos:config:server-addr: 127.0.0.1:8848 # nacos中⼼地址file-extension: yaml # 配置⽂件格式profiles:active: dev # 环境标识

4、在 nacos 中添加配置，然后把商品微服务原 application.yml 配置复制到配置内容中。


6、如果依旧可以成功访问程序，说明我们 nacos 的配置中心功能已经实现

---

2.3 动态刷新

需要在需要刷新的类上加 @RefreshScope 注解，以支持当前类动态刷新。具体案例如下：

@RestController
@RefreshScope
public class NacosConfigController {@Value("${appConfig.name}")private String appConfigName;@RequestMapping("/nacosConfig1")public String nacosConfig(){return "远程信息:"+appConfigName;}
}

此时当在配置中心修改 ${appConfig.name}，再次访问接口即可发生变化。

注：动态刷新只支持部分属性，有些属性不可动态刷新如端口号等。

---

2.4 配置共享

当配置越来越多的时候，我们就发现有很多配置是重复的，这时候就考虑将公共配置⽂件提取出来，然后实现共享。

2.4.1 同一个微服务的不同环境之间共享配置

如果想在同一个微服务的不同环境之间实现配置共享（如：product-service-dev.yaml、product-service-test.yaml）。只需要提取一个以 spring.application.name 命名的配置文件，然后将其所有环境的公共配置放在里面即可。

1、新建一个名为 product-service.yaml 配置存放商品微服务的公共配置，把之前的公共配置都存放进去。

2、新建⼀个名为 product-service-test.yaml 配置存放测试环境的配置。

3、新建⼀个名为 product-service-dev.yaml 配置存放测试环境的配置。

4、需要的配置信息具体如下:

5、通过修改环境，参看是否可以读取公共配置和环境独有配置

---

2.4.2 不同微服务中间共享配置

不同微服务之间实现配置共享的原理类似于文件引入，就是定义⼀个公共配置（如：redis-config.yaml），然后在当前配置中引入。

1、在 nacos 中定义一个 DataID 为 global-config.yaml 的配置，用于所有微服务共享。

2、修改bootstrap.yaml

spring:application:name: product-servicecloud:nacos:config:server-addr: 127.0.0.1:8848 # nacos中⼼地址file-extension: yml # 配置⽂件格式shared-configs:- data-id: global-config.yaml # 配置要引⼊的配置refresh: true # 是否支持该文件的动态刷新，默认不支持falseprofiles:active: dev # 环境标识

3、重启测试即可

---

文章参考：Java微服务商城高并发秒杀项目实战|Spring Cloud Alibaba真实项目实战+商城双11秒杀+高并发+消息+支付+分布式事物Seata