一.nacos配置中心
1.1微服务为什么需要配置中心
在微服务架构中,当系统从一个单体应用,被拆分成分布式系统上一个个服务节点后,配置文件也必须跟着迁移(分割),这样配置就分散了,不仅如此,分散中还包含着冗余。
配置中心就是一种统一管理各种应用配置的基础服务组件。配置中心的出现,可以解决这些问题,使得配置信息集中管理,易于维护,并且可以动态更新配置,使得分布式系统更加稳定可靠。
- 修改/发布配置
- 配置更新通知
- 获取最新配置
1.2 什么是Nacos配置中心
Nacos 提供用于存储配置和其他元数据的 key/value 存储,为分布式系统中的外部化配置提供服务器端和客户端支持。使用 Spring Cloud Alibaba Nacos Config,您可以在 Nacos Server 集中管理你 Spring Cloud 应用的外部属性配置。
配置中心的架构图
二.Nacos配置中心实战
2.1微服务整合nacos配置中心
1)准备nacos server环境
之前nacos已经搭建完毕我这边就不在费话(单节点需要的时候会换成多节点)
2)微服务整合Nacos配置中心
以mall-user-config-demo为例 创建之前springcloud的子工程
注意:nacos版本要对应不然会导致项目启动不了的情况可以参考我的之前发布的
微服务nacos应用实战-优快云博客 这个博客参照一下版本自己直接搭建一个
2.1)引入依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
Spring Cloud2020之后,默认没有使用bootstarp的依赖,重新引入spring-cloud-starter-bootstarp的依赖即可解决。
2.2)创建bootstrap.yml文件,配置nacos配置中心的地址
spring:
application:
name: mall-user-config-demo #微服务名称
cloud:
nacos:
config: #配置nacos配置中心地址
server-addr: 192.168.110.108:1111
username: nacos
password: nacos
3)将application.yml中的配置移到配置中心, 在配置中心中创建微服务的配置
server:
port: 8060
spring:
application:
name: mall-user-config-demo #微服务名称
cloud:
nacos:
discovery: #配置nacos注册中心地址
server-addr: 192.168.110.108:1111
username: nacos
password: nacos
openfeign: #openfeign的配置
client:
config:
#default: # 全局生效
# loggerLevel: BASIC
mall-order: # 对应微服务
loggerLevel: FULL
# 连接超时时间
connectTimeout: 3000
# 请求处理超时时间
readTimeout: 5000
# 配置编解码器
#encoder: feign.jackson.JacksonEncoder
#decoder: feign.jackson.JacksonDecoder
#requestInterceptors: #配置拦截器
# - com.sj.mall.feigndemo.interceptor.FeignAuthRequestInterceptor
# httpclient: #feign client使用 Apache HttpClient5
# hc5:
# enabled: true
# okhttp: #feign client使用 okhttp
# enabled: true
# compression: # 配置 GZIP 来压缩数据
# request:
# enabled: true
# mime-types: text/xml,application/xml,application/json
# min-request-size: 1024 # 最小请求压缩阈值
# response:
# enabled: true
logging:
level:
com.sj.mall.feigndemo.feign: debug #打印openFegin日志
management:
endpoints:
web:
exposure:
include: '*'
DateId
Nacos 中的某个配置集的ID。配置集Id时组织划分配置的维度之一。Data ID通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。
Group
Nacos是一组配置集,是组织配置的维度之一。通过一个有意义的字符串对配置进行分组,从而区分Dara ID相同的配置集。当您在 Nacos 上创建一个配置时,如果未填写配置分组的名称,则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景:不同的应用或组件使用了相同的配置类型,如 database_url 配置和 MQ_topic 配置。
4)注释掉application.yml中的配置,并在bootstrap.yml中指定需要加载的配置文件的路径
在 Nacos Spring Cloud 中,dataId 的完整格式如下:${prefix}-${spring.profiles.active}.${file-extension}
- prefix 默认为 spring.application.name 的值,也可以通过配置项 spring.cloud.nacos.config.prefix来配置。
- spring.profiles.active 即为当前环境对应的 profile,详情可以参考 Spring Boot文档。 注意:当 spring.profiles.active 为空时,对应的连接符 - 也将不存在,dataId 的拼接格式变成 ${prefix}.${file-extension}
- file-exetension 为配置内容的数据格式,可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。
注意:所有的配置能复制到nacos配置尽量复制,不然手敲出错排查问题能有三四天这样的时间奉劝大家别整自己。细心点
5)启动mall-user-config-demo服务,测试http://localhost:8060/user/findOrderByUserId/1
2.2Nacos配置中心常用配置
Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串,公共命名空间(public),分组默认是 DEFAULT_GROUP
支持profile粒度的配置
spring-cloud-starter-alibaba-nacos-config 在加载配置的时候,不仅仅加载了以 dataid 为 ${spring.application.name}.${file-extension:properties} 为前缀的基础配置,还加载了dataid为 ${spring.application.name}-${profile}.${file-extension:properties} 的基础配置。在日常开发中如果遇到多套环境下的不同配置,可以通过Spring 提供的 ${spring.profiles.active} 这个配置项来配置
spring:
profiles:
active: dev
支持自定义group的配置
Group是组织配置的维度之一。通过一个有意义的字符串对配置集进行分组,从而区分Data ID相同的配置集。当您在Nacos上创建一个配置是,如果为天蝎配置分组的名称,则配置分组的名称默认采用DEFAULT_GROUP。配置分组的常见场景:不同的应用或组件使用啦相同的配置类型。如database_url配置等。。。
在没有明确指定 ${spring.cloud.nacos.config.group} 配置的情况下,默认是DEFAULT_GROUP 。如果需要自定义自己的 Group,可以通过以下配置来实现:
spring.cloud.nacos.config.group=sj #自己定义的名字
支持自定义扩展的Data Id配置
Data ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包(如 com.taobao.tc.refund.log.level)的命名规则保证全局唯一性。此命名规则非强制。
在实际的业务场景中应用和共享配置间的关系可能如下:
- 从单个应用的角度来看: 应用可能会有多套(develop/beta/product)发布环境,多套发布环境之间有不同的基础配置,例如数据库。
- 从多个应用的角度来看:多个应用间可能会有一些共享通用的配置,比如多个应用之间共用一套zookeeper集群。
通过自定义扩展的 Data Id 配置,既可以解决多个应用间配置共享的问题,又可以支持一个应用有多个配置文件。
- 通过spring.cloud.nacos.config.shared-configs[n].data-id来支持多个共享Data Id的配置,多个之间用逗号隔开。多个共享配置间的一个优先级的 关系我们约定:按照配置出现的先后顺序,即后面的优先级要高于前面。如果没有明确配置,默认情况下所有共享配置的Data Id 都不支持动态刷新。
- 通过spring.cloud.nacos.config.extension-configs[n].data-id 的配置方式来支持多个 Data Id 的配置。多个 Data Id 同时配置时,他的优先级关系是 n 的值越大,优先级越高。
- 通过spring.cloud.nacos.config.extension-configs[n].group 的配置方式自定义 Data Id 所在的组,不明确配置的话,默认是 DEFAULT_GROUP。
- 通过spring.cloud.nacos.config.extension-configs[n].refresh 的配置方式来控制该 Data Id 在配置变更时,是否支持应用中可动态刷新, 感知到最新的配置值。默认是不支持的。
配置的优先级
spring Cloud Alibaba Nacos Config 目前提供来三种配置从nacos拉取相关配置
- 1通过spring.cloud.nacos.config.shared-configs支持多个共享Data Id的配置
- 2通过spring.cloud.nacos.config.extension-configs[n].data-di的方式支持多个扩展Data id的配置
- 3通过内部相关规则(应用名,应用名+profile)自动生成相关的Data Id配置
当三种方式同时使用时,优先级关是1<2<3
完整的配置优先级从高到低:
- ${spring.application.name}-${profile}.${file-extension}
- ${spring.application.name}.${file-extension}
- ${spring.application.name}
- extensionConfigs
- sharedConfigs
完全关闭配置
通过设置 spring.cloud.nacos.config.enabled = false 来完全关闭 Spring Cloud Nacos Config
通过 Nacos Config 对外暴露的 Endpoint查看相关的配置
Nacos Config 内部提供了一个 Endpoint, 对应的 endpoint id 为 nacosconfig。
Endpoint 暴露的 json 中包含了三种属性:
- Sources: 当前应用配置的数据信息
- RefreshHistory: 配置刷新的历史记录
- NacosConfigProperties: 当前应用 Nacos 的基础配置信息
Endpoint 信息查看
1)引入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
2)暴露监控端点
management:
endpoints:
web:
exposure:
include: '*'
3)查看Endpoint信息,访问:
2.3配置的动态刷新
Spring-cloud-starter-alibaba-nacos-config 也支持配置的动态刷新
测试版、:当前动态配置刷新是,会更新到Enviroment中
1)修改启动,每个5秒从环境里获取一次
public static void main(String[] args) throws InterruptedException{
ConfigurableApplicationContext applicationContext = SpringApplication.run(MallUserConfigDemoApplication.class, args);
while (true) {
//当动态配置刷新时,会更新到 Enviroment中,因此这里每隔3秒中从Enviroment中获取配置
String userName = applicationContext.getEnvironment().getProperty("common.name");
String userAge = applicationContext.getEnvironment().getProperty("common.age");
System.err.println("common name:" + userName + "; age: " + userAge);
TimeUnit.SECONDS.sleep(5);
}
}
2)进入配置中心,修改配置修改common.yml的配置,common.age从10改成“nh”
3)控制台的输入,common.age的值是否发生变化
openfeign开启对feign.request.options属性的属性支持
#启用刷新功能,可以刷新connectTimeout和readTimeout
spring.cloud.openfeign.client.refresh-enabled=true
@RefreshScope实现Bean的动态刷新
如下例子
@RestController
@RefreshScope
public class IndexController {
@Value("${common.age}")
private String age;
@Value("${common.name}")
private String name;
@GetMapping("/index")
public String hello() {
return name+","+age;
}
}
测试结果: 使用@RefreshScope修饰的IndexController,访问/index结果可以获取最新的值
@RefreshScope导致@Scheduled定时任务实效问题
当利用@RefreshScope刷新配置后会导致定时任务实效
@RestController
@RefreshScope //动态感知修改后的值
public class TestController {
@Value("${common.age}")
String age;
@Value("${common.name}")
String name;
@GetMapping("/common")
public String hello() {
return name+","+age;
}
//触发@RefreshScope执行逻辑会导致@Scheduled定时任务失效
@Scheduled(cron = "*/3 * * * * ?") //定时任务每隔3s执行一次
public void execute() {
System.out.println("定时任务正常执行。。。。。。");
}
}
- 当在配置中心变更属性后,定时任务失效(改变配置)
- 当配置改的时候当前这个bean销毁就不会被立刻调用创建属于懒加载类型调用的时候才会被加载,定时任务也会失效
-
原因:@RefreshScope修饰的bean的属性发生变更后,会从缓存中清除。此时没有这个bean,定时任务当然也就不生效了。
详细原因:
- @RefreshScope 注解标注了@Scope 注解,并默认了ScopedProxyMode.TARGET_CLASS属性,此属性的功能就是创建一个代理,在每次调用的时候都用它来调用GenericScope#get 方法来获取bean对象。
- 在GenericScope 里面包装了一个内部类 BeanLifecycleWrapperCache 来对加了 @RefreshScope 的bean进行缓存,使其在不刷新时获取的都是同一个对象。
- 如属性发生变更会调用 ContextRefresher#refresh()——>RefreshScope#refreshAll() 进行缓存清理方法调用,并发送刷新事件通知 ——> 调用GenericScope#destroy() 实现清理缓存
- 当下一次使用此bean对象时,代理对象会调用GenericScope#get(String name, ObjectFactory objectFactory) 方法创建一个新的bean对象,并存入缓存中,此时新对象因为Spring 的装配机制就是新的属性了
解决方案:
实现S pring事件监听器,监听RefreshScopeRefreshScopeRefreshedEvent事件,监听方法中进行一次定时方法的调用
2.4 Nacos插件扩展:配置加密
为保证用户敏感配置数据的安全,Nacos 提供了配置加密的新特性。降低了用户使用的风险,也不需要再对配置进行单独的加密处理。
参考文档:配置加密
Nacos 加解密插件是可插拔的,有没有都不影响 Nacos 的核心功能的运行。如果想要使用 Naocs 的配置加解密功能需要单独引用加密算法的实现。
在 Nacos 服务端启动的时候就会加载所有依赖的加解密算法,然后通过发布配置的 dataId 的前缀(cipher-[加密算法名称])来进行匹配是否需要加解密和使用的加解密算法。
客户端发布的配置会在客户端通过filter完成加解密,也就是配置在传输过程中都是密文的。而控制台发布的配置会在服务端进行处理。
注意:客户端和服务端都通过添加以下依赖来使用 AES 加解密算法,服务端推荐添加到 config 模块下。
<!-- 引入加密插件 -->
<dependency>
<groupId>com.alibaba.nacos</groupId>
<artifactId>nacos-aes-encryption-plugin</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
注意:目前插件需要自行编译,并上传至自己的maven仓库
1) 编译nacos-aes-encryption-plugin插件
通过 SPI 的机制抽象出加密和解密的操作,Nacos 默认提供 AES 的实现。用户也可以自定义加解密的实现方式。具体的实现在 nacos-plugin 仓库。
2)如何编译
编译插件之前需要先编译nacos
并安装至本地仓库.
若出现
revision
变量无法解析,请更新maven
至最新版本
git clone git@github.com:alibaba/nacos.git
cd nacos && mvn -B clean package install -Dmaven.test.skip=true
git clone git@github.com:nacos-group/nacos-plugin.git
mvn install
本地拉取代码然后加入依赖赖
随后将编译的放入nacos的config 引入当前的jar
3)在nacos的config包下引入nacos-aes-encryption-plugin依赖,重新编译nacos服务端源码
建议上传到公司的maven仓库
4)创建加密配置
配置前缀使用cipher-[加密算法名称]-dataId来标识这个配置需要加密,系统会自动识别并加密。例如使用 AES 算法来解密配置:cipher-aes-nacos.yml
查看mysql数据库存储的数据,是否加密: