首页  思维导图  详情

Nacos配置中心实战

2025-02-26 14:45:54   0  举报





仅支持查看

AI智能生成

Nacos配置中心实战，分享给大家学习。更多干货内容，欢迎关注我的公众号：Fox爱分享

Nacos

微服务

配置中心

springcloud

SpringCloudAlibaba

作者其他创作

大纲/内容

课程目标

掌握nacos配置中心的常用配置的使用

怎么学

没接触过微服务的同学一定要先把《轻松玩转微服务：新手入门Spring Cloud Alibaba》这节课跟一遍

课上代码

项目地址

git切换到nacos-teach分支，选择 tag v2.3.0，v2.3.1

基础回顾

微服务为什么需要配置中心

一个微服务一个application.yml，100个微服务100个application.yml，如果注册中心地址变了，想象一下怎么改配置

配置中心使得配置信息集中管理，易于维护，并且可以动态更新配置

怎么用

Nacos配置中心配置方式的变化

在SpringBoot2.4这个大版本中有一项非常重要的改动：出于对云原生多配置文件的支持，默认关闭了对bootstrap.yml的使用。

解决方案

方案1：重新启用bootstrap.yml（不推荐）

方案2：使用spring.config.import（官方推荐）

订单服务整合Nacos配置中心

目标：把微服务中公共的配置配置统一管理，比如订单服务的注册中心配置和数据库公共配置可以抽取出来

演示环境，以订单服务tlmall-order-config-demo为例

代码地址

1) 在Nacos控制台创建dataId（对应spring.config.import指定的配置文件名）

抽取application.yml中配置信息配置到Nacos指定的dataId文件中

公共配置

nacos-discovery.yml

db-common.yml

订单服务自己的配置

tlmall-order-config-demo.yml

同时注释掉application.yml对应的配置

2）引入依赖

订单服务的pom.xml中引入nacos-config依赖

3) 在订单服务的application.yml 配置文件中配置 Nacos Config 地址并引入服务配置

使用spring.config.import（官方推荐）

注意事项

指定的配置文件对应Nacos配置中心配置的dataId

重启订单服务测试

可以先在application.yml中增加nacos日志打印配置，便于查看从配置中心拉取配置的情况

查看订单服务是否启动成功，并成功注册到Nacos注册中心

如果没有拉取到数据库配置是会报错的

课后作业

tlmall-user-config-demo整合nacos配置中心

Nacos 配置中心常用配置详解

profile 粒度的配置

在日常开发中如果遇到多套环境下的不同配置，可以通过Spring 提供的 ${spring.profiles.active} 这个配置项来配置。

以订单服务为例，配置开发环境和生产环境

1）演示环境准备

1.1) 准备测试代码

1.2) 配置中心增加开发环境和生产环境的配置文件

tlmall-order-config-demo-dev.yml

tlmall-order-config-demo-prod.yml

2）修改application.yml配置

2.1) 配置spring.profiles.active为开发环境

2.2) import中引入${spring.application.name}-${spring.profiles.active}.yml配置

3）测试

3.1）重启订单服务，调用localhost:8060/order/post1，查看测试结果

3.2) 配置jvm参数-Dspring.profiles.active=prod,重启服务，调用localhost:8060/order/post1，查看测试结果

自定义 Namespace 的配置

用于进行租户粒度的配置隔离。

不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。

在没有明确指定 ${spring.cloud.nacos.config.namespace} 配置的情况下，默认使用的是 Nacos 上 Public 这个namespace。

测试

1）Nacos配置克隆

将public命名空间下的配置克隆到fox命名空间

2）application.yml中增加spring.cloud.nacos.config.namespace配置

启动订单服务，查看控制台是否拉取了配置

自定义 Group 的配置

主要用于区分不同的微服务或应用组件

一个应用可能使用了database_url配置和MQ_topic配置，我们可以将这些配置分别划分到不同的Group中，以便更好地管理和维护。

在没有明确指定 ${spring.cloud.nacos.config.group} 配置的情况下，默认使用的是组 DEFAULT_GROUP 。

配置的优先级

按import的配置顺序加载，重复的配置会被覆盖

配置的动态刷新

spring-cloud-starter-alibaba-nacos-config 支持配置的动态更新。

测试：当动态配置刷新时，会更新到 Enviroment中

1）修改启动类，每隔3s从Enviroment中获取order.count的值，并启动订单服务

2）进入配置中心，修改tlmall-order-config-demo-prod.yml的配置，order.count从100改成300

查看控制台输出，count是否从100改为300

调用localhost:8060/order/post1，查看count是否从100改为300

结论：可以从Environment获取到配置中心更改的值，但是OrderController（Bean对象）中@Value修饰的值没有变化

思考：如何实现Spring管理的Bean对象中@Value修饰的属性的动态更新

解决方案

使用@RefreshScope注解实现Bean的动态刷新

使用@RefreshScope修饰的OrderController，访问/order/post1接口可以获取最新的值

测试

调用localhost:8060/order/post1，查看count是否从100改为300

注意：@RefreshScope 使用不当会导致@Scheduled定时任务失效

场景重现

当利用@RefreshScope刷新配置后会导致定时任务失效

测试

当在配置中心变更属性后，定时任务失效

当再次访问/count接口时，定时任务生效

原因分析

@RefreshScope修饰的bean的属性发生变更后，会从缓存中清除。此时没有这个bean，定时任务当然也就不生效了。

解决方案

实现Spring事件监听器，监听 RefreshScopeRefreshedEvent事件，监听方法中进行一次定时方法的调用

OpenFeign开启对feign.Request.Options属性的刷新支持

拓展：Nacos插件

配置加密

需求

为了保证用户敏感配置数据的安全，对配置中心的配置数据加密

解决方案

使用Nacos 加解密插件

在 Nacos 服务端启动的时候就会加载所有依赖的加解密算法，然后通过发布配置的 dataId 的前缀(cipher-[加密算法名称])来进行匹配是否需要加解密和使用的加解密算法。
客户端发布的配置会在客户端通过filter完成加解密，也就是配置在传输过程中都是密文的。而控制台发布的配置会在服务端进行处理。

注意：目前插件需要自己编译,并未上传至maven中央仓库

怎么用

1）环境准备

1.1）编译插件之前需要先编译nacos并安装至本地仓库.

注意：拉取的是最新版的nacos,可以切换到2.3.2的分支后编译

nacos2.3.2源码编译填坑

官方编译命令mvn -Prelease-nacos -Dmaven.test.skip=true clean install -U执行后各种报错

编译环境：jdk8, maven3.5.4

最终编译命令

1.2）编译nacos-aes-encryption-plugin插件

注意：切换到2.2.x的分支编译不会报错

编译环境：jdk8, maven3.5.4