做婚恋网站代理商挣钱吗,怎么查询网站的空间商,wordpress设置用户访问个数据库,wordpress网站更换空间1. Nacos配置中心
1.1 微服务为什么需要配置中心
在微服务架构中#xff0c;当系统从一个单体应用#xff0c;被拆分成分布式系统上一个个服务节点后#xff0c;配置文件也必须跟着迁移#xff08;分割#xff09;#xff0c;这样配置就分散了#xff0c;不仅如此当系统从一个单体应用被拆分成分布式系统上一个个服务节点后配置文件也必须跟着迁移分割这样配置就分散了不仅如此分散中还包含着冗余。
配置中心就是一种统一管理各种应用配置的基础服务组件。配置中心的出现可以解决这些问题使得配置信息集中管理易于维护并且可以动态更新配置使得分布式系统更加稳定可靠。 1.2 什么是Nacos配置中心
Nacos 提供用于存储配置和其他元数据的 key/value 存储为分布式系统中的外部化配置提供服务器端和客户端支持。使用 Spring Cloud Alibaba Nacos Config您可以在 Nacos Server 集中管理你 Spring Cloud 应用的外部属性配置。
配置中心的架构 应用场景 2. Nacos配置中心实战
2.1 微服务整合Nacos配置中心快速开始
1准备Nacos Server环境
参考Nacos注册中心笔记搭建Nacos Server环境 2微服务端整合Nacos配置中心
以mall-user-config-demo为例
2.1引入依赖
dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-config/artifactId
/dependency
dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-bootstrap/artifactId
/dependency
常见错误 No spring.config.import set
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: nacos.mall.com:8848username: nacospassword: nacos
3将application.yml中的配置移到配置中心 在配置中心中创建微服务的配置 DateID Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集每个配置集都可以被一个有意义的名称标识。
Group Nacos 中的一组配置集是组织配置的维度之一。通过一个有意义的字符串如 Buy 或 Trade 对配置集进行分组从而区分 Data 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 来配置。 5启动mall-user-config-demo服务测试调用http://localhost:8060/user/findOrderByUserId/1可以正常访问 查看控制台日志会发现openFeign的配置也是生效的 2.2 Nacos配置中心常用配置 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.activedev 支持自定义 namespace 的配置
用于进行租户粒度的配置隔离。不同的命名空间下可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离例如开发测试环境和生产环境的资源如配置、服务隔离等。
在没有明确指定 ${spring.cloud.nacos.config.namespace} 配置的情况下 默认使用的是 Nacos 上 Public 这个namespace。如果需要使用自定义的命名空间可以通过以下配置来实现 spring.cloud.nacos.config.namespace71bb9785-231f-4eca-b4dc-6be446e12ff8 支持自定义 Group 的配置
Group是组织配置的维度之一。通过一个有意义的字符串如 Buy 或 Trade 对配置集进行分组从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时如果未填写配置分组的名称则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景不同的应用或组件使用了相同的配置类型如 database_url 配置和 MQ_topic 配置。
在没有明确指定 ${spring.cloud.nacos.config.group} 配置的情况下默认是DEFAULT_GROUP 。如果需要自定义自己的 Group可以通过以下配置来实现 spring.cloud.nacos.config.groupDEVELOP_GROUP 支持自定义扩展的 Data Id 配置
Data ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包如 com.taobao.tc.refund.log.level的命名规则保证全局唯一性。此命名规则非强制。
在实际的业务场景中应用和共享配置间的关系可能如下
从单个应用的角度来看 应用可能会有多套(develop/beta/product)发布环境多套发布环境之间有不同的基础配置例如数据库。从多个应用的角度来看多个应用间可能会有一些共享通用的配置比如多个应用之间共用一套zookeeper集群。
通过自定义扩展的 Data Id 配置既可以解决多个应用间配置共享的问题又可以支持一个应用有多个配置文件。
spring:application:name: mall-user-config-demo #微服务名称profiles:active: dev #加载开发环境的配置文件cloud:nacos:config: #配置nacos配置中心地址server-addr: nacos.mall.com:8848username: nacospassword: nacosfile-extension: yml # 指定配置文件的扩展名为yml# 自定义 Data Id 的配置shared-configs: #不同工程的通用配置 支持共享的 DataId- data-id: nacos.ymlgroup: GLOBALE_GROUP- data-id: openfeign.ymlgroup: GLOBALE_GROUPextension-configs: # 支持一个应用多个 DataId 的配置- data-id: common.ymlgroup: REFRESH_GROUPrefresh: true #支持动态刷新
通过 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 拉取相关的配置。
A: 通过 spring.cloud.nacos.config.shared-configs 支持多个共享 Data Id 的配置B: 通过 spring.cloud.nacos.config.extension-configs[n].data-id 的方式支持多个扩展 Data Id 的配置C: 通过内部相关规则(应用名、应用名 Profile )自动生成相关的 Data Id 配置
当三种方式共同使用时他们的一个优先级关系是:A B C
完整的配置优先级从高到低
${spring.application.name}-${profile}.${file-extension}${spring.application.name}.${file-extension}${spring.application.name}extensionConfigssharedConfigs
完全关闭配置
通过设置 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引入依赖
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-actuator/artifactId
/dependency
2暴露监控端点
# 暴露所有的端点
management:endpoints:web:exposure:include: *
3) 查看Endpoint信息访问http://localhost:8060/actuator/nacosconfig 2.3 配置的动态刷新
spring-cloud-starter-alibaba-nacos-config 也支持配置的动态更新。
测试当动态配置刷新时会更新到 Enviroment中
1修改启动类每隔3s从Enviroment中获取common.user和common.age中的值
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(3);}}
2进入配置中心修改common.yml的配置common.age从10改成30 3查看控制台的输出common.age的值是否发生变化
OpenFeign开启对feign.Request.Options属性的刷新支持
Spring Cloud OpenFeign #启用刷新功能,可以刷新connectTimeout和readTimeout spring.cloud.openfeign.client.refresh-enabledtrue RefreshScope实现Bean的动态刷新
下面例子中使用Value注解可以获取到配置中心的值但是无法让IndexController动态感知修改后的值需要利用RefreshScope注解修饰。
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刷新配置后会导致定时任务失效
SpringBootApplication
EnableScheduling // 开启定时任务功能
public class NacosConfigApplication {
}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(定时任务正常执行。。。。。。);}}
测试结果
当在配置中心变更属性后定时任务失效当再次访问http://localhost:8060/common定时任务生效
原因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 的装配机制就是新的属性了
后面会结合源码分析核心源码GenericScope#get
解决方案
实现Spring事件监听器监听 RefreshScopeRefreshedEvent事件监听方法中进行一次定时方法的调用
RestController
RefreshScope //动态感知修改后的值
public class TestController implements ApplicationListenerRefreshScopeRefreshedEvent{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(定时任务正常执行。。。。。。);}Overridepublic void onApplicationEvent(RefreshScopeRefreshedEvent event) {this.execute();}
}
2.4 Nacos插件扩展配置加密
为保证用户敏感配置数据的安全Nacos 提供了配置加密的新特性。降低了用户使用的风险也不需要再对配置进行单独的加密处理。
参考文档配置加密
Nacos 加解密插件是可插拔的有没有都不影响 Nacos 的核心功能的运行。如果想要使用 Naocs 的配置加解密功能需要单独引用加密算法的实现。
在 Nacos 服务端启动的时候就会加载所有依赖的加解密算法然后通过发布配置的 dataId 的前缀(cipher-[加密算法名称])来进行匹配是否需要加解密和使用的加解密算法。
客户端发布的配置会在客户端通过filter完成加解密也就是配置在传输过程中都是密文的。而控制台发布的配置会在服务端进行处理。
客户端和服务端都通过添加以下依赖来使用 AES 加解密算法服务端推荐添加到 config 模块下。
!-- 引入加密插件 --
dependencygroupIdcom.alibaba.nacos/groupIdartifactIdnacos-aes-encryption-plugin/artifactIdversion1.0.0-SNAPSHOT/version
/dependency
注意目前插件需要自己编译,并未上传至maven中央仓库
1 编译nacos-aes-encryption-plugin插件
通过 SPI 的机制抽象出加密和解密的操作Nacos 默认提供 AES 的实现。用户也可以自定义加解密的实现方式。具体的实现在 nacos-plugin 仓库。 git clone gitgithub.com:nacos-group/nacos-plugin.gitmvn install
编译nacos-aes-encryption-plugin插件 如果不想自己编译可以直接下载下面的jar包 nacos-aes加密版使用 2) 在nacos的config包下引入nacos-aes-encryption-plugin依赖重新编译nacos服务端源码 3创建加密配置
配置前缀使用cipher-[加密算法名称]-dataId来标识这个配置需要加密系统会自动识别并加密。例如使用 AES 算法来解密配置cipher-aes-nacos.yml。 查看mysql数据库存储的数据是否加密
