构建微服务架构(Config 篇)
该篇文档,前置代码下载:下载
该篇文档,全部完成后的代码下载:下载
原文链接:https://blog.csdn.net/u011863024/article/details/114298270
SpringCloud: https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/
Config分布式配置中心介绍
分布式系统面临的配置问题
微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。
SpringCloud 提供了 ConfigServer 来解决这个问题,我们每一个微服务自己带着一个 application.yml,上百个配置文件的管理.……
是什么
SpringCloud Config 为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
怎么玩
SpringCloud Config 分为服务端和客户端两部分。
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口。
客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容。
能干嘛
集中管理配置文件
不同环境不同配置,动态化的配置更新,分环境部署比如 dev/test/prod/beta/release
运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息
当配置发生变动时,服务不需要重启即可感知到配置的变化并应用新的配置
将配置信息以 REST 接口的形式暴露 - post/crul 访问刷新即可…
与 GitHub 整合配置
由于 SpringCloud Config 默认使用 Git 来存储配置文件(也有其它方式,比如支持 SVN 和本地文件),但最推荐的还是 Git,而且使用的是 http/https 访问的形式。
Config 配置总控中心搭建
1. 用你自己的账号在 GitHub 上新建一个名为 springcloud-config 的新 Repository。
由上一步获得刚新建的git地址 - https://github.com/Sevattal/springcloud-config.git
本地硬盘目录上新建git仓库并clone。
工作目录为 D:\SpringCloud2021
1 | git clone https://github.com/Sevattal/springcloud-config.git |
此时在工作目录会创建名为 springcloud-config 的文件夹。
在springcloud-config的文件夹种创建三个配置文件(为本次教学使用的),随后 git add .,git commit -m “sth” 等一系列上传操作上传到 springcloud-config 的新 Repository。
config-dev.yml
1 | config: |
config-prod.yml
1 | config: |
config-test.yml
1 | config: |
2. 新建Module模块cloud-config-center-3344,它即为Cloud的配置中心模块CloudConfig Center
3. cloud-config-center-3344 项目 pom.xml文件
1 | <?xml version="1.0" encoding="UTF-8"?> |
4. cloud-config-center-3344 项目 application.yml 文件 (若是私有仓库需要配置 密钥或者是账号和密码)
1 | server: |
注意:目前 GitHub 上的默认分支为 main,请按照实际的分支进行配置
5. cloud-config-center-3344 项目 主启动类 文件
1 | package com.sevattal.springcloud; |
6. windows下修改hosts文件,增加映射
1 | 127.0.0.1 config-3344.com |
7. 测试通过 Config 微服务是否可以从 GitHub 上获取配置内容
启动 ConfigCenterMain3344
浏览器防问 - http://config-3344.com:3344/master/config-dev.yml
页面返回结果:
1 | config: |
8. 配置读取规则
/{label}/{application}-{profile}.yml(推荐)
master分支
1 | http://config-3344.com:3344/master/config-dev.yml |
dev分支
1 | http://config-3344.com:3344/dev/config-dev.yml |
/{application}-{profile}.yml
1 | http://config-3344.com:3344/config-dev.yml |
/{application}/{profile}[/{label}]
1 | http://config-3344.com:3344/config/dev/master |
重要配置细节总结
1 | /{name}-{profiles}.yml |
成功实现了用 SpringCloud Config 通过 GitHub 获取配置信息
Config客户端配置与测试
1. 新建 cloud-config-client-3355 项目
2. cloud-config-client-3355 项目 pom.xml 文件
1 | <?xml version="1.0" encoding="UTF-8"?> |
3. cloud-config-client-3355 项目 bootstrap.yml
applicaiton.yml 是用户级的资源配置项
bootstrap.yml 是系统级的,优先级更加高
Spring Cloud 会创建一个 Bootstrap Context,作为 Spring 应用的 Application Context 的父上下文。
初始化的时候,BootstrapContext 负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的 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。
1 | server: |
4. 修改 config-dev.yml 配置并提交到 GitHub 中,比如加个变量 age 或者版本号 version
5. cloud-config-client-3355 项目 主启动
1 | import org.springframework.boot.SpringApplication; |
6. cloud-config-client-3355 项目 业务类
1 | package com.sevattal.springboot.controller; |
7. 测试
启动 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
成功实现了客户端3355访问SpringCloud Config3344通过GitHub获取配置信息可题随时而来
分布式配置的动态刷新问题
Linux 运维修改 GitHub 上的配置文件内容做调整
刷新 3344,发现 ConfigServer 配置中心立刻响应
刷新 3355,发现 ConfigClient 客户端没有任何响应
3355 没有变化除非自己重启或者重新加载
难到每次运维修改配置文件,客户端都需要重启??噩梦
Config 动态刷新之手动版
避免每次更新配置都要重启客户端微服务 3355
动态刷新步骤:
修改 3355 模块
1. POM引入actuator监控
1 | <dependency> |
2. 修改 YML,添加暴露监控端口配置:
1 | # 暴露监控端点 |
3. @RefreshScope 业务类 Controller 修改
1 | import org.springframework.cloud.context.config.annotation.RefreshScope; |
4. 测试
此时修改 github 配置文件内容 -> 访问 3344 -> 访问 3355
1 | http://localhost:3355/configInfo |
3355 改变没有 ??? 没有,还需一步
How
需要运维人员发送Post请求刷新3355
1 | curl -X POST "http://localhost:3355/actuator/refresh" |
再次测试
1 | http://localhost:3355/configInfo |
3355 改变没有 ??? 改了。
成功实现了客户端 3355 刷新到最新配置内容,避免了服务重启
想想还有什么问题?
假如有多个微服务客户端 3355/3366/3377
每个微服务都要执行—次 post 请求,手动刷新?
可否广播,一次通知,处处生效?
我们想大范围的自动刷新,求方法