看了其他大佬的文章记录一下自己追源码的过程。
Apollo配置中心动态生效机制，是基于Http长轮询请求和Spring扩展机制实现的，在Spring容器启动过程中，Apollo通过自定义的BeanPostProcessor和BeanFactoryPostProcessor將参数中包含${…}占位符和@Value注解的Bean注册到Apollo框架中定义的注册表中。然后通过Http长轮询不断的去获取服务端的配置信息，一旦配置发生变化，Apollo会根据变化的配置的Key找到对应的Bean，然后修改Bean的属性，从而实现了配置动态生效的特性。
需要注意的是，Apollo在配置变化后，只能修改Bean的属性，例如我们数据源的属性发生变化，新创建的Connection对象是没问题的，但是连接池中已经创建的Connection对象相关信息是不能动态修改的，所以依然需要重启应用。
Spring框架启动过程回顾
Apollo原理解析
首先找到他的入口@EnableApolloConfig
那么@EnableApolloConfig注解到底做了什么事情了，我们可以看下EnableApolloConfig注解的定义，代码如下
如上面代码所示，在EnableApolloConfig注解中，通过@Import注解导入了一个ApolloConfigRegistrar，接下来我们就来看一下：
ApolloConfigRegistrar继承了ImportBeanDefinitionRegistrar接口
ImportBeanDefinitionRegistrar接口是也是spring的扩展点之一,它可以支持我们自己写的代码封装成BeanDefinition对象;实现此接口的类会回调postProcessBeanDefinitionRegistry方法，注册到spring容器中。把bean注入到spring容器不止有 @Service @Component等注解方式；还可以实现此接口。
Ordered中定义了最高/低优先级的有用常量
EnvironmentAware是spring提供的一个接口，实现了EnvironmentAware接口重写setEnvironment方法后，在工程启动时可以获得application.properties的配置文件配置的属性值。
回到这里，上面说到该类实现了 ImportBeanDefinitionRegistrar 接口,拥有动态注册bean的能力,通过SPI机制加载 META-INF下 services 文件夹目录下的 DefaultApolloConfigRegistrarHelper 实现类。执行 registerBeanDefinitions 方法
ServiceBootstrap.loadPrimary(ApolloConfigRegistrarHelper.class);
在ServiceLoader.load的时候,根据传入的接口类,遍历META-INF/services目录下的以该类命名的文件中的所有类,并实例化返回
回来点进这里
Spring初始化Context的时候读取XML配置（基于XML）， 这个流程优先于Spring 普通Bean初始化。配合扫包(<context:component-scan />)得到的Bean进而实现对XML里面配置的Bean的载入。
PropertySourcesPlaceholderConfigurer本质上是一个BeanFactoryPostProcessor。解析XML的流程在BeanFactoryPostProcessor之前， 优先将配置文件的路径以及名字通过Setter传入PropertySourcesPlaceholderConfigurer
在上文我们剖析,配置热发布 源码中有提到 会从SpringValueRegistry中获取拥有配置信息的bean, 那它是如何找到拥有配置信息的bean,又是何时set进去的。
SpringValueRegistry具有 @Value 和 xml 配置占位符的字段或方法的 Spring 值处理器
先看下类关系图
主要继承自 ApolloProcessor 类,实现 BeanFactoryPostProcessor 、BeanFactoryAware 接口,我们知道这两个接口都是Spring的扩展接口,前者会在bean初始化前后调用钩子方法,后者提供beanFactory环境。该类重新了父类已实现的的钩子方法 postProcessBeforeInitialization
判断如果上下文开启了自动更新注入,则调用父类的postProcessBeforeInitialization
这里会遍历bean的每一个字段和每一个方法,分别调用processField 和 processMethod 方法,这两个方法是父类提供的抽象方法,我们先来看 processField 方法
获取字段上的 @Value 注解,如果没有,则不处理，有的进入doRegister方法
placeholderHelper.extractPlaceholderKeys 通过这个方法从占位符中提取键值 例如
●
●${some.key} => "some.key"
●${some.key:${some.other.key:100}} => "some.key", "some.other.key"
●${${some.key}} => "some.key"
●${${some.key:other.key}} => "some.key"
●${${some.key}:${another.key}} => "some.key", "another.key"
封装SpringValue对象,并注册到SpringValueRegistry对象中
processMethod 方法也一致,这里就不展开叙述了,唯一的区别是封装的SpringValue对象field字段为null
进入register中看看他做了什么
●如果map中不包含当前bean,则加入对象锁,进行初始化
●注册以当前bean对象为key,以@Value注解的key和封装成的SpringValue对象组成的map为value的map
●使用CAS特性避免重复执行initialize()
开启一条后台线程,不断得去清理map中,SpringValue的弱引用为null的。
找到registry的get方法看看哪里用到了他
当修改配置发布事件后，AutoUpdateConfigChangeListener就被触发onChange(ConfigChangeEvent changeEvent)事件
（1）通过event拿到所有变更的keys
（2）遍历keys，通过springValueRegistry.get(beanFactory, key) 拿到SpringValue集合对象
（3）判断配置是否真的发生了变化 shouldTriggerAutoUpdate(changeEvent, key)
（4）遍历SpringValue集合，逐一通过反射改变字段的值
