文章大纲
一、分布式配置中心是什么
二、配置基本实现
三、Spring Cloud Config服务端配置细节(一)
四、Spring Cloud Config服务端配置细节(二)
五、Spring Cloud Config客户端配置细节
六、项目源码与参考资料下载
七、参考文章
一、分布式配置中心是什么
随着我们的分布式项目越来越大,我们可能需要将配置文件抽取出来单独管理,Spring Cloud Config对这种需求提供了支持。Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。我们可以使用Config Server在所有环境中管理应用程序的外部属性,Config Server也称为分布式配置中心,本质上它就是一个独立的微服务应用,用来连接配置仓库并将获取到的配置信息提供给客户端使用;客户端就是我们的各个微服务应用,我们在客户端上指定配置中心的位置,客户端在启动的时候就会自动去从配置中心获取和加载配置信息。Spring Cloud Config可以与任何语言运行的应用程序一起使用。服务器存储后端的默认实现使用git,因此它轻松支持配置信息的版本管理,当然我们也可以使用Git客户端工具来管理配置信息。本文我们就先来看下Spring Cloud Config的一个基本使用。
二、配置基本实现
1. 构建配置中心
首先我们来构建一个配置中心,方式很简单,创建一个普通的Spring Boot项目,叫做config-server,创建好之后,添加如下依赖:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.7.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<properties>
<spring-cloud.version>Dalston.SR3</spring-cloud.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
然后在入口类上添加@EnableConfigServer注解,表示开启配置中心服务端功能,如下:
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
然后在application.properties中配置一下git仓库的信息,为了简单,我这里就不自己搭建git服务端了,直接使用GitHub(当然也可以使用码云),这里需要我首先在我的Github上创建一个名为scConfig的项目,创建好之后,再做如下配置:
spring.application.name=config-server
server.port=2007
spring.cloud.config.server.git.uri=https://github.com/lenve/scConfig.git
spring.cloud.config.server.git.search-paths=config-repo
spring.cloud.config.server.git.username=username
spring.cloud.config.server.git.password=password
前两行配置的含义就不用我多说了,我说下后面四行配置的含义,如下:
(1)uri表示配置中心所在仓库的位置
(2)search-paths表示仓库下的子目录
(3)username表示你的GitHub用户名
(4)password表示你的GitHub密码
做好这些之后我们的配置中心服务端就创建好了。
2. 构建配置仓库
接下来我们需要在github上设置好配置中心,首先我在本地找一个空文件夹,在该文件夹中创建一个文件夹叫config-repo,然后在config-repo中创建四个配置文件,如下:
四个文件中的内容分别如下:
OK,然后回到test目录下,依次执行如下命令将本地文件同步到Github仓库中,如下:
如此之后,我们的配置文件就上传到GitHub上了。此时启动我们的配置中心,通过/{application}/{profile}/{label}就能访问到我们的配置文件了,其中application表示配置文件的名字,对应我们上面的配置文件就是app,profile表示环境,我们有dev、test、prod还有默认,label表示分支,默认我们都是放在master分支上,我们在浏览器上访问结果如下:
OK,从这里我们看到了我们放在仓库中的配置文件。JSON中的name表示配置文件名application的部分,profiles表示环境部分,label表示分支,多了一个version,实际上就是我们GitHub上提交信息时产生的版本号,当我们访问成功后,我们还可以看到控制台打印了如下日志:
实际上是配置中心通过git clone命令将配置文件在本地保存了一份,这样可以确保在git仓库挂掉的时候我们的应用还可以继续运行,此时我们断掉网络,再访问http://localhost:2007/app/prod/master,一样还可以拿到数据,此时的数据就是从本地获取的。
3. 客户端配置
服务端搞好了,接下来我们来看看怎么样在客户端使用。
首先创建一个普通的Spring Boot工程config-client,创建成功之后添加如下依赖:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.7.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<properties>
<spring-cloud.version>Dalston.SR3</spring-cloud.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
然后创建bootstrap.properties文件,来获取配置信息,注意这些信息一定要放在bootstrap.properties文件中才有效,文件内容如下:
spring.application.name=app
spring.cloud.config.profile=dev
spring.cloud.config.label=master
spring.cloud.config.uri=http://localhost:2007/
server.port=2008
这里的name对应了配置文件中的application部分,profile对应了profile部分,label对应了label部分,uri则表示配置中心的地址。配置完成之后创建一个测试Controller,我们来看看效果:
@RestController
@RefreshScope
public class HelloController {
@Value("${sang}")
String sang;
@Autowired
Environment env;
@RequestMapping("/sang")
public String sang() {
return this.sang;
}
@RequestMapping("/sang2")
public String sang2() {
return env.getProperty("sang", "未定义");
}
}
我们可以直接注入值,也可以通过Environment来获取值,访问结果如下:
三、Spring Cloud Config服务端配置细节(一)
我们先通过下面一张图来看看Config Server的一个大致工作过程:
说明
1.首先我们需要一个远程的Git仓库,自己学习可以直接用GitHub,在在实际生产环境中,需要自己搭建一个Git服务器,远程Git仓库的作用主要是用来保存我们的配置文件
2.除了远程Git仓库之外,我们还需要一个本地Git仓库,每当Config Server访问远程Git仓库时,都会保存一份到本地,这样当远程仓库无法连接时,就直接使用本地存储的配置信息
3.至于微服务A、微服务B则是我们具体的应用,这些应用在启动的时候会从Config Server中来加载相应的配置信息
4.当微服务A/B尝试去从Config Server中加载配置信息的时候,Config Server会先通过git clone命令克隆一份配置文件保存到本地
5.由于配置文件是存储在Git仓库中,所以配置文件天然的具备版本管理功能,Git中的Hook功能可以实时监控配置文件的修改
Git URI中的占位符
灵活的使用URI占位符,可以有效的减少我们的工作量。考虑这样一个问题,我有ServerA、ServerB两个服务,两个服务对应的配置文件的存储地址分别位于https://github.com/lenve/scConfig/sa和https://github.com/lenve/scConfig/sb,但是我的Config Server只有一个,那么当我的ServerA和ServerB连接上Config Server时,Config Server怎么知道去哪个地址下拿配置文件?这个时候就涉及到占位符的使用。
在上篇文章中我们已经了解了Spring Cloud Config中的三种占位符,分别是{application}、{profile}和{label},这些占位符除了用来标识配置文件的规则,还可以用在Config Server中对Git仓库的URI配置,用在URI配置中时,这三个占位符的含义分别如下所示:
1.{application}映射到客户端的 spring.application.name
2.{profile}映射到客户端上的 spring.profiles.active
3.{label}这是一个服务器端功能,标记”版本”的配置文件集
此时,假设我不同环境下的配置文件分别放在下面这些目录下:
https://github.com/lenve/scConfig/app/dev
https://github.com/lenve/scConfig/app/prod
https://github.com/lenve/scConfig/app/test
那么我的客户端文件这样配置:
spring.application.name=app
# dev根据具体情况来修改
spring.cloud.config.profile=dev
spring.cloud.config.label=master
spring.cloud.config.uri=http://localhost:2007/
server.port=2008
然后Config Server按下面这种方式配置即可:
spring.cloud.config.server.git.uri=https://github.com/lenve/scConfig.git
spring.cloud.config.server.git.search-paths={application}/{profile}
当然这种存储规划不一定最佳,这里只是给小伙伴们演示占位符的用法。
默认情况下,Config Server 克隆下来的文件保存在C:Users<当前用户>AppDataLocalTemp目录下,我们可以通过如下配置来修改:
spring.cloud.config.server.git.basedir=E:\111\
健康监测
默认情况下Spring Cloud Config会为配置中心服务端创建一个健康监测器,该检测器默认情况下是访问的仓库文件是{application}为app的配置文件,如果仓库中不存在这个文件,健康显示器就会显示仓库无法连接,此时我们有两种解决方案:1.仓库中添加相应的配置文件;2.重新指定检测的配置,重新指定方式如下:
spring.cloud.config.server.health.repositories.check.name=app
spring.cloud.config.server.health.repositories.check.label=master
spring.cloud.config.server.health.repositories.check.profiles=dev
此时,系统回去访问http://localhost:2007/app/dev/master地址,如果能够访问到,则显示仓库已连接,如下:
安全保护
开发环境中我们的配置中心肯定是不能随随便便被人访问的,我们可以加上适当的保护机制,由于微服务是构建在Spring Boot之上,所以整合Spring Security是最方便的方式。
首先添加依赖:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
然后在application.properties中配置用户名密码:
security.user.name=sang
security.user.password=123
最后在配置中心的客户端上配置用户名和密码即可,如下:
spring.cloud.config.username=sang
spring.cloud.config.password=123
四、Spring Cloud Config服务端配置细节(二)
1. 简介
在微服务架构中,由于独立的服务个数众多,加上前期测试工作量大,一些原本由运维人员维护的敏感信息会被我们直接写在微服务中,以提高开发效率,但是这种明文存储方式显然是非常危险的,所以我们要对这些信息进行加密,而Spring Cloud Config则提供了对称加解密、非对称加解密的功能来帮助我们完成这一需求。OK,本文我们就来看看如何实现配置信息的加解密。
2. 准备工作
默认情况下我们的JRE中自带了JCE(Java Cryptography Extension),但是默认是一个有限长度的版本,我们这里需要一个不限长度的JCE,这个JCE我们可以直接百度然后在Oracle官网下载,下载之后解压,我们可以看到如下三个文件:
我们需要将这里的两个jar包拷贝到我们的jdk安装目录下,我的是%JAVA_HOME%jrelibsecurity
,覆盖该目录下原有的文件。
如此之后,我们的准备工作就完成了。
3. 对称加解密
对称加解密比较简单,直接配置密钥就可以了,在我们前文创建出来的config-server中配置密钥,但是注意这个密钥需要配置在bootstrap.properties中,另外这里还有非常重要一点:Spring Cloud的Dalston.SR3和Dalston.SR2版本在这个问题上是有BUG的,如果用这两个版本在这里测试会没有效果,应该避开使用这两个版本,我这里使用的是Dalston.SR4版本,配置如下:
encrypt.key=sang
配置完成之后,启动我们的config-server工程,然后访问如下地址http://localhost:2007/encrypt/status,如果看到如下访问结果,表示环境搭建成功了:
此时我们就可以通过第三方工具如POSTMAN、RestClient等来访问/encrypt和/decrypt接口,比如说我要给dev这个字符加密,方式如下(我这里以POSTMAN为例,注意是POST请求):
解密方式如下:
OK,拿到加密的字符串之后,我们就可以在配置文件中使用了,还是我们昨天的配置文件,这次我这样来写:
小伙伴们注意,配置文件的值如果是以{cipher}
开头,表示该值是一个加密字符,配置中心config-server在获取到这个值之后会先对值进行解密,解密之后才会返回给客户端使用。
4. 非对称加解密
上文我们使用了对称加解密的方式来确保配置文件的安全性,如果使用非对称加解密的方式,我们的安全性将会得到进一步的提高。使用非对称加密的话需要我们先生成密钥对,生成密钥对可以直接使用jdk中自带的keytool工具,方式如下:
keytool -genkeypair -alias config-server -keyalg RSA -keystore config-server.keystore
执行效果如图:
执行成功之后,会在命令执行目录下生成一个名为config-server.keystore的文件,将该文件拷贝到config-server的srcmain esources目录下,然后做如下配置:
encrypt.key-store.location=config-server.keystore
encrypt.key-store.alias=config-server
encrypt.key-store.password=111111
encrypt.key-store.secret=111111
OK,如此之后我们的非对称加密就配置好了,测试方式和对称加密的测试方式一致,我这里就不再演示了。
五、Spring Cloud Config客户端配置细节
服务化配置中心
在前面几篇关于Spring Cloud Config配置中心的文章中,我们在config-client中配置config-server地址的时候都是直接将地址写死,这种方式显然不够灵活,有的小伙伴可能已经想到了,这里我们可以结合eureka注册中心,然后在配置的时候直接使用服务名即可,OK,那我们对之前的项目稍加改造吧。
config-server改造
这里的改造都是非常简单的,服务端改造和客户端改造都是分三步走:1.添加依赖;2.添加注解;3.修改application.properties.
首先我们在config-server中添加如下依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
然后在config-server的入口类上添加@EnableDiscoveryClient注解,表示这是一个Eureka客户端,如下:
@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
最后在application.properties中配置eureka注册中心地址:
eureka.client.service-url.defaultZone=http://localhost:1111/eureka/
至此,我们的config-server就配置成功了。
config-client改造
config-client改造第一步也是先添加依赖,如下:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
然后入口类添加@EnableDiscoveryClient注解,如下:
@SpringBootApplication
@EnableDiscoveryClient
public class ConfigClientApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigClientApplication.class, args);
}
}
最后修改配置文件,如下:
spring.application.name=app
# dev根据具体情况来修改
spring.cloud.config.profile=dev
spring.cloud.config.label=master
eureka.client.service-url.defaultZone=http://localhost:1111/eureka/
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.service-id=config-server
server.port=2008
关于这个配置文件我说如下三点:
1.eureka.client.service-url.defaultZone设置了注册中心的地址,将config-client注册到eureka注册中心中去
2.spring.cloud.config.discovery.enabled表示开启通过服务名来访问config-server
3.spring.cloud.config.discovery.service-id=config-server则表示config-server的服务名
测试
OK,经过以上的改造之后,此时我们分别启动eureka服务注册中心、config-server、config-client,然后访问http://localhost:1111,可以看到两个应用都已经注册成功了:
然后继续测试config-client的/sang接口,结果如下:
没问题。
好了,服务化配置中心构建成功。
失败快速响应
不作任何额外配置的情况下,失败响应有点迟钝,举个简单的例子,关掉config-server,我们直接启动config-client,此时启动会报错,但是报错时间较晚,报错的时候系统已经打印了许多启动日志了,如果我们希望在启动失败时能够快速响应,方式很简单,config-client中添加如下配置即可:
spring.cloud.config.fail-fast=true
此时不启动config-server直接启动config-client依然会报错,但是我们看到报错时间较早,系统都没打印几条启动日志。
重试机制
如果由于网络抖动等原因导致config-client在启动时候访问config-server没有访问成功从而报错,这显然是不划算的,遇到这种情况我们希望config-client最好能重试几次,重试机制在这里也是受支持的,添加重试机制的方式很简单,引入如下两个依赖:
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>
引入依赖就OK了,不用做任何额外配置(当然要确保失败快速响应已开启),此时我们再尝试不启动config-server直接启动config-client,得到的启动日志如下:
我们看到,config-client一共尝试了六次去访问config-server,六次都失败了才抛异常。
和重试机制相关的配置有如下四个:
# 配置重试次数,默认为6
spring.cloud.config.retry.max-attempts=6
# 间隔乘数,默认1.1
spring.cloud.config.retry.multiplier=1.1
# 初始重试间隔时间,默认1000ms
spring.cloud.config.retry.initial-interval=1000
# 最大间隔时间,默认2000ms
spring.cloud.config.retry.max-interval=2000
动态刷新配置
有的时候,我动态的更新了Git仓库中的配置文件,那么我如何让我的config-client能够及时感知到呢?方式很简单,首先在config-client中添加如下依赖:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
该依赖中包含了/refresh端点的实现,我们将利用这个端点来刷新配置信息。然后需要在application.properties中配置忽略权限拦截:
management.security.enabled=false
OK,配置好之后,启动eureka注册中心,config-server和config-client,访问http://localhost:2008/sang,结果如下:
此时我利用Git客户端工具,将app-dev.properties中的内容修改一下,修改成功之后,先用POST请求访问http://localhost:2008/refresh地址,结果如下:
然后再访问http://localhost:2008/sang,结果如下:
我们看到配置文件已经更新了。
六、项目源码与参考资料下载
链接:https://pan.baidu.com/s/1WgA85ExFsQQlU7Ek1Rvf6w
提取码:p7qn