(超详细)关于Nacos的共享配置( shared-configs)和拓展配置(extension-config)

前言

用SpringBoot的铁子们,相信大多数人都使用过Nacos作为注册中心和配置文件管理中心,确实很方便。但是很多铁子们依葫芦画瓢,都知道怎么用,但是对于其中的细节可能没有系统地整理过。今天就讲讲关于Nacos的共享配置和扩展配置。

配置Demo

(超详细)关于Nacos的共享配置( shared-configs)和拓展配置(extension-config)_第1张图片

shared-configs(共享配置)和extension-config(扩展配置)

实际工作开发中,对于模块较多的项目,一般都会使用Redis、Mq、公共数据库连接等信息,同时不同模块可能需要连接特定的数据库和配置信息,如果每个模块都使用自己的配置文件本身是没什么问题,只是一旦改动的话,需要每个配置文件都修改,一是麻烦,更主要的是风险大,比如改错或者漏改,损失的都是白花花的银子。

共享配置和扩展配置共同点

两类配置都⽀持三个属性:data-id、group(默认为字符串DEFAULT_GROUP)、refresh(默认为true)

-refresh:是动态刷新,在Nacos修改配置后,服务可以动态感知而无需重启项目。

共享配置

允许我们指定⼀个或多个额外配置

扩展配置

允许我们指定⼀个或多个共享配置

修改配置文件级别

将配置文件改成由application改成bootstrap

application.yml作用域在于当前应用有效,bootstrap.yml系统级别的配置有效(一般采用远程配置的时候才会用到)。

因此,将项目中原来的application.yml、application-dev.yml对应改成bootstrap.yml、bootstrap-dev.yml 。(非强制,根据需求来)

配置Demo

spring:
  application:
    name: nacos-config-test
  main:
    allow-bean-definition-overriding: true
  cloud:
    nacos:
      username: ${nacos.username}
      password: ${nacos.password}
      config:
        server-addr: ${nacos.server-addr}
        namespace: ${nacos.namespace}
        # 用于共享的配置文件
        shared-configs:
          - data-id: common-mysql.yaml
            group: SPRING_CLOUD_EXAMPLE_GROUP
 
          - data-id: common-redis.yaml
            group: SPRING_CLOUD_EXAMPLE_GROUP
 
          - data-id: common-base.yaml
            group: SPRING_CLOUD_EXAMPLE_GROUP
 
        # 常规配置文件
        # 优先级大于 shared-configs,在 shared-configs 之后加载
        extension-configs:
          - data-id: nacos-config-advanced.yaml
            group: SPRING_CLOUD_EXAMPLE_GROUP
            refresh: true
 
          - data-id: nacos-config-base.yaml
            group: SPRING_CLOUD_EXAMPLE_GROUP
            refresh: true

参数解析

  • data-id : Data Id
  • group:自定义 Data Id 所在的组,不明确配置的话,默认是 DEFAULT_GROUP。
  • refresh: 控制该 Data Id 在配置变更时,是否支持应用中可动态刷新, 感知到最新的配置值。默认是不支持的。

注意

Data ID后面是加.yaml后缀的,且不需要指定file-extension。

两者的选择

Nacos中并未对extension-configs和shared-configs的差别进⾏详细阐述。我们从他们的结构,看不出本质差别;除了优先级不同以外,也没有其他差别。那么,Nacos项⽬组为什么要引⼊两个类似的配置呢?我们可以从当初该功能的需求(issue)上找到其原始⽬的。

细节解释

  • namespace

区分环境:开发环境、测试环境、预发布环境、⽣产环境。

  • group

区分不同应⽤:同⼀个环境内,不同应⽤的配置,通过group来区分。

主配置是应⽤专有的配置

主配置应当在dataId上要区分,同时最好还要有group的区分,因为group区分应⽤(虽然dataId上区分了,不⽤设置group也能按应⽤单独加载)。

使用公共配置

如果各应⽤之间共享⼀个配置,请使⽤上⾯的 shared-configs,shared-configs指定的配置,本来应该是不指定group的,也就是应当归⼊DEFAULT_GROUP这个公共分组。

使⽤ extension-config细节

如果要在特定范围内(⽐如某个应⽤上)覆盖某个共享dataId上的特定属性,请使⽤ extension-config。

⽐如,其他应⽤的数据库url,都是⼀个固定的url,使⽤shared-configs.dataId = mysql的共享配置。但其中有⼀个应⽤ddd-demo是特例,需要为该应⽤配置扩展属性来覆盖。示例如下:

spring:
 application:
   name: 你的应用名称
 cloud:
   nacos:
     config:
       server-addr: 你的nacos地址
       namespace: ygjpro-test2
       group: xxx-demo
       ......
       shared-configs[3]:
         data-id: mysql.yaml
         refresh: true
       ......
       extension-configs[3]:
         data-id: mysql.yaml
         group: xxx-demo
         refresh: true

配置文件优先级解释

  • 1、 上述两类配置都是数组,对同种配置,数组元素对应的下标越⼤,优先级越⾼。也就是排在后⾯的相同配置,将覆盖排在前⾯的同名配置。
    同为扩展配置,存在如下优先级关系:extension-configs[3] > extension-configs[2] > extension-configs[1] > extension-configs[0。

同为共享配置,存在如下优先级关系:shared-configs[3] > shared-configs[2] > shared-configs[1] > shared-configs[0]。

  • 2、不同种类配置之间,优先级按顺序如下

主配置 > 扩展配置(extension-configs) > 共享配置(shared-configs)

掌握nacos最好的方法

动手整一个Demo,实际上手配置一下,相信操作一遍之后,你可能就理解了。如果仅仅是看这篇文字的话,实际工作用到的时候还是一脸迷茫。千万别懒,动一次手你离大佬的级别就越近一步。

写在最后

好了,今天的分享就到这里。欢迎持续关注"安前码后",一个致力于分享实用干货的号,后续分享最近两年在整的赚钱的号,可以留意消息。哈哈,太穷了,又是个实在人,觉得有点用处的铁子们,给个三连,请收下我的膝盖。
周末快乐!

你可能感兴趣的:(中间件,&&,分布式应用,Java,后端)