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 支持很多种文件存储仓库,比如 JDBCSVNGitHub 和本地文件,当然也可以配置多种类型组合的方式,也就是说 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 构建开始:

  1. SpringBoot 构建 Context:和所有的 SpringBoot 项目一样,通过SpringApplication 类的 run 方法开始启动项目初始化和加载流程,其中就包括prepareContext 这一步,整个项目的上下文结构就通过这个方法来构建
  2. 加载 initializer:这是一连串的初始化构造过程,当我们在项目中引入了SpringCloud 依赖时,PropertySourceBootstrapConfiguration 将作为一个初始化构造器,参与 SpringBoot 上下文的初始化,用来加载 SpringCloud 的属性资源
  3. 初始化属性资源:PropertySourceBootstrapConfiguration 是通过一系列的 locator 来定位资源文件的,当我们在项目中引入 springcloud-config-client的依赖以后,就会开启 Config 组件的自动装配(由ConfigServiceBootstrapConfiguration 实现),在这个自动装配过程中会向locator 列表里添加一个专门用来获取远程文件的类-ConfigServicePropertySourceLocator
  4. 拉取远程文件:ConfigServicePropertySourceLocator 定义了执行顺序的优先级是 0(通过@Order(0)注解定义),在 Spring 中这个数字越小则表示优先级越高,因此,这个组件将优先于其他 locator 先被执行。通过getRemoteEnvironment() 方法,向 Config Server 发起请求,获取远程属性.

小结

本文带大家了解了配置中心的核心功能和运作原理,后续我们继续来了解一下 Config 客户端如何通过直连模式获取配置项。

本文已收录至我的个人网站:程序员波特,主要记录Java相关技术系列教程,共享电子书、Java学习路线、视频教程、简历模板和面试题等学习资源,让想要学习的你,不再迷茫。

热门相关:神医嫁到   士子风流   佣兵之王都市行   娇妻如云   影帝偏要住我家