springcloud ApplicationInitialize两次调用以及配置中心对比分析

背景

springcloud工程，

1. 工作代码中新增了ApplicationContextInitializer（步骤：1. 增加实现类，2. spring.factories文件增加配置），联调过程中发现执行了两次initialize方法
2. debug ApolloApplicationContextInitializer类时，发现执行了两次initialize方法

ApplicationContextInitializer两次执行原因分析

1. springcloud创建 id为bootstrap 的ApplicationContext，该context后续作为main ApplicationContext的parent。同时，bootstrap也是由SpringApplication.run方法创建。
2. 在SpringApplication.run方法中，通过spi的机制获取ApplicationContextInitializer，并执行其initialize方法
3. bootstrap和application都执行了一次ApplicationContextInitializer的initialize方法，故在现象上看到两次执行记录

如何避免执行多次？

大部分的业务场景下，该Initializer执行一次即可，方案如下：

1. 保持是否执行过的状态，执行过一次后续就不再执行执行
2. apollo的实现，在initialize方法中判断是否propertySources中已然存在"ApolloBootstrapPropertySources"，来决定是否继续执行余下的逻辑。
3. 参考springcloud的实现

org.springframework.cloud.bootstrap.BootstrapConfiguration=\
org.springframework.cloud.bootstrap.config.PropertySourceBootstrapConfiguration

其中PropertySourceBootstrapConfiguration实现了ApplicationContextInitializer，在bootstrap 执行过程中把Initializer添加到main SpringApplication中，然后在main ApplicationContext初始化过程中执行一次对应initialize方法。

配置中心设计方案对比分析

结合apollo， nacos配置中心微服务实现，做简单对比分析。关于孰优孰略，我们暂不讨论，分布式配置中心核心流程包含配置项的加载，动态配置生效两部分，结合产品定位以及场景我们一起看下

1. Apollo和nacos配置中心的实现方案
   apollo作为微服务组件中的一员，因其简单的接入方式，完善的交互，权限控制以及容错性保障，在分布式配置中占有非常重要的地位。配置项加载的实现逻辑比较类似，通过PropertySource来加载对应的远端配置项，这点跟nacos的实现比较类似； 动态配置生效实现方案上，apollo使用SpringValue关联对应的spring bean，在配置项变更时，使用反射动态更新bean的字段值。
   nacos的动态配置生效，跟springcloud的规范保持一致，使用@RefreshScope，lazy动态代理； 当配置项变更时，销毁之前的target bean，重新创建新的bean对象。

2. springcloud对于分布式配置中心的规范化约束，核心类如下。
   PropertySourceLocator
   RefreshScope
   EnvironmentChangeEvent

3. 总结
   apollo的实现方案简单直接，在满足业务需求的前提下，精简的实现方案，跟springcloud的规范有出入；
   nacos符合springcloud的规范，让用户使用springcloud的规范化api来满足业务需求，不需要关心其实现细节；背后alibaba的加持以及spring-cloud–alibaba生态蓬勃发展，相信大家有目共睹，其他不再多言。