SpringCloud Config分布式配置中心
SpringCloud Config是什么?
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
为什么要使用config?
微服务意味着要将单体应用中的业务拆分成一个个子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行,所以一套集中式的、动态的配置管理设施是必不可少的。
SpringCloud提供了ConfigServer来解决这个问题,我们每一个微服务自己带着一个application.yml,上百个配置文件的管理
怎么使用?
SpringCloud Config分为服务端
和客户端
两部分。
服务端也称为分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密/解密信息等访问接口
客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容。
使用config会带来什么优势?
- 集中管理配置文件
- 不同环境不同配置,动态化的配置更新,分环境部署比如dev/test/prod/beta/release
- 运行期间动态调整配置,不再需要在每个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置自己的信息
- 当配置发生变动时,服务不需要重启即可感知到配置的变化并应用新的配置
- 将配置信息以REST接口的形式暴露(可以通过post、curl访问刷新均可)
与Gitee(码云)整合配置
由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持SVN和本地文件),
但最推荐的还是Git,而且使用的是http/https访问的形式
因为我的网络比较差所以使用github比较慢,之后我就换gitee,其实都一样,网速可以用github
简单的示例
【Config服务端配置与测试】
1.用自己的GitHub账号在GitHub/gitee上新建一个名为microservicecloud-config
的新Repository
2.将gitee仓库clone 下来 到本地命令:git clone 仓库链接
3.在仓库中添加几个application-{}.yml文件
4.新建microservicecloud-config-3344 它即为Cloud的配置中心模块
【pom中引入】
<!-- springCloud Config -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<!-- 避免Config的Git插件报错:org/eclipse/jgit/api/TransportConfigCallback -->
<dependency>
<groupId>org.eclipse.jgit</groupId>
<artifactId>org.eclipse.jgit</artifactId>
<version>4.10.0.201712302008-r</version>
</dependency>
【yml中配置】
server:
port: 3344
spring:
application:
name: microservicecloud-config
cloud:
config:
server:
git:
uri: https://gitee.com/hzx456_admin/springcloud-config.git #GitHub/gitee 上面的git仓库名字
#Eureka配置
eureka:
client:
service-url:
defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka
主启动类上加上@EnableConfigServer
配置完了之后就测试https://localhost:3344/application-dev.yml
但是这样子只是作为配置中心的,所以我们还要配置客户端的
5.新建microservicecloud-config-client-3355 Config客户端
【pom】
<!-- SpringCloud Config客户端 和配置中心不同的地方就是少了一个-serve---“spring-cloud-config-server”-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
【yml】
这里要创建一个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
配置的分离。
spring:
application:
name: microservicecloud-config-client
#通过name,profile , label 来精确的找到gitee/github上的配置文件
spring:
cloud:
config:
name: microservicecloud-config-client #需要从github上读取的资源名称,注意没有yml后缀名
profile: dev #本次访问的配置项
label: master #分支名
uri: http://localhost:3344 #本微服务启动后先去找3344号服务,通过SpringCloudConfig获取GitHub的服务地址
找到的文件会和bootstrap合并起来,组成最终的配置
【controller】
/**
*直接输入gitee中的信息
*/
@RestController
@RefreshScope
public class ConfigClientController {
@Value("${config.info}")
private String configInfo;
@GetMapping("/configInfo")
public String getConfigInfo(){
return configInfo;
}
}
【测试】
访问:https/localhost:3355/configInfo
正常没有问题,这时候我们去修改gitee中 的配置,然后再访问https/localhost:3355/configInfo然后发现没有马上发生改变,
解决这个问题:
方式一:通过重启服务,但是实际开发中特别浪费时间所以不行
方式二:通过post请求http://localhost:3355/actuator/refresh来刷新,也就是手动来刷新,可以不用重启服务
虽然这个解决了修改了文件要重启服务的难题,但是不但需要手动,要是客户端多的话特别麻烦,这个就要需要配置SpringCloud Bus 来解决这个问题
Q.E.D.
Comments | 1 条评论