SpringCloud Config分布式配置中心
SpringCloud
微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。
SpringCloud提供了ConfigServer来解决这个问题,我们每一个微服务自己带着一个application.yml,上百个配置文件的管理…/(ㄒoㄒ)/~~
简介
官网:https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
SpringCloud Config分为服务端和客户端两部分。
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口
客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容。
作用:
- 集中管理配置文件
- 运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息
- 当配置发生变动时,服务不需要重启即可感知到配置的变化并应用新的配置
- 将配置信息以REST接口的形式暴露,post、curl访问刷新均可…
由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持SVN和本地文件),但最推荐的还是Git,而且使用的是http/https访问的形式。
服务端配置与测试
创建
远程配置中心是在github上面
新建配置中心微服务
依赖配置
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
application.yml:
server:
port: 3344
spring:
application:
name: cloud-config-center
cloud:
config:
server:
git:
uri: https://github.com/wzq-55552/springcloud-config.git #配置远程的仓库地址springcloud-config
search-paths:
- springcloud-config
label: master #进到仓库的主分支
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
启动类:
/**
* @author zzyy
*/
@SpringBootApplication
@EnableConfigServer
public class ConfigCenterMain3344 {
public static void main(String[] args) {
SpringApplication.run(ConfigCenterMain3344.class, args);
}
}
测试
配置中心读取github配置以REST方式暴露出来
读取方式很多:
一个一个文件也行,一个yml文件包含多个环境也行,通过profiles区分。
github创建:
如果有其他分支,都可以访问,直接url上把master改成其他分支
访问github上面的文件:http://localhost:3344/master/application.yml
http://localhost:3344/application.yml效果一样,不加分支默认配置中的分支,为master
读取github上面application.yml文件中的不同环境内容
dev环境的值:http://localhost:3344/application/dev/master
test环境的值:http://localhost:3344/application/test/master
客户端配置与测试
创建
依赖配置
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
两种模式:根据具体场景
**一、**github上文件是config(application)-dev.yml、config(application)-test.yml、config(application)-prod.yml多个环境文件细分的,如下配置:
http://localhost.com:3344/master/config-dev.yml
http://localhost.com:3344/master/application-dev.yml
bootstrap.yml(该配置是与配置中心互通的,读取公有配置),applicaiton.yml是该微服务独有,特有的配置。该微服务需要2个配置文件。
server:
port: 3355
spring:
application:
name: config-client
cloud:
config:
label: master # 分支名称
name: config # 配置文件名称,可自定义,最好application/config
profile: dev # 读取的后缀,上述三个综合,为master分支上的config-dev.yml的配置文件被读取,http://localhost.com:3344/master/config-dev.yml
uri: http://localhost:3344 #配置中心的地址
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
- 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
配置的分离。
**二、**github上文件是一个application.yml,比如:
http://localhost:3344/application/dev/master
github配置内容
spring:
profiles:
active:
- dev
---
spring:
profiles: dev #开发环境
application:
name: microservicecloud-config-atguigu-dev
---
spring:
profiles: test #测试环境
application:
name: microservicecloud-config-atguigu-test
# 请保存为UTF-8格式
如下配置:
bootstrap.yml(该配置是与配置中心互通的,公有配置),applicaiton.yml是该微服务独有,特有的配置。
server:
port: 3355
spring:
#application:
# name: config-client
cloud:
config:
label: master # 分支名称
name: application # 配置文件名称,可自定义,最好application/config
profile: dev # 文件中的dev profile内容,上述三个综合,为master分支上的application.yml的配置文件中的dev内容被读取http://localhost:3344/application/dev/master
uri: http://localhost:3344 #配置中心的地址
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
测试
这里测试,我采用第二种方式,都一样。
首先,我们客户端微服务是没有配置application.name的,但是却可以注册到服务注册中心,因为优先加载bootstrap.yml配置文件,读取到了github上的配置,这里测试例子的github配置有实例名。
controller测试读取配置中心的配置
@RestController
//@RefreshScope
public class ConfigClientController {
@Value("${spring.application.name}")
private String applicationName;
@GetMapping("/applicationName")
public String getApplicationName(){
return applicationName;
}
}
配置中心的配置读取,github上的:
客户端读取:
客户端动态刷新配置
问题:
linux运维修改Github上的配置文件内容
刷新3344,发现ConfigServer配置中心立刻响应
刷新3355,发现ConfigClient客户端的没有任何响应
3355没有变化除非自己重启或者重新加载,实际生产各种微服务都要重启?
为了避免每次更新配置都要重启客户端微服务3355,还需要完善配置中心
加上监控的依赖,服务端和客户端都加。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
客户端完整bootstrap.yml配置
server:
port: 3355
spring:
# application:
# name: config-client
cloud:
config:
label: master # 分支名称
name: application # 配置文件名称,可自定义,最好application/config
profile: dev # 文件中的dev profile内容,上述三个综合,为master分支上的application.yml的配置文件中的dev内容被读取http://localhost:3344/application/dev/master
uri: http://localhost:3344 #配置中心的地址
eureka:
client:
service-url:
defaultZone: http://localhost:7001/eureka
#暴露监控端口
management:
endpoints:
web:
exposure:
include: "*"
controller上加上刷新注解@RefreshScope
运维人员得执行请求curl -X “http://localhost:3355/actuator/refresh”
必须是POST请求
这样就实现了客户端3355刷新到最新配置内容
每个微服务都要执行一次post请求,手动刷新?
这样也会很麻烦,微服务多了工作量太大,但是结合消息总线可以实现一次通知,处处生效。