文章目录
背景
springcloud工程,
- 工作代码中新增了ApplicationContextInitializer(步骤:1. 增加实现类,2. spring.factories文件增加配置),联调过程中发现执行了两次initialize方法
- debug ApolloApplicationContextInitializer类时,发现执行了两次initialize方法
ApplicationContextInitializer两次执行原因分析
- springcloud创建 id为bootstrap 的ApplicationContext,该context后续作为main ApplicationContext的parent。同时,bootstrap也是由SpringApplication.run方法创建。
- 在SpringApplication.run方法中,通过spi的机制获取ApplicationContextInitializer,并执行其initialize方法
- bootstrap和application都执行了一次ApplicationContextInitializer的initialize方法,故在现象上看到两次执行记录
如何避免执行多次?
大部分的业务场景下,该Initializer执行一次即可,方案如下:
- 保持是否执行过的状态,执行过一次后续就不再执行执行
- apollo的实现,在initialize方法中判断是否propertySources中已然存在"ApolloBootstrapPropertySources",来决定是否继续执行余下的逻辑。
- 参考springcloud的实现
org.springframework.cloud.bootstrap.BootstrapConfiguration=\
org.springframework.cloud.bootstrap.config.PropertySourceBootstrapConfiguration
其中PropertySourceBootstrapConfiguration实现了ApplicationContextInitializer,在bootstrap 执行过程中把Initializer添加到main SpringApplication中,然后在main ApplicationContext初始化过程中执行一次对应initialize方法。
配置中心设计方案对比分析
结合apollo, nacos配置中心微服务实现,做简单对比分析。关于孰优孰略,我们暂不讨论,分布式配置中心核心流程包含配置项的加载,动态配置生效两部分,结合产品定位以及场景我们一起看下
-
Apollo和nacos配置中心的实现方案
apollo作为微服务组件中的一员,因其简单的接入方式,完善的交互,权限控制以及容错性保障,在分布式配置中占有非常重要的地位。配置项加载的实现逻辑比较类似,通过PropertySource来加载对应的远端配置项,这点跟nacos的实现比较类似; 动态配置生效实现方案上,apollo使用SpringValue关联对应的spring bean,在配置项变更时,使用反射动态更新bean的字段值。
nacos的动态配置生效,跟springcloud的规范保持一致,使用@RefreshScope,lazy动态代理; 当配置项变更时,销毁之前的target bean,重新创建新的bean对象。 -
springcloud对于分布式配置中心的规范化约束,核心类如下。
PropertySourceLocator
RefreshScope
EnvironmentChangeEvent -
总结
apollo的实现方案简单直接,在满足业务需求的前提下,精简的实现方案,跟springcloud的规范有出入;
nacos符合springcloud的规范,让用户使用springcloud的规范化api来满足业务需求,不需要关心其实现细节;背后alibaba的加持以及spring-cloud–alibaba生态蓬勃发展,相信大家有目共睹,其他不再多言。
原文地址:https://blog.csdn.net/weixin_43493520/article/details/113943752
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。