SpringCloud Config分布式配置中心
- 1、SpringCloud Config概述
- 1.1 分布式系统面临的配置问题
- 1.2 SpringCloud Config是什么?
- 1.3 分布式配置中心能做什么?
- 1.4 与GitHub或Gitee整合配置
- 2、Config服务端配置与测试
- 2.1 创建仓库
- 2.2 新建cloud-config-center-3344模块
- 2.3 pom.xml
- 2.4 application.yml
- 2.5 主启动类
- 2.6 测试
- 2.7 读取配置规则
- 3、Config客户端配置与测试
- 3.1 新建cloud-config-client-3355模块
- 3.2 pom.xml
- 3.3 bootstrap.yml
- 3.3.1 bootstrap.yml是什么?
- 3.3.2 bootstrap.yml内容
- 3.4 主启动类
- 3.5 业务类
- 3.6 测试
- 3.7 当前配置存在的问题
- 4、Config客户端之动态刷新
- 4.1 修改3355模块
- 4.1.1 pom引入actuator监控
- 4.1.2 修改yml,暴露监控端口
- 4.1.3 业务类Controller添加注解@RefreshScope
- 4.2 测试
- 4.3 还需要改进的地方有哪些?
笔记来源于周阳老师的SpringCloud视频,本人手敲总结出来的。
我去年发布过的文章:
Spring Cloud ConfigBus集成webhooks实现自动刷新
1、SpringCloud Config概述
1.1 分布式系统面临的配置问题
微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。
SpringCloud提供了ConfigServer来解决这个问题。
1.2 SpringCloud Config是什么?
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
SpringCloud Config分为服务端和客户端两部分。
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口。
客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容。
1.3 分布式配置中心能做什么?
- 集中管理配置文件
- 不同环境不同配置,动态化的配置更新,分环境部署比如dev/test/prod/beta/release
- 运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息
- 当配置发生变动时,服务不需要重启即可感知到配置的变化并应用新的配置
- 将配置信息以REST接口的形式暴露:post、curl访问刷新均可。
1.4 与GitHub或Gitee整合配置
由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持SVN和本地文件),但最推荐的还是Git,而且使用的是http/https访问的形式
官方文档:https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/
2、Config服务端配置与测试
2.1 创建仓库
这里由于有“墙”的存在,我这里配置用Gitee,视频中用的是GitHub
我这里的仓库地址是:https://gitee.com/interface_xiongtete/springcloud-config,没有文件的可以从这里clone。
2.2 新建cloud-config-center-3344模块
它即为Cloud的配置中心模块cloudConfig Center
2.3 pom.xml
2.4 application.yml
2.5 主启动类
加上@EnableConfigServer
注解
这里再加一步:windows下修改hosts文件,增加映射 127.0.0.1 config-3344.com
2.6 测试
测试通过Config微服务是否可以从Gitee上获取配置内容
启动微服务3344
访问:http://config-3344.com:3344/master/config-dev.yml
和仓库中的文件对比,发现是一致的。
2.7 读取配置规则
官网给出了5中配置方式,我们这里只介绍主要用的3种。
- /{label}/{application}-{profile}.yml
我们访问master分支:
http://config-3344.com:3344/master/config-dev.yml
http://config-3344.com:3344/master/config-test.yml
http://config-3344.com:3344/master/config-prod.yml
dev分支:
http://config-3344.com:3344/dev/config-dev.yml
http://config-3344.com:3344/dev/config-test.yml
http://config-3344.com:3344/dev/config-prod.yml
- /{application}-{profile}.yml
http://config-3344.com:3344/config-dev.yml
http://config-3344.com:3344/config-test.yml
http://config-3344.com:3344/config-prod.yml
- /{application}/{profile}[/{label}]
http://config-3344.com:3344/config/dev/master
http://config-3344.com:3344/config/test/master
http://config-3344.com:3344/config/test/dev
重要配置细节总结:
label:分支(branch)
name :服务名
profiles:环境(dev/test/prod)成功实现了用SpringCloud Config通过Gitee获取配置信息
3、Config客户端配置与测试
3.1 新建cloud-config-client-3355模块
3.2 pom.xml
3.3 bootstrap.yml
3.3.1 bootstrap.yml是什么?
applicaiton.yml是用户级的资源配置项
bootstrap.yml是系统级的,优先级更加高
Spring Cloud会创建一个“Bootstrap Context”,作为Spring应用的Application Context
的父上下文。初始化的时候,Bootstrap Context
负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment
。
Bootstrap
属性有高优先级,默认情况下,它们不会被本地配置覆盖。 Bootstrap context
和Application Context
有着不同的约定,所以新增了一个bootstrap.yml
文件,保证Bootstrap Context
和Application Context
配置的分离。
要将Client模块下的application.yml文件改为bootstrap.yml,这是很关键的,
因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml
3.3.2 bootstrap.yml内容
说明:根据上面的配置回去找master分支上面的config-dev.yml配置文件。
3.4 主启动类
3.5 业务类
3.6 测试
启动Config配置中心3344微服务并自测
http://config-3344.com:3344/master/config-prod.yml
http://config-3344.com:3344/master/config-dev.yml
启动3355作为Client准备访问:http://localhost:3355/configInfo
根据bootstrap.yml中的配置会去找master分支上面的config-dev.yml配置文件。
成功实现了客户端3355访问SpringCloud Config3344通过Gitee获取配置信息
3.7 当前配置存在的问题
Linux运维修改Gitee上的配置文件内容做调整,我们尝试修改version,改为verision=4
刷新3344,发现ConfigServer配置中心立刻响应
刷新3355,发现ConfigClient客户端没有任何响应
3355没有变化除非自己重启或者重新加载,难到每次运维修改配置文件,客户端都需要重启??当然不是,解决方案在下面。
4、Config客户端之动态刷新
这主要是为了解决每次更新配置都要重启客户端的问题
4.1 修改3355模块
4.1.1 pom引入actuator监控
4.1.2 修改yml,暴露监控端口
4.1.3 业务类Controller添加注解@RefreshScope
4.2 测试
此时再次修改远程仓库master分支上的config-dev.yml配置文件
修改version=5
http://localhost:3355/configInfo
这里发现3355的version还是没有变,这里需要需要运维人员发送Post请求刷新3355
我们手动发送post请求
再次刷新3355:http://localhost:3355/configInfo
发现版本号已经和远程仓库中的一致了。
到此,成功实现了客户端3355刷新到最新配置内容,避免了服务重启。
4.3 还需要改进的地方有哪些?
假如有多个微服务客户端3355/3366/3377等,难道我们每个微服务都要执行一次post请求,手动刷新吗?能否实现消息广播,一次通知,处处生效,别着急,后面我再写一篇SpringCloud Bus消息总线。