SpringCloud Alibaba实战和源码（6） Nacos Config配置中心

渔阳镇节度使

已于 2024-03-30 00:22:24 修改

阅读量141

点赞数

于 2023-07-27 20:26:03 首次发布

本文链接：https://blog.csdn.net/Forbidden_City/article/details/131968019

版权

微服务专栏收录该内容

16 篇文章 0 订阅

订阅专栏

Nacos之服务配置中心

Nacos不仅仅可以作为注册中心来使用，同时它支持作为配置中心
在这里插入图片描述
pom文件

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

YML配置

bootstrap.yml

# nacos配置
server:
  port: 3377

spring:
  application:
    name: nacos-config-client
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #Nacos服务注册中心地址
      config:
        server-addr: localhost:8848 #Nacos作为配置中心地址
        file-extension: yaml #指定yaml格式的配置
        ----------------------
        shared-configs[0]:  #shared-configs是一个列表，可以添加多项
          data_id: redis.yml #具体配置
          group: DEFAULT_GROUP #默认可以不写
          refresh: true #是否开启自动刷新，默认为false，必须搭配@RefreshScope注解

application.yml

spring:
  profiles:
    active: dev # 表示开发环境

主启动类

@EnableDiscoveryClient

在这里插入图片描述

业务类

@RefreshScope   //动态刷新注解

在这里插入图片描述

Nacos配置规则
在 Nacos Spring Cloud 中，dataId 的完整格式如下（详情可以参考官网 https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html）：

${prefix}-${spring.profiles.active}.${file-extension}

1. `prefix` 默认为 `spring.application.name` 的值，也可以通过配置项 `spring.cloud.nacos.config.prefix`来配置。
2. `spring.profiles.active` 即为当前环境对应的 profile，注意：**当 `spring.profiles.active` 为空时，对应的连接符 `-` 也将不存在，dataId 的拼接格式变成 `${prefix}.${file-extension}`**（不能删除）
3. `file-exetension` 为配置内容的数据格式，可以通过配置项 `spring.cloud.nacos.config.file-extension` 来配置。目前只支持 `properties` 和 `yaml` 类型。
4. 通过 Spring Cloud 原生注解 `@RefreshScope` 实现配置自动更新：
5. 所以根据官方给出的规则我们最终需要在Nacos配置中心添加的配置文件的名字规则和名字为：

# ${spring.application.name}-${spring.profiles.active}.${file-extension}
# nacos-config-client-dev.yaml
# 微服务名称-当前环境-文件格式

在这里插入图片描述

Nacos Config进阶

解决不同环境相同配置问题-自定义Data ID配置
在这里插入图片描述

不同微服务之间如何共享配置

配置文件名字没有固定要求
在这里插入图片描述
方式1： 通过shard-configs方式

spring:
  application:
    name: nacos-config-client
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #Nacos服务注册中心地址
      config:
        server-addr: localhost:8848 #Nacos作为配置中心地址
        file-extension: yaml #指定yaml格式的配置
        shared-configs[0]:  #shared-configs是一个列表，可以添加多项
          data_id: redis.yml #具体配置
          group: DEFAULT_GROUP #默认可以不写
          refresh: true #是否开启自动刷新，默认为false，必须搭配@RefreshScope注解

当然也支持多个配置，只需要在shared-configs[n]，增加n的数值即可

cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #Nacos服务注册中心地址
      config:
        server-addr: localhost:8848 #Nacos作为配置中心地址
        file-extension: yaml #指定yaml格式的配置
        shared-configs[0]:  #shared-configs是一个列表，可以添加多项
          data_id: redis.yml #具体配置
          group: DEFAULT_GROUP #默认可以不写
          refresh: true #是否开启自动刷新，默认为false，必须搭配@RefreshScope注解
        shared-configs[1]: #shared-configs是一个列表，可以添加多项
          data_id: common.yml #具体配置
          group: DEFAULT_GROUP #默认可以不写
          refresh: true #是否开启自动刷新，默认为false，必须搭配@RefreshScope注解

多个 Data Id 同时配置时，他的优先级关系是 spring.cloud.nacos.config.extension-configs[n].data-id 其中 n 的值越大，优先级越高。

方式2： 通过extension-configs方式
（区别：shard-configs注重于共享，共享同一个配置；extension-configs则是扩展，一个微服有多个配置文件）

其实以上的实现还可以通过extension-configs方式来完成，其实作用基本一致，只不过语义上可以更好的区分，如果我们需要在一个微服务上配置多个配置文件，可以使用extension-configs，如果需要多个配置文件共享，可以使用shard-configs配置方式，当然其实两种方式所实现的效果和配置方法基本一致。

所以通过自定义扩展的 Data Id 配置，既可以解决多个应用间配置共享的问题，又可以支持一个应用有多个配置文件。

具体实现

更改yml，只需要将shared-configs改为extension-configs即可

spring:
  application:
    name: nacos-config-client
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #Nacos服务注册中心地址
      config:
        server-addr: localhost:8848 #Nacos作为配置中心地址
        file-extension: yaml #指定yaml格式的配置
        extension-configs[0]:  #shared-configs是一个列表，可以添加多项
          data_id: redis.yml #具体配置
          group: DEFAULT_GROUP #默认可以不写
          refresh: true #是否开启自动刷新，默认为false，必须搭配@RefreshScope注解
        extension-configs[1]: #shared-configs是一个列表，可以添加多项
          data_id: common.yml #具体配置
          group: DEFAULT_GROUP #默认可以不写
          refresh: true #是否开启自动刷新，默认为false，必须搭配@RefreshScope注解

整体配置优先级

Spring Cloud Alibaba Nacos Config 目前提供了三种配置能力从 Nacos 拉取相关的配置。

A: 通过 spring.cloud.nacos.config.shared-configs[n].data-id 支持多个共享 Data Id 的配置
B: 通过 spring.cloud.nacos.config.extension-configs[n].data-id 的方式支持多个扩展 Data Id 的配置
C: 通过内部相关规则(应用名、应用名+ Profile )自动生成相关的 Data Id 配置

当三种方式共同使用时，他们的一个优先级关系是:A < B < C

Nacos Config动态刷新原理

动态监听
（客户端通过长轮询的方式来获取配置数据）

所谓动态监听，简单理解就是指Nacos会自动找到那些服务已经注册，而对比来说静态监听，就是指需要有指定配置指定的服务。

其实在这里我们就要说一下客户端和服务端的交互方式，无非就是推和拉

Push：表示服务端主动将数据变更信息推送给客户端
- 服务需要维持客户端的长连接，因为需要知道具体推送的客户端
- 客户端耗费内存高，因为需要保存所有客户端的连接，并且需要检测连接有效性（心跳机制）
Pull：表示客户端主动去服务端拉取数据
- 需要定时拉取数据
- 缺点：时效性，数据实时性，无效请求
  
  核心：Nacos动态刷新机制，采用推和拉的优点，避免缺点。

Nacos做配置中心的时候，配置数据的交互模式是有服务端push推送的，还是客户端pull拉取的？

Nacos客户端发送一个请求连接到服务端，然后服务端中会有一个29.5+0.5s的一个hold期，然后服务端会将此次请求放入到allSubs队列中等待，触发服务端返回结果的情况只有两种，第一种是时间等待了29.5秒，配置未发生改变，则返回未发生改变的配置；第二种是操作Nacos Dashboard或者API对配置文件发生一次变更，此时会触发配置变更的事件，发送一条LocalDataEvent消息，此时服务端监听到消息，然后遍历allSubs队列，根据对应的groupId找到配置变更的这条ClientLongPolling任务，并且通过连接返回给客户端

Nacos动态刷新避免了服务端对客户端进行push操作时需要保持双方的心跳连接，同样也避免了客户端对服务端进行pull操作时数据的时效性问题，不必频繁去拉去服务端的数据

通过上面原理的初步了解，显而易见，答案是：客户端主动拉取的，通长轮询的方式（Long Polling）的方式来获取配置数据。

短轮询

不管服务端的配置是否发生变化，不停发起请求去获取配置，比如支付订单场景中前端不断轮询订单支付的状态，这样的坏处显而易见，由于配置并不会频繁发生变更，如果是一直发请求，一定会对服务端造成很大的压力。还会造成数据推送的延迟，比如每10秒请求一次配置，如果在第11秒的时候配置更新，那么推送将会延迟9秒，等待下一次请求这就是短轮询，为了解决短轮询的问题，有了长轮询的方案

长轮询

长轮询不是什么新技术，它其实就是由服务端控制响应客户端请求结果的返回时间，来减少客户端无效请求的一种优化手段，其实对于客户端来说，长轮询的使用并没有本质上的区别，客户端发起请求后，服务端不会立即返回请求结果，而是将请求hold挂起一段时间，如果此时间段内配置数据发生变更，则立即响应客户端，若一直无变更则等到指定超时时间后响应给客户端结果，客户端重新发起长链接
在这里插入图片描述