Spring Cloud与Kubernetes系列文章已经更新到第十五篇，而源码分析类的文章笔者是默认大家都已经对Spring的源码所有了解了，至少什么工厂Bean、后置处理器BeanPostProcessor、Bean的生命周期、Spring容器的启动流程等都有所了解。
在继续分析Spring Cloud实现动态配置的源码之前，我们需要补充一些Spring Boot和Spring Cloud的基础知识才能继续往下看。本篇我们一起学习Spring Boot与Spring Cloud应用的启动流程。
SpringBoot应用启动流程
当我们在Spring Boot项目中调用SpringApplication的run方法启动应用时，Spring Boot应用启动流程粗粒度可划分为三个步骤。
第一步：准备环境Environment。此时会发送一个ApplicationEnvironmentPreparedEvent事件（应用环境准备事件），事件是同步消费的。当事件监听器都被调用完后，Spring Boot继续完成环境Environment的准备工作，加载application.yaml以及所有的ActiveProfiles对应的application-[activeProfile].yaml配置文件。
第二步：准备ApplicationContext容器。我们在spring.factories文件中配置的EnableAutoConfiguration就是在此时被读取的，并且根据配置的类名加载类，为类生成BeanDefinition注册到bean工厂中。
第三步：一切准备就绪后再刷新ApplicationContext。
Spring Boot启动流程如下图所示。
Spring Cloud应用启动流程
Spring Cloud项目可以在spring.factories配置文件中配置一种BootstrapConfiguration类，这与Spring Boot提供的EnableAutoConfiguration类并没有什么区别，只是它们作用在不同的ApplicationContext容器中。
当项目中添加Spring Cloud的依赖时，SpringApplication的run方法启动的就会是两个容器，即两个ApplicationContext。原本的应用启动流程也有所变化。
Spring Cloud的BootstrapApplicationListener监听ApplicationEnvironmentPreparedEvent事件，在监听到事件时开启一个新的ApplicationContext容器，我们可以称这个ApplicationContext容器为Spring Cloud的Bootstrap容器。
Bootstrap容器被用来注册spring.factories配置文件中配置的所有BootstrapConfiguration，并在Bootstrap容器初始化完成后将其Bean工厂作为原本Spring Boot启动的ApplicationContext容器的Bean工厂的父工厂，如下图所示。
这个Spring Cloud层的Bootstrap容器似乎是Spring Cloud特定为实现动态配置量身定做的。
Spring Cloud的启动流程如下图所示。
Spring Cloud创建为应用启动一个Bootstrap容器也会走一遍Spring Boot应用的启动流程。而原来main方法中调用SpringApplication的run方法启动ApplicationContext容器则会卡在环境准备阶段，等待Spring Cloud为其提供父工厂。
bootstrap.[yaml｜props]配置文件在BootstrapApplicationListener监听到ApplicationEnvironmentPreparedEvent事件时，准备启动Bootstrap容器之前读取，并写入到Bootstrap容器的Environment。
BootstrapApplicationListener通过判断Environment中是否存在bootstrap这个PropertySource辨别当前容器是否是Bootstrap容器，以解决无限监听到ApplicationEnvironmentPreparedEvent事件启动新容器的问题。
