前面我们认识了配置中心的作用，接下来我们来了解一下Spring Cloud中的配置管理组件Config。
配置管理的前世今生
随着技术的发展，配置项管理变得越来越简单，尽管如今它只限于管理业务属性或者配置初始化参数等等，但是当年它可肩负着Spring IOC的光荣使命，风光无限。
老师刚入行的时候还是SSH（Struts + Spring + Hibernate）的天下，那时远没有如今这些丰富的开源组件，一个标准的Java程序员就是靠SSH这三把刷子打天下，正所谓学好数理化，走遍天下都不怕，但那时候的配置管理是一件让人头疼的事情。
早先SSH的配置管理可以说是相当复杂，每个项目的XML配置文件大大小小几十个。如果有过Struts1的使用经验就能理解这种痛苦，创建一个Form表单从前到后要创建好几个Java Class，还要再加上一大堆配置文件。那时的Spring还没有@Autowired功能，所有类之间的依赖关系全部靠XML来描述，远不像今天一个auto-scan搞定一切。所以，配置管理承担了Spring的依赖注入功能。
第一次工业革命
这一次由Spring引领，在Spring引入自动装配机制以后，情况发生了天翻地覆的变化。基于注解的自动装配取代了繁重的XML配置，使用@Autowired，@Qualifier，@Primary等一系列自动装配注解，把所有关于“依赖注入”的繁重工作从配置项中解放了出来。
现在的项目已经很少看到XML配置的身影了，配置文件只要关注业务属性的管理，比如说注册中心的连接参数，或者某个功能开关的控制等等。
第二次工业革命
随着应用复杂度的提升，大家开始意识到使用工程化的方式对待杂乱的配置项
- 环境隔离：当项目中建立起了多级环境（从测试、集成、上线都有独立的研发环境），需要我们的应用根据不同环境加载不同的配置文件，把各个不同环境的配置项隔离开来，把配置文件也纳入工程化部署的一部分
- 运行期变更：大多数配置文件的内容是静态属性，也就是说自打项目启动加载一次以后就再也不会发生变化，可随着业务复杂度提升，我们也需要一种能够在应用运行期修改属性的功能，以支持复杂业务场景
在这个阶段各种技术百花齐放，每个公司都有自己的玩法，就拿第二点来说，有些公司直接把需要动态变更的属性放到数据库中或者缓存中，每次运行的时候去读取一把，但是这并不是一种既方便又高效的解决方案。那么我们有没有一个简单、高效并且还易于管理的方式可以应用在配置项上呢？我们接下来就看看Spring Cloud是如何设计配置管理的。
Config Server核心功能
Config作为Spring Cloud官方指定产品，在配置管理方面主要提供了三个功能
- 统一配置 提供了一个中心化的配置方案，将各个项目中的配置内容集中在Config Server一端
- 环境隔离 Config Server提供了多种环境隔离机制，Client可以根据自身所处的项目环境（比如生产环境、测试环境）加载对应的配置文件
- 动态刷新 支持运行期改变配置属性
除了上面三个功能以外，还有加密解密、定向推送等功能，我们暂且不表，在后面的章节中再做深入了解。
Config Server实现原理分析
经过前面几个组件的源码阅读锻炼，相信同学们读起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会自动将配置内容转为对应格式。
Config Client的实现原理
如果大家在application.yml中定义了一个属性test，并使用占位符${remoteTest}作为test属性的值，当我们在Config Server中配置remoteTest属性后，你会发现在项目完成启动的时候，Config Server中的remoteTest被注入到了配置文件中的test属性。从这个现象我们可以得出一个结论，应用程序一定是在Spring上下文初始化的早期阶段就从Config Server获取了配置文件，这个过程优先于本地配置项的加载过程。
P.S. 关于文件加载顺序在这里多提一句，bootstrap.yml文件在所有文件以前加载，所以Config的配置我们会放在bootstrap.yml中。然后application.properties的加载优先级比application.yml文件高。
我们来看看应用的初始化方式：
SpringCloud应用同时也是一个SpringBoot应用，因此整个应用的初始化从SpringBoot启动时的上下文Context构建开始：
- SpringBoot构建Context：和所有的SpringBoot项目一样，通过SpringApplication类的run方法开始启动项目初始化和加载流程，其中就包括prepareContext这一步，整个项目的上下文结构就通过这个方法来构建
- 加载initializer：这是一连串的初始化构造过程，当我们在项目中引入了SpringCloud依赖时，PropertySourceBootstrapConfiguration将作为一个初始化构造器，参与SpringBoot上下文的初始化，用来加载SpringCloud的属性资源
- 初始化属性资源：PropertySourceBootstrapConfiguration是通过一系列的locator来定位资源文件的，当我们在项目中引入springcloud-config-client的依赖以后，就会开启Config组件的自动装配（由ConfigServiceBootstrapConfiguration实现），在这个自动装配过程中会向locator列表里添加一个专门用来获取远程文件的类-ConfigServicePropertySourceLocator
- 拉取远程文件：ConfigServicePropertySourceLocator定义了执行顺序的优先级是0（通过@Order(0)注解定义），在Spring中这个数字越小则表示优先级越高，因此，这个组件将优先于其他locator先被执行。通过getRemoteEnvironment方法，向Config Server发起请求，获取远程属性
小结
这一节带大家了解了配置中心的核心功能和运作原理，下一节我们来了解一下Config客户端如何通过直连模式获取配置项。
若有收获，就点个赞吧
0 人点赞
