Spring Cloud Context 阅读记录

https://docs.spring.io/spring-cloud-commons/docs/current/reference/html/#spring-cloud-context-application-context-services

Spring Cloud 提供了更多功能作为两个库：Spring Cloud Context 和 Spring Cloud Commons。

• Spring Cloud Context 为ApplicationContextSpring Cloud 应用程序（引导上下文、加密、刷新范围和环境端点）提供实用程序和特殊服务。
• Spring Cloud Commons 是在不同的 Spring Cloud 实现（例如 Spring Cloud Netflix 和 Spring Cloud Consul）中使用的一组抽象和通用类。

image-20211129105635286

image-20211126170333324

image-20211126170422664

image-20211126170557304

image-20211126170631270

image-20211126170722947

image-20211126171914042

那么他为啥要再启动一个容器，启动的这个容器都做了什么？

image-20211129094857581

image-20211129101516236

• PropertySourceBootstrapConfiguration
  • 这就是那个解析 cloud config 的初始化器
• EncryptionBootstrapConfiguration
  • Spring 内置了加解密，支持对称加密和非对称加密。使用对称加密只需要在bootstrap.yml文件中通过encrypt.key属性指定加密用的密钥，这样SpringCloud就会自动创建一个org.springframework.security.crypto.encrypt.TextEncryptor类型的bean。
  • 其中可以解析配置文件中加密配置的 bean EnvironmentDecryptApplicationInitializer 也是这个配置类注入的。
• ConfigurationPropertiesRebinderAutoConfiguration
  • 与属性动态刷新（@RefreshScope）相关
  • 监听 EnvironmentChangeEvent，然后绑定那些我们已经用 ConfigrationProperties 绑定过的 beans。
• 其他两个（wo ye）不重（zhi）要（dao）...

总结一下：创建这个父容器是为了从 spring.factories 文件中解析出 @BootstrapConfiguration 对应的自动配置类，准备一些后续需要使用到的bean。

然后又启动了一圈又回来了。

image-20211129105101417

image-20211126173825653

image-20211126173855250

这些initializer啥时候被调用的呢？

image-20211129092758033

image-20211129092900576

所以，总结一下 BootstrapApplicationListener 主要做了 2 件事：

1. 启动了自己的父容器，从 spring.factories 文件中解析出 @BootstrapConfiguration 对应的自动配置类，准备一些后续需要使用到的bean。
2. 为 SpringApplication 添加了一些初始化器，在”子“容器启动前做一些事情

接下来看一下其中一个比较重要的初始化器 PropertySourceBootstrapConfiguration，他主要是用来解析 cloud config 的。

image-20211130151906815

image-20211130150634938

上面那个是加载远程文件的，本地的 bootstrap* 文件是在“父”容器启动时触发 ApplicationEnvironmentPreparedEvent 然后到了监听器 ConfigFileApplicationListener 来加载的。

image-20211129124015493

因为BootstrapApplicationListener排在第一位，他又启动了“父”容器，所以第一次启动时并没有执行到 ConfigFileApplicationListener，第一次执行 ConfigFileApplicationListener 是“父”容器，

image-20211129124259272

image-20211129124806850

image-20211129125220097

image-20211129125500829

1. file: ./config/ & file:./ 为了 java -jar 启动时读取 jar 包外的配置
2. classpath:/config/ & classpath:/ 读取类路径下的配置

image-20211130102709666

todo

1. 可能与参数动态刷新有关，可以研究下日后，用于xadmin

image-20211126171635460

image-20211126172902301

3. 突然觉得日志的配置要放到bootstrap.yml中一份了（application可以覆盖吗？）

image-20211129110327558

4. why？

   

   wecom-temp-0242631582c5b2ad38748456f2a73085
   

   wecom-temp-2af26aa0f18b2846e98917a41e1a1908

5. 配置文件覆盖优先级？