Config分布式配置中心前置
-
微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。我们每个微服务自己带着一个application.yml,过多的配置管理将出现问题,springcloud提供了ConfigServer来解决这个问题。
-
springcloud config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
-
springcloud Config分为服务端和客户端两部分。
- 服务端:也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器,并为客户端提供获取配置信息,加密/解密信息等访问接口。
- 客户端:是通过指定配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候,从配置中心获取和加载配置信息,配置,配置服务器默认采用git来存储配置信息,这样有助于对环境配置进行版本管理,并且可以通过git客户端工具,来方便的管理和访问配置内容。
-
具体功能:
- 集中管理配置文件;
- 不同环境不同配置,动态化的配置更新,分环境部署,比如dev、test、prod、beta、release;
- 运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息;
- 当配置发生变动时,服务不需要重启,即可感知到配置的变化,并应用新的配置;
- 将配置信息以REST接口的形式暴露,用post、curl访问刷新均可…
-
与GitHub整合配置,由于SpringCloud Config默认使用Git来存储配置文件(最推荐使用Git),而且使用的是http/https访问的形式。
版本说明
- cloud Hoxton.SR1
- boot 2.2.2RELEASE
- cloud alibaba 2.1.0 RELEASE
- java java8
- Maven 3.5以上
- Mysql 5.7以上
Config分布式配置中心
config服务端配置与测试
-
用自己的账号在GitHub上新建名为springcloud-config的新Repostiry。
-
获取新建的git地址,https://github.com/AJ-Spade/springcloud-config.git
-
在本地硬盘目录上新建git仓库,并clone,具体:
-
新建模块cloud-config-center-3344,它即为Cloud的配置中心模块cloudConfig Center;
-
POM、YML文件;
server: port: 3344 spring: application: name: cloud-config-center #注册进Eureka服务器的微服务名 cloud: config: server: git: uri: git@github.com:AJ-Spade/springcloud-config.git #GitHub上面的git仓库名字 ###搜索目录 search-paths: - springcloud-config ####读取分支 label: master #服务注册到eureka地址 eureka: client: service-url: defaultZone: http://localhost:7001/eureka
-
编写主启动类;
//别忘了这两个注解 @SpringBootApplication @EnableConfigServer
-
windows下修改hosts文件,增加映射;注意:修改hosts,增加映射时,最后一行一定要是回车,否则最后一行不生效!!!!
-
测试通过Config微服务是否可以从GitHub上获取配置内容;启动7001/7002,访问localhost:3344/master/config-dev.yml
-
配置读取规则(label表示分支(branch)、name:表示服务名、profiles:表示环境(dev/test/prod);
-
/{label}/{application}-{profile}.yml
-
例如读master分支,url如下:
http://config-3344.com:3344/master/config-dev.yml
-
例如读dev分支,url如下:
http://config-3344.com:3344/dev/config-dev.yml
-
-
/{application}-{profile}.yml
-
/{application}/{profile}[/{lable}]
-
-
成功实现了用SpringCloud Config通过GitHub获取配置信息;
config客户端配置与测试
- 新建cloud-config-client-3355
- POM
- 添加bootstrap.yml
- 修改config-dev.yml配置,并提交到GitHub中,比如加个变量age或者版本号version
- 主启动类
- 业务类
- 测试:
- 启动Config配置中心3344微服务,并自测:1. http://config-3344.com:3344/master;2. http://config-3344.com/master
- 启动3355作为Client准备访问:http://localhost:3355/configInfo
- 成功实现客户端3355访问springcloud config3344通过github获取配置信息
- 但产生的问题:即分布式配置的动态刷新问题:
- 修改GitHub的配置文件内容做调整;
- 刷新3344,发现ConfigServer配置中心立刻响应;
- 刷新3355,发现ConfigClient客户端没有任何响应;
- 3355没有变化,除非自己重启或重新下载。
config客户端之动态刷新
-
问题:每次有新配置,都要重启客户端微服务3355,才能读出更新后的内容;
-
config客户端设置动态刷新的步骤:
-
修改3355模块;
-
POM引入actuator监控;
-
修改YML,暴露监控端口;
-
@RefreshScope业务类Controller的修改;
-
然后需要运维人员发送Post请求刷新3355:
-
curl -X POST "http://localhost:3355/actuator/refresh"
-
-
是否可以实现一次通知,处处(假设有多个config客户端)生效,或者定向通知某些客户端(有100台机器,只通知指定的89台)?
- 目前来说做不到,只能用springcloud bus(消息总线)。
-
需熟练掌握
知识点
- 如果需要修改,此处模拟运维人员操作git和github:
- git add …
- git commit -m “init yml”
- git push origin master
- bootstrap.yml是什么?
- application.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。
tips
-
从github上clone文件,命令:
git clone https://github.com/AJ-Spade/springcloud-config.git
-
从本地推送到github:
//在要同步的文件夹下,右键打开git同步,然后点击管理,然后添加远端即可,第一个是名字(随便取),第二个是github的HTTPS地址,然后添加保存即可。最后点击推送即可。
-
注意:修改hosts,增加映射时,最后一行一定要是回车,否则最后一行不生效!!!!
代码地址:https://github.com/AJ-Spade/cloud2020/tree/master