【SpringCloud笔记】（9）分布式配置中心之Config
Config
概述
分布式系统当前面临的配置问题
微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。
比如：有n个微服务连接同一套数据库，当连接数据库需要发生变动时，需要改n多次
比如：每一个微服务都有dev，prd环境
…
每一个微服务自己带着一个application.yml，上百个配置文件的管理…/(T o T)/~~
由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的，SpringCloud提供了ConfigServer来解决这个问题
当前主流使用的配置中心有三种
- config+bus
- alibaba nacos
- 携程 阿波罗
Config是什么？
一句话：统一共用的配置放在配置中心，各自独立的配置各自保存
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
SpringCloud Config分为服务端和客户端两部分。
服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口
客户端（也就是我们的微服务模块）则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容
Config能干嘛？
- 集中管理配置文件
- 不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release
- 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
- 当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置
- 将配置信息以REST接口的形式暴露
config服务端配置与测试
git参考文档： https://blog.csdn.net/qq_44722674/article/details/117200397
https://lolitasian.blog.csdn.net/article/details/79085301
在GitHub上新建一个仓库：springcloud-config
获得刚才新建的git地址：[email protected]:mazhuorui/springcloud-config.git
在本地硬盘目录新建git仓库 比如我新建目录：D:\app\appFile\gitRepository，在该目录下执行以下命令
注意上面的操作不是必须的，只要github上有就可以，克隆到本地只是为了方便修改
新建Module模块cloud-config-center-3344
它即为Cloud的配置中心模块cloudConfig Center
pom文件
<artifactId>cloud-config-center-3344artifactId>
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-config-serverartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
<dependency>
<groupId>com.mzr.springcloudgroupId>
<artifactId>cloud-api-commonsartifactId>
<version>1.0-SNAPSHOTversion>
dependency>
dependencies>
yml文件
server:
port: 3344
spring:
application:
name: cloud-config-center #注册进Eureka服务器的微服务名
cloud:
config:
server:
git:
uri: [email protected]:mazhuorui/springcloud_config.git #GitHub上面的git仓库名字
####搜索目录
search-paths:
- springcloud_config
####读取分支
label: master
#服务注册到eureka地址
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
主启动类
@SpringBootApplication
@EnableConfigServer //加上该注解
@EnableEurekaClient
public class ConfigCenterMain3344
{
public static void main(String[] args) {
SpringApplication.run(ConfigCenterMain3344.class, args);
}
}
windows下修改hosts文件，增加映射127.0.0.1 config-3344.com
启动微服务3344（先启动7001）
测试通过Config微服务是否可以从GitHub上获取配置内容
http://config-3344com:3344/master/config-dev.yml
配置读取规则
/{label}-{nalrne}-{profiles}.yml
- label:分支(branch)
- name :服务名
- profiles:环境(dev/test/prod)
建议使用第一种
不加分支名{label}默认是master分支
前两种返回的时yml内容，第三种返回的是json串
config客户端配置与测试
新建cloud-config-client-3355模块
pom文件
<artifactId>cloud-config-client-3355artifactId>
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-configartifactId>//
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
dependencies>
applicaiton. yml是用户级的资源配置项 bootstrap. yml是系统级的，优先级更加高
Spring Cloud会创建一个“Bootstrap Context”，作为Spring应用的Application Context的父上下文。
初始化的时候，BootstrapContext负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment。Bootstrap属性有高优先级，默认情况下，它们不会被本地配置覆盖。
Bootstrap context和Application Context有着不同的约定，所以新增了一个bootstrap.yml文件，保证Bootstrap Context和Application Context配置的分离。
一般会有bootstrap.yml、application.yml两个文件，bootstrap.yml从外部获取共有的配置，application.yml负责微服务独有的配置，两个配置文件才能组合成一个完整的配置环境
本次只使用一个bootstrap.yml文件
server:
port: 3355
spring:
application:
name: config-client
cloud:
#Config客户端配置
config:
label: master #分支名称
name: config #配置文件名称
profile: dev #读取后缀名称 上述3个综合：master分支上config-dev.yml的配置文件被读取，读取路径http://config-3344.com:3344/master/config-dev.yml
uri: http://localhost:3344 #配置中心地址k
#服务注册到eureka地址
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
主启动类
@SpringBootApplication
@EnableEurekaClient
public class ConfigClientMain3355{
public static void main(String[] args) {
SpringApplication.run(ConfigClientMain3355.class, args);
}
}
controller层
@RestController
public class ConfigClientController {
//将配置文件中config.info内容注入到configInfo变量中
@Value("${config.info}")
private String configInfo;
@GetMapping("/configInfo")
public String getConfigInfo(){
return configInfo;
}
}
启动测试
可以发现3344和3355访问的内容是一致的
成功实现了客户端3355通过访问SpringCloud Config3344获取到GitHub上的配置信息
动态刷新
问题：如果我们修改了GitHub上配置文件内容，3344、3355还能获取到新的内容吗？
- Linux运维修改GitHub上的配置文件内容做调整：比如修改config-dev.yml提交
- 刷新3344，发现ConfigServer服务端配置中心立刻响应，得到最新值了
- 刷新3355，发现ConfigClient客户端没有任何响应，拿到的还是旧值
- 客户端3355没有变化除非自己重启或者重新加载，才能拿到最新值
- 难到每次运维修改配置文件，客户端都需要重启？？噩梦
解决动态刷新问题
修改3355模块
POM引入actuator
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
监控修改YML，暴露监控端口
server:
port: 3355
spring:
application:
name: config-client
cloud:
#Config客户端配置
config:
label: master #分支名称
name: config #配置文件名称
profile: dev #读取后缀名称 上述3个综合：master分支上config-dev.yml的配置文件被读取，读取路径http://config-3344.com:3344/master/config-dev.yml
uri: http://localhost:3344 #配置中心地址k
#服务注册到eureka地址
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
#暴露监控端点
management:
endpoints:
web:
exposure:
include: "*"
@RefreshScope业务类Controller修改
@RestController
@RefreshScope//自动刷新注解
public class ConfigClientController
{
@Value("${config.info}")
private String configInfo;
@GetMapping("/configInfo")
public String getConfigInfo()
{
return configInfo;
}
}
此时，我们客户端的配置已经完成了，我们再去刷新3355访问3355发现拿到的依然时旧值？！
最后一步操作：向客户端发送post请求刷新3355，相当于告诉3355GitHub内容已更新
curl -X POST “http://localhost:3355/actuator/refresh”
两个必须：1.必须是 POST 请求，2.请求地址：http://localhost:3355/actuator/refresh
假如有多个微服务客户端3355/3366/3377…
每个微服务都要执行一次post请求，手动刷新?
可否广播，一次通知，处处生效？我们想大范围的自动刷新，并且还能够定点通知、精确通知，比如100台
中我要剔除2台通知其他98台，求方法~
如果我说消息总线Bus可以呢？