标签：

把配置文件到nacos里面写

1. Nacos简介

Nacos除了实现了服务的注册发现之外，还将配置中心功能整合在了一起，

通过Nacos的配置管理功能，我们可以将整个架构体系内的所有配置都集中在Nacos中存储。

另外，在分布式系统中，由于服务数量巨多，为了实现更灵活的管理权限、安全性，

实时更新以及一次打包，多处运行，所以需要分布式配置中心组件

Spring Cloud Alibaba Nacos Config

2. 快速实现Nacos作为配置中心(私有配置)

1.进入Nacos的控制页面，在配置列表功能页面中，点击右上角的“+”按钮，进入“新建配置”页面

Data ID：填入nacos-config-client.yml，注意：Data ID 的默认扩展名为 .properties ，希望使用yml配置，此处必须指明是*.yml

Group： 不修改，使用默认值DEFAULT_GROUP

配置格式：选择yaml

配置内容：应用要加载的配置内容，这里仅作为示例(注：请将下面内容改成yml格式填入，这里是为了书写方便)

cnf.message=hello nacos config clent

注1：当新建配置的DataID的值与模块名相同时，表示此配置是此模块的私有配置

2.导入nacos配置中心客户端依赖

<!--Nacos配置中心客户端依赖(与Eureka不同没有服务端)，在需要使用配置中心的模块才导入此依赖-->

<dependency>

<groupId>com.alibaba.cloud</groupId>

<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>

</dependency>

3.创建配置文件bootstrap.yml，并配置服务名称和Nacos地址(注：请将下面内容改成yml格式填入，这里是为了书写方便)

server.port=7301 #项目端口号(boostrap.yml中配置后，可在application.yml中不配置)

spring.application.name=nacos-config-client #应用名对应nacos配置中心的Data Id

spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848 #指定nacos注册中心地址(boostrap.yml中配置后，可在application.yml中不配置)

spring.cloud.nacos.config.prefix=${spring.application.name} #不填写默认就是项目的应用名

spring.cloud.nacos.config.server-addr=127.0.0.1:8848 #指定nacos配置中心地址

spring.cloud.nacos.config.file-extension=yml #指定配置文件后缀名

这里有两个坑：1. 配置文件必须是bootstrap.properties或者bootstrap.yml，如果配置application.properties或者application.yml会导致加载不到配置；

2. spring.cloud.nacos.config.namespace如果是默认的public，则不需填写，否则获取不到配置信息

详情见：资料/nacos-config-client-bootstrap.yml

4. 创建NacosConfigController进行配置信息的读取

@Value("${cnf.message}")

5. @RefreshScope实现自动刷新

此注解主要用来让这个类下的配置内容支持动态刷新，也就是当我们的应用启动之后，修改了Nacos中的配置内容之后，这里也会马上生效

2. Nacos实现共享配置

之前讲的都当前项目的私有配置，但一个真实项目中还会有许多的共享配置，比方说数据库、redis、log4j日志配置等，这些都可以放到nacos中，做到配置的共享加载与统一管理

1.进入Nacos的控制页面，创建新的配置文件db.yml,hello.yml

username=zs

password=123

hello=hello nacos

2.修改bootstrap.yml添加如下配置

spring.cloud.nacos.config.shared-dataids=db.yml,hello.yml

spring.cloud.nacos.config.refreshable-dataids=db.yml,hello.yml

注1：spring.cloud.nacos.config.shared-dataids参数用来配置多个共享配置的Data Id，多个的时候用用逗号分隔

注2：spring.cloud.nacos.config.refreshable-dataids参数用来定义哪些共享配置的Data Id在配置变化时，应用中可以动态刷新，多个Data Id之间用逗号隔开。如果没有明确配置，默认情况下所有共享配置都不支持动态刷新

注3：不能省略后缀名yml或properties

3. 多环境的配置管理

本例使用了nacos的命名空间，来实现不同环境的切换，这也是nacos官方推荐的方式。还有其它两种方式，了解可参考附录四，详情请参考：资料/04,05,06

1.进入Nacos的控制页面，创建新的命名空间dev/test/prd

2.在配置列表的最上方，可以看到除了public之外，多了几个刚才创建的namepsace。分别在dev/test/prd空间下为nacos-config-client应用创建配置内容

nacos-config-client.yml

db.yml

hello.yml

3.修改bootstrap.yml添加如下配置

spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a #这里需要注意namespace的配置不是使用名称，而是使用Namespace的ID。

注意事项：对于指定环境的配置

（spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），

都不要配置在应用的bootstrap.yml中。而是在发布脚本的启动命令中，

用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活

语法格式：java -jar xxx.jar --a1=aaa --b1=bbb

java -jar nacos-config-client.jar --spring.cloud.nacos.config.namespace=d43d645d-0567-40f7-97d0-a39e2f0216b1

附录一：yml和properties文件区别

1.首先yml和properties文件都是属于配置文件，功能一样，使用哪种方式自己开心就好，建议使用yml，因为树状结构更加清晰，代码更少

附录二：application.yml和 bootstrap.yml区别

1.主要是application和bootstrap的加载顺序

bootstrap.yml在application.yml之前加载，用于应用程序上下文的引导阶段

注意：Spring Boot 配置文件的加载顺序，依次为 bootstrap.properties -> bootstrap.yml -> application.properties -> application.yml ，其中 bootstrap.properties 配置为最高优先级

2.典型场景

1.当使用 Spring Cloud Config Server的时候，你应该在 bootstrap.yml里面指定spring.application.name和spring.cloud.nacos.config.server-addr

2.一些加密/解密的信息

3.属性覆盖问题

1.启动上下文时，Spring Cloud会创建一个Bootstrap Context，作为Spring应用的Application Context的父上下文。Bootstrap Context属性有高优先级，默认情况下，它们不会被本地配置覆盖。

2.初始化的时候，Bootstrap Context负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment。

3.Bootstrap context和Application Context有着不同的约定，所以新增了一个bootstrap.yml文件，而不是使用application.yml (或者application.properties)。保证Bootstrap Context和Application Context配置的分离

附录三：Nacos共享配置的两种实现方式

shared-dataids方式：

适合于共享配置文件与项目默认配置文件处于相同Group时，直接两条命令就可以搞定

优点：配置方便

缺点：只能在同一Group中

ext-config方式：

它可以由开发者自定义要读取的共享配置文件的DataId、Group、refresh属性，这样刚好解决了shared-dataids存在的局限性。

优点：可以与shared-dataids方案结合使用，用户自定义配置。灵活性强

缺点：配置容易出错，要熟悉YAML语法

附录四：利用Nacos配置管理功能中的几个不同纬度来实现多环境的配置管理

第一种：通过Data ID与profile实现。

优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。

缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。

建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划。

第二种：通过Group实现。

优点：通过Group按环境讲各个应用的配置隔离开。可以非常方便的利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。

缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。

建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。

第三种：通过Namespace实现。

优点：官方建议的方式，通过Namespace来区分不同的环境，释放了Group的自由度，这样可以让Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。

缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。

建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？

注意：不论用哪一种方式实现。对于指定环境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），都不要配置在应用的bootstrap.properties中。而是在发布脚本的启动命令中，用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活

附录四：

management.endpoints.web.exposure.include=*，默认只公开了/health和/info端点，要想暴露所有端点只需设置成星号即可

 

标签：
来源：

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。