image.png
nfig Ser ver实现原理分析
经过前⾯⼏个组件的源码阅读锻炼，相信同学们读起Config来已经不在话下了，作为配置中⼼的服务端，拉取参数三步⾛：
⾃动装配：秉承了Spring Cloud的⼀贯传统，⼀段故事从⼀个注解开始。我们只要在启动类上放个@EnableConfigServer注解就可以了，Config内部再通过@Import注解引⼊其他配置类，完成⾃动装配（具体承担⾃动装配的类是ConfigServerAutoConfiguration）环境仓库装配：启动了⾃动装配以后，⾃然要知道从哪⾥拉取配置⽂件，具体负责环境仓库装配的是
EnvironmentRepositoryConfiguration这个类。Config Server⽀持很多种⽂件存储仓库，⽐如JDBC，SVN，GitHub和本地⽂件，当然也可以配置多种类型组合的⽅式，也就是说Config会从不同的地⽅拉取配置⽂件。默认情况下Config采⽤基于GitHub的集成⽅式，这也是官
对外REST接⼝：从外部环境拉取到了配置⽂件之后，需要返回给客户端。Config通过EnvironmentController这个类对外提供了⼀套供客户端调⽤的REST格式接⼝，所有服务都是通过GET⽅法对外提供，客户端可以通过不同的URL路径获取相对应的配置内容
除此之外，Config还提供了属性转换的功能。假如我们提供的配置⽂件是yml形式的，如果希望获取其他格式的配置项，那么在调⽤第三步中的REST接⼝时可以在URL后⾯以扩展名结尾，⽐如“.json”或者”.properties“，Config Server会⾃动将配置内容转为对应格式。
image.png
3.Co nfig Client的实现原理
如果⼤家在l中定义了⼀个属性test，并使⽤占位符${remoteTest}作为test属性的值，当我们在Config Server中配置remoteTest属性后，你会发现在项⽬完成启动的时候，Config Server中的remoteTest被注⼊到了配置⽂件中的test属性。从这个现象我们可以得出⼀个结论，应⽤程序⼀定是在Spring上下⽂初始化的早期阶段就从Config Server获取了配置⽂件，这个过程优先于本地配置项的加载过程。
P.S. 关于⽂件加载顺序在这⾥多提⼀句，l⽂件在所有⽂件以前加载，所以Config的配置我们会放在l中。然后application.properties的加载优先级⽐l⽂件⾼。
我们来看看应⽤的初始化⽅式：
bootstrap项目image.png
SpringCloud应⽤同时也是⼀个SpringBoot应⽤，因此整个应⽤的初始化从SpringBoot启动时的上下⽂Context构建开始：
1.Sp r ing B oot构建C onte x t：
和所有的SpringBoot项⽬⼀样，通过SpringApplication类的run⽅法开始启动项⽬初始化和加载流程，其中就包括prepareContext这⼀步，整个项⽬的上下⽂结构就通过这个⽅法来构建
2.加载initialize r：
这是⼀连串的初始化构造过程，当我们在项⽬中引⼊了SpringCloud依赖时，PropertySourceBootstrapConfiguration将作为⼀个初始化构造器，参与SpringBoot上下⽂的初始化，⽤来加载SpringCloud的属性资源
3.加载initialize r：
PropertySourceBootstrapConfiguration是通过⼀系列的locator来定位资源⽂件的，当我们在项⽬中引⼊springcloud-config-client的依赖以后，就会开启Config组件的⾃动装配（由ConfigServiceBootstrap
Configuration实现），在这个⾃动装配过程中会向locator列表⾥添加⼀个专门⽤来获取远程⽂件的类-ConfigServicePropertySourceLocator
4.拉取远程⽂件：
ConfigServicePropertySourceLocator定义了执⾏顺序的优先级是0（通过@Order(0)注解定义），在Spring中这个数字越⼩则表⽰优先级越⾼，因此，这个组件将优先于其他locator先被执⾏。通过getRemoteEnvironment⽅法，向Config Server发起请求，获取远程属性

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。