Alibaba微服务组件——Naocs配置中心，从0到0.8

最新推荐文章于 2024-07-19 16:45:52 发布

第1缕阳光

最新推荐文章于 2024-07-19 16:45:52 发布

阅读量851

点赞数

分类专栏： Java技术栈文章标签：微服务 microservices spring cloud spring cloud alibaba nacos

本文链接：https://blog.csdn.net/qq_45043381/article/details/122338145

版权

Java技术栈专栏收录该内容

10 篇文章 0 订阅

订阅专栏

1，基于datid为yaml的文件扩展名配置方式

一，简介

Nacos 提供用于存储配置和其他元数据的 key/value 存储，为分布式系统中的外部化配置提供服务器端和客户端支持。使用 Spring Cloud Alibaba Nacos Config，您可以在 Nacos Server 集中管理你 Spring Cloud 应用的外部属性配置。——来自springcloud alibaba官网文档

也就是说：

有一个统一的配置中心，整个spring cloud应用的所有的微服务的任何配置都可以在这个可视化配置中心中编辑、存储、分发、变更；
在nacos可视化界面中增删改查这些配置；
当系统运行时，在nacos可视化界面中修改配置之后不需要重启项目，nacos会将修改后的配置自动分发到代码引用的地方；
提高系统的可维护性；（不用重启项目）
提高修改配置的时效性；（不用在代码中修改配置）

二，主流配置中心比较

与 springcloud config 对比

springcloud config部分场景需要结合git 使用；
动态变更还需要依赖Spring Cloud Bus 消息总线来通过所有的客户端变化；
springcloud config不提供可视化界面；
nacos config使用HTTP长轮询实时推送配置, 一旦配置有变动后，通知Provider的过程非常的迅速；

三，快速开始

1，Nacos服务端配置

①在配置管理-服务列表中新增配置

②添加配置

Data ID（配置集 ID）：配置集ID是组织划分配置的维度之一。Data ID通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID通常采用类java包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。

Group：Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

配置格式：不同类型的文件，不同类型的扩展名，不同类型的格式， properties是默认的文件扩展名方式。

配置内容：根据指定的配置格式，设置配置信息；就是将系统中application.yml的配置信息放置到这个地方进行管理。

Namespace：代表不同环境，如开发、测试、生产环境。
Group：代表某项目，如XX医疗项目、XX电商项目
DataId：每个项目下往往有若干个工程（微服务），每个配置集(DataId)是一个工程（微服务）的主配置文件

③发布

2，客户端使用方式

①在要被管理配置的服务中pom.xml中添加依赖

② 在添加bootstrap.properties(或bootstrap.yml)配置文件并配置Nacos Config配置

bootstrap.yml文件：是sping cloud扩展出来的文件，一般放在src/main/resources路径下。 必须使用 bootstrap.properties 配置文件来配置Nacos Server 地址（配置中心的配置）。

③代码中引用配置

@RefreshScope：动态刷新，Nacos Config Starter 默认为所有获取数据成功的 Nacos 的配置项添加了监听功能，在监听到服务端配置发生变化时会实时触发 org.springframework.cloud.context.refresh.ContextRefresher 的 refresh 方法。如果需要对 Bean 进行动态刷新，推荐给类添加 @RefreshScope 或 @ConfigurationProperties 注解。

@Value注解可以获取到配置中心的值，但是无法动态感知修改后的值，需要利用@RefreshScope注解。

④调用接口验证配置生效

⑤直接修改配置的user.name的值

刷新页面，可以看到name的值直接刷新，此时我们并没有重启系统。

四，其他扩展配置

1，基于datid为yaml的文件扩展名配置方式

①客户端bootstrap.properties配置及其中显示声明dataid文件扩展名

②在Nacos服务端可视化界面新增一个dataid为yaml为扩展名的配置

除了默认的配置文件，其他配置文件的dataid名必须写上后缀名；

默认的配置文件：跟服务名相同的dataid的配置文件
spring.cloud.nacos.config.file-extension只针对默认的配置文件的后缀名。

2，支持配置的动态更新

nacos默认开启配置的动态更新，可以通过配置 spring.cloud.nacos.config.refresh.enabled=false 来关闭动态刷新。

nacos的优点，为什么要关闭呢？

3，支持profile粒度的配置

spring-cloud-starter-alibaba-nacos-config 在加载配置的时候，不仅仅加载以 dataid 为 ${spring.application.name}.${file-extension:properties} 为前缀的基础配置，还加载dataid为 ${spring.application.name}-${profile}.${file-extension:properties} 的基础配置。

通过${spring.application.name}可以看出只能通过默认的配置文件进行配置，其他的名字的配置文件是不能通过profile的方式配置的；
默认的配置文件：跟服务名相同的dataid的配置文件
除了默认的配置文件，其他配置文件的dataid名必须写上后缀名
profile文件的后缀必须跟随默认配置文件的格式，即跟随
spring.cloud.nacos.config.file-extension的配置
在日常开发中如果遇到多套环境下的不同配置，可以通过Spring 提供的 ${spring.profiles.active} 这个配置项来配置。

类似于springboot的配置文件，application.yml、application-dev.yml、application-prod.yml的意思。

①客户端：在配置文件application.properties配置

spring.profiles.active是springboot的配置，一般放在application.yml中，一般只把spring cloud alibaba nacos config的配置放在bootstarp.yml中。

②服务端：可视化界面新增一个dataid为xxx-dev.yaml的基础配置

配置文件优先级：

profile > 默认配置文件
优先级大的会覆盖优先级小的，并形成互补

③验证

更推荐使用命名空间的方式激活不同环境的配置文件，因为根据后缀区分不同的配置文件不能进行权限控制。

这里通过 spring.profiles.active=<profilename> 的方式写死在配置文件中，而在真正的项目实施过程中这个变量的值是需要不同环境而有不同的值。

这个时候通常的做法是通过 -Dspring.profiles.active=<profile> 参数指定其配置来达到环境间灵活的切换。

4，支持自定义namespace的配置

用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

①服务端：在可视化界面新增一个命名空间

②服务端：在dev命名空间中新建配置文件

③客户端：在bootstrap.yml配置文件中配置

在没有明确指定 ${spring.cloud.nacos.config.namespace} 配置的情况下，默认使用的是 Nacos 上 Public 这个namespae。
该配置必须放在 bootstrap.properties 文件中。
spring.cloud.nacos.config.namespace 的值是 namespace 对应的 id，id 值可以在 Nacos 的控制台获取。
在添加配置时注意不要选择其他的 namespae，否则将会导致读取不到正确的配置。

④验证

5，支持自定义Group的配置

Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用DEFAULT_GROUP。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

①服务端：在可视化界面中新增配置文件并指定Group

②客户端：配置文件boostrap.yml中配置分组

该配置必须放在 bootstrap.properties 文件中。

并且在添加配置时 Group 的值一定要和 spring.cloud.nacos.config.group 的配置值一致。

不同的Group可以存在相同的DataId。

③验证

6，支持自定义Data ID

Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。

服务名和Data ID名不一样的话读取不到这个Data ID的配置文件（非默认配置文件）。

使用场景：

多个配置文件的公共配置信息；

①服务端：创建一个配置文件并自定义和服务名不同的DataID

②客户端：代码引用配置字段

③客户端：配置文件bootstrap.yml中配置读取这个自定义DataID名的配置文件

方式一：

字段解释：

通过 spring.cloud.nacos.config.extension-configs[n].data-id 的配置方式来支持多个 Data Id 的配置。

通过 spring.cloud.nacos.config.extension-configs[n].group 的配置方式自定义 Data Id 所在的组，不明确配置的话，默认是 DEFAULT_GROUP。

通过 spring.cloud.nacos.config.extension-configs[n].refresh 的配置方式来控制该 Data Id 在配置变更时，是否支持应用中可动态刷新，感知到最新的配置值。默认是不支持的。

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

文件扩展名：

spring.cloud.nacos.config.extension-configs[n].data-id 的值必须带文件扩展名，文件扩展名既可支持 properties，又可以支持 yaml/yml。

此时 spring.cloud.nacos.config.file-extension 的配置对自定义扩展配置的 Data Id 文件扩展名没有影响。