SpringCloud中把nacos做为配置中心

把配置文件到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端点，要想暴露所有端点只需设置成星号即可