Spring Cloud Config
随着线上项目变的日益庞大,每个项目都散落着各种配置文件,如果采用分布式的开发模式,需要的配置文件随着服务增加而不断增多。某一个基础服务信息变更,都会引起一系列的更新和重启,运维苦不堪言也容易出错。配置中心便是解决此类问题的灵丹妙药。**Spring Cloud Config
,因为它功能全面强大,可以无缝的和spring
体系相结合。**
Spring Cloud Config
是 Spring Cloud
团队创建的一个全新项目,用来为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,它分为服务端与客户端两个部分。其中服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置仓库并为客户端提供获取配置信息、加密 / 解密信息等访问接口;而客户端则是微服务架构中的各个微服务应用或基础设施,它们通过指定的配置中心来管理应用资源与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息。Spring Cloud Config
实现了对服务端和客户端中环境变量和属性配置的抽象映射,所以它除了适用于 Spring
构建的应用程序之外,也可以在任何其他语言运行的应用程序中使用。由于 Spring Cloud Config
实现的配置中心默认采用 Git
来存储配置信息,所以使用 Spring Cloud Config
构建的配置服务器,天然就支持对微服务应用配置信息的版本管理,并且可以通过 Git
客户端工具来方便的管理和访问配置内容。当然它也提供了对其他存储方式的支持,比如:SVN
仓库、本地化文件系统。
配置中心提供的功能:
- 提供服务端和客户端支持
- 集中管理各环境的配置文件
- 配置文件修改之后,可以快速的生效
- 可以进行版本管理
- 支持大的并发查询
- 支持各种语言
准备工作
在 Github
上面创建了一个文件夹 config-repo
用来存放配置文件,创建以下三个配置文件:
// 开发环境 |
每个文件都写一个test.hello
属性,属性值分别是dev
、test
、prod
,如:
test: |
Server端
创建一个基础的 Spring Boot
工程,命名为:config-server-git
。
POM
<properties> |
添加spring-cloud-config-server
依赖。
配置文件
在配置文件中配置服务的基本信息以及git的地址:
spring: |
Spring Cloud Config
也提供本地存储配置的方式。我们只需要设置属性spring.profiles.active=native
,Config Server
会默认从应用的src/main/resource
目录下检索配置文件。也可以通过spring.cloud.config.server.native.searchLocations=file:E:/properties/
属性来指定配置文件的位置。虽然 Spring Cloud Config
提供了这样的功能,但是为了支持更好的管理内容和版本控制的功能,还是推荐使用 Git
的方式。
如果我们的 Git 仓库需要权限访问,那么可以通过配置下面的两个属性来实现;
spring.cloud.config.server.git.username:访问 Git 仓库的用户名
spring.cloud.config.server.git.password:访问 Git 仓库的用户密码
启动类
启动类添加@EnableConfigServer
,激活对配置中心的支持:
|
Server
端的配置到此为止
测试
测试 Server
端是否可以读取到 github
上面的配置信息,通过postman
请求http://localhost:28088/test-config/test,返回如下信息:
{ |
注:路径中的test-config
是指config-repo
中的文件名前缀。
修改test-config-test.yml
中的内容,再次在postman
请求,发现返回的内容是最新的了,说明Server
端会自动读取最新提交的内容。
仓库中的配置文件会被转换成 Web 接口,访问可以参照以下的规则:
- /{application}/{profile}[/{label}]
- /{application}-{profile}.yml
- /{label}/{application}-{profile}.yml
- /{application}-{profile}.properties
- /{label}/{application}-{profile}.properties
上面的
URL
会映射{application}-{profile}.yml
对应的配置文件,其中{label}
对应 Git 上不同的分支,默认为master
。以config-client-dev.yml
为例子,它的application
是config-client
,profile
是dev
。
Client端
在微服务应用中获取上述的配置信息。再创建一个基础的 Spring Boot
应用,命名为 config-client
。
POM
修改pom
文件,引入如下配置:
<properties> |
spring-boot-starter-webflux
是为了方便 Web
测试。Spring WebFlux
是随 Spring 5
推出的响应式 Web
框架。
配置文件
需要两个配置文件,application.yml
和bootstrap.yml
。
application.yml
:
spring: |
bootstrap.yml
:
spring: |
- spring.application.name:对应{application}部分
- spring.cloud.config.profile:对应{profile}部分
- spring.cloud.config.label:对应git的分支。如果配置中心使用的是本地存储,则该参数无用
- spring.cloud.config.uri:配置中心的具体地址
- spring.cloud.config.discovery.service-id:指定配置中心的service-id,便于扩展为高可用配置集群。
上面这些与
Spring Cloud Config
相关的属性必须配置在bootstrap.yml
中,config
部分内容才能被正确加载。因为config
的相关配置会先于application.yml
,而bootstrap.yml
的加载也是先于application.yml
。
启动类
不需要修改:
|
新建HelloController
,使用@value
注解来获取Server
端参数的值
|
测试
使用postman
请求http://localhost:28089/info,返回如下结果,则说明Client
端成功获取到了Server
端的配置值。
至此,SpringCloud
的Git
版配置中心就完成了。
Refresh
Spring Cloud Config
分服务端和客户端,服务端负责将git(svn)
中存储的配置文件发布成REST
接口,客户端可以从服务端REST
接口获取配置。但客户端并不能主动感知到配置的变化,从而主动去获取新的配置。客户端如何去主动获取新的配置信息呢,springcloud
已经给我们提供了解决方案,每个客户端通过POST
方法触发各自的/refresh
。
仅修改客户端项目,就可以实现 refresh
的功能。
添加依赖
<dependency> |
增加了spring-boot-starter-actuator
包,spring-boot-starter-actuator
是一套监控的功能,可以监控程序在运行时状态,其中就包括/actuator/refresh
的功能。
开启更新机制
需要给加载变量的类上面加载@RefreshScope
,在客户端执行/actuator/refresh
的时候就会更新此类下面的变量值。
|
配置文件
SpringBoot1.5
以后需要添加以下配置以将/actuator/refresh
这个 Endpoint
暴露出来:
management: |
测试
重启 config-client
,我们以 POST
请求的方式来访问http://localhost:28089/actuator/refresh就会更新配置文件至最新版本。
- 修改
test-config-test.yml
文件的内容 - 使用
postman
请求http://localhost:28089/actuator/refresh接口 - 再请求http://localhost:28089/info接口
- 发现配置内容已经更新到最新了
至此,配置中心的配置刷新就算完成了,但是这样做有个弊端,就是每次更新了配置之后都要请求refresh
接口,这就很麻烦。。
Webhook
Webhook
是当某个事件发生时,通过发送 HTTP POST
请求的方式来通知信息接收方。Webhook
来监测你在 Github.com
上的各种事件,最常见的莫过于 push
事件。如果你设置了一个监测 push
事件的 Webhook
,那么每当你的这个项目有了任何提交,这个 Webhook
都会被触发,这时 Github
就会发送一个 HTTP POST
请求到你配置好的地址。
如此一来,你就可以通过这种方式去自动完成一些重复性工作,比如,你可以用 Webhook
来自动触发一些持续集成(CI)工具的运作,比如 Travis CI
;又或者是通过 Webhook
去部署你的线上服务器。下图就是 Github
上面的 Webhook
配置。
Payload URL
:触发后回调的 URLContent type
:数据格式,两种一般使用 jsonSecret
:用作给 POST 的 body 加密的字符串。采用 HMAC 算法events
:触发的事件列表。
events 事件类型 | 描述 |
---|---|
push | 仓库有 push 时触发。默认事件 |
create | 当有分支或标签被创建时触发 |
delete | 当有分支或标签被删除时触发 |
这样我们就可以利用 hook
的机制去触发客户端的更新,但是当客户端越来越多的时候,hook
机制也不够优雅了,另外每次增加客户端都需要改动 hook
也是不现实的。其实,Spring Cloud
给了我们更好解决方案——Spring Cloud Bus
。