Spring Cloud（十四）Config 配置中心与客户端的使用与详细

前言

在上一篇 文章 中我们直接用了本应在本文中配置的Config Server，对Config也有了一个基本的认识，即

Spring Cloud Config 是一种用来动态获取Git、SVN、本地的配置文件的一种工具

在上文中我们使用Config用来实现 动态路由 的功能，就是使用的Git的方式

快速入门

1. Config Server 的搭建

新建一个模块名为

ConfigServer

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>com.cnblogs.hellxz</groupId>
<artifactId>ConfigServer</artifactId>
<version>1.0-SNAPSHOT</version>

<parent>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-parent</artifactId>
<version>Dalston.SR5</version>
<relativePath/>
</parent>

<dependencies>
<!--Spring Cloud Config 服务端依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
</project>

配置文件没什么好说的，其中因为我们不需要将这个项目注册到 注册中心 ，所以我们只需添加Config Server的依赖

spring-cloud-starter-config-server

spring-cloud-config-server

在java目录下添加主类ConfigServerApp

import org.springframework.boot.SpringApplication;
import org.springframework.boot.SpringBootConfiguration;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.cloud.config.server.EnableConfigServer;

/**
* 这里没有使用SpringBootApplication或SpringCloudApplication注解，会报错
* 原因也很简单，我们的java源码目录下没有目录，我们手动加一个也就正常了，
* 为了写点体会和这里没必要用到包和类，所以使用这种方式
*/
@EnableConfigServer
@SpringBootConfiguration
@EnableAutoConfiguration
public class ConfigServerApp {

public static void main(String[] args) {
SpringApplication.run(ConfigServerApp.class, args);
}
}

@EnableConfigServer

在resources下添加一个

bootstrap.yml

server:
port: 7001

spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://github.com/hellxz/SpringCloudlearn
search-paths: config-repo
username: username  #账号密码写真实的快一些我觉得，不使用也能访问有点慢
password: password

其中

spring.cloud.config.server.git.uri

search-paths指定的是匹配查询的路径名

username和password是访问仓库的用户名和密码，写自己的好象快一些，还有用码云也会快一些，因为网络长城

现在项目就配置好了，我们需要提供配置文件了，我们在SpringCloudLean下创建一个普通目录

config-repo

hellxztest.yml

from: default-environment-1.0

hellxztest-dev.yml

from: dev-environment-1.0

hellxztest-prod.yml

from: prod-environment-1.0

hellxztest-stable.yml

from: stable-environment-1.0

dynamic-route-zuul.yml

zuul:
routes:
service-provider:
path: /service/**
serviceId: eureka-service

前三个是普通的测试文件，最后一个是上一篇文章中做动态路由实验中用到的文件

这个文件的目录也可以创建一个其它的项目提到git上

将config-repo提交到github上，或者你自己的码云、gitlab等均可，修改之前的uri进行测试.

测试

只需启动ConfigServer项目即可。

使用postman进行测试

其它也是一样的，我们试一下动态路由的配置

测试默认的配置文件

接下来讲讲这些url为什么是这样的

配置规则详解

还记得最开始我们建的那几个测试文件的命名规则么？

• hellxztest.yml
• hellxztest-dev.yml
• hellxztest-stable.yml
• hellxztest-prod.yml

这里的application可以自定义为其它的名称，这里可以用应用的名称，即

应用名

环境名

Config支持我们使用的请求的参数规则为：

• / { 应用名 } / { 环境名 } [ / { 分支名 } ]
• / { 应用名 } - { 环境名 }.yml
• / { 应用名 } - { 环境名 }.properties
• / { 分支名 } / { 应用名 } - { 环境名 }.yml
• / { 分支名 } / { 应用名 } - { 环境名 }.properties

此时我们查看ConfigServer的终端输出，我们很容易发现他的工作原理：

使用git clone 方式，将配置文件拉取到本地，将配置文件的信息传输给接收端

断网测试一下

测试正常，配置文件信息依旧被请求获取到了，该配置信息来自Config Server本地

客户端配置映射与动态刷新

1. 创建Config Client

为了更直观地测试客户端的配置，这里新建一个模块

ConfigClient

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>com.cnblogs.hellxz</groupId>
<artifactId>ConfigClient</artifactId>
<version>1.0-SNAPSHOT</version>

<parent>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-parent</artifactId>
<version>Dalston.SR5</version>
<relativePath/>
</parent>

<dependencies>
<!--Spring Cloud Config 客户端依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<!-- web的依赖，必须加 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!--Spring Boot Actuator，感应服务端变化-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
</dependencies>

</project>

创建名为

com.cnblogs.hellxz

ConfigClientApp

package com.cnblogs.hellxz;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class ConfigClientApp {

public static void main(String[] args) {
SpringApplication.run(ConfigClientApp.class, args);
}
}

在刚才的包下加一层controller的包，加一个用来展示服务端返回的from的值的TestController

package com.cnblogs.hellxz.controller;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import org.springframework.web.bind.annotation.RestController;

/**
* 当有请求/fresh节点的时候，会重新请求一次ConfigServer去拉取最新的配置文件
* 请求/fresh需要有几点要求：1.加actuator的依赖 2.SpringCloud1.5以上需要设置 management.security.enabled=false
* 这个Controller的作用是查看from这个key的值
*/
@RestController
@RefreshScope //开启更新功能
@RequestMapping("api")
public class TestController {

@Value("${from}")
private String fromValue;

/**
* 返回配置文件中的值
*/
@GetMapping("/from")
@ResponseBody
public String returnFormValue(){
return fromValue;
}
}

加

@RefreshScope

接下来在resources目录下创建bootstrap.yml

spring:
application:
name: hellxztest                     #指定了配置文件的应用名
cloud:
config:
uri: http://localhost:7001/        #Config server的uri
profile: dev                       #指定的环境
label: master                      #指定分支
server:
port: 7002
management:
security:
enabled: false     #SpringBoot 1.5.X 以上默认开通了安全认证，如果不关闭会要求权限

2. 测试

Config Server 和 Config Client 这两个都没有注册到Eureka注册中心，这里只需要启动这两个项目

我们看到Config Client项目在启动的时候请求一次Config Server

而且我们还在终端输出中看到了匹配的/refresh节点被Mapped了，请求的方法是Post

请求一下

http://localhost:7002/api/from

我们看到from现在对应的值是

dev-environment-1.0

hellxztest-dev.yml

1.0

2.0

http://localhost:7002/api/from

接下来测试一下/fresh接口，注意这里要用post方法进行访问

此时我们还需要调用一次

http://localhost:7002/api/from

可以看到from的值的确在Config Client中改变了，当中并没有重启Config Client，刷新配置功能测试通过。

@纯结的微笑

一般我们不能每次修改配置都手动刷新（post方法调用/refresh），可以与github之类的webhook进行配合，如果有修改就发起post请求/refresh就可以了，svn也有类似的hook机制，这里就不多讲了。

服务端详解

1. 基础架构

根据上边的结构图，我们可以看到几个必要的元素：

• 远程git仓库：用来存储配置文件的地方，多环境配置文件使用 hellxztest-{环境名}.yml
• Config Server：分布式配置中心，指定了

  git仓库uri

  、

  搜索路径

  、

  访问账号

  和

  密码

• 微服务应用：配置客户端（Config Client），指定

  应用名

  、

  配置中心url

  、

  环境名

  、

  分支名

  等

2. 启动流程：

1. 微服务应用启动，根据bootstrap.yml（properties）中配置的应用名（application）、环境名（profile）、分支名（label），向Config Server请求配置信息
2. Config Server 根据自己bootstrap.yml（properties）中的Git（或SVN）仓库信息加上客户端传来的配置定位信息去查配置信息的路径
3. Config Server 执行git clone命令，将配置信息下载到本地Git仓库中，将配置信息加载到Spring的ApplicationContext读取内容返回给客户端（微服务应用）
4. 客户端将内容加载到ApplicationContext，配置内容的优先级大于客户端内部的配置内容，进行忽略

3. Git配置仓库

本地仓库

Spring Cloud Config默认使用Git，对Git的配置也最简单，这里Config Server只用到了uri、username、password这三个参数就可以读取配置了，通过Git的版本控制可以使Config Server适应特殊的场景。

测试时我们也可以使用本地仓库的方式，使用

file://

spring:
cloud:
config:
server:
git:
uri: file://${user.home}/config-repo

占位符配置URI

｛application｝

｛profile｝

{label}

如：

spring.cloud.config.server.git.uri=https://github.com/hellxz/SpringCloudlearn/config-repo/{application}

spring.application.name

匹配并配置多个仓库

Spring Cloud Config Server除了使用

{应用名}/{环境名}

当有多个匹配规则的时候，可以用逗号分隔多个

{应用名}/{环境名}

以官方文档例子加减举例：

spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo   #默认的仓库
repos:
simple: https://github.com/simple/config-repo
special:
pattern: special*/dev*,*special*/dev*
uri: https://github.com/special/config-repo
local:
pattern: local*
uri: file:/home/configsvc/config-repo
test:
pattern:
- '*/development'
- '*/staging'
uri: https://github.com/development/config-repo

如果

{应用名}/{环境名}

上边的例子中，

• simple 仓库自动匹配到

  simple/*

• special 仓库的pattern，第一个是应用名以special开头，环境名以dev开头；第二个是应用名包含special，环境名以dev开头；多个匹配到同一uri的pattern用逗号分割
• local 仓库的的pattern也会自动补全为

  local*/*

• test仓库中的 pattern 是以通配符开始的，需要使用单引号

子目录存储

通过

spring.cloud.config.server.git.searchPaths

searchPaths参数的配置也支持使用{应用名}、{环境名}、{分支名}占位符

比如

spring.cloud.config.server.git.searchPaths={应用名}

举例：

spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
searchPaths: '{application}'

访问权限

使用Git仓库的时候，使用HTTP认证需要使用username和password属性来配置账户

举例

spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
username: trolley
password: strongpassword

4. SVN配置仓库

除了默认使用Git外，还可以使用SVN进行配置，如下：

在pom.xml中加入SVN的依赖配置，这里没写版本号，Spring Cloud中包含其版本号

<!--SVN-->
<dependency>
<groupId>org.tmatesoft.svnkit</groupId>
<artifactId>svnkit</artifactId>
</dependency>

在bootstrap.yml加入

spring:
cloud:
config:
server:
svn:
uri: http://192.168.0.1/svn/repo/config-repo
username: username
password: password
default-label: trunk
profiles:
active: subversion

和Git版本稍有区别，需要显示声明subversion，其他使用方法同Git

5. 本地仓库

使用版本控制方式将配置文件clone到本地，往往都是克隆到一些临时目录中，但是操作系统往往会清理这些临时目录，这可以导致一些我们不期待的情况，比如丢配置，为了避免出现这种问题，可以通过

spring.cloud.config.server.svn.basedir

6. 本地文件系统

不同于Git和SVN以及他们的本地仓库的存储方式，Spring Cloud Config 提供了本地文件系统的存储方式来保存配置信息，实现方式很简单，设置属性

spring.profiles.active=native

spring.cloud.config.server.native.searchLocations

7. 健康监测

配置好了Git或SVN之后，为了能确保能连通仓库，我们需要为其实现健康监测功能，来判断Git或SVN仓库是否可以访问

我们配置了

spring.cloud.config.server.git.uri

spring-boot-actuator

如果我们无法连接到配置仓库的uri那么

status

DOWN

在

org.springframework.cloud.config.server.config

ConfigServerHealthIndicator

如果不想使用这个健康检测器，也可以通过使用

spring.cloud.config.server.health.enabled=false

8. 属性覆盖

Config Server提供一个叫

Property Overrides

属性覆盖

spring.cloud.config.server.overrides

官方举例：

spring:
cloud:
config:
server:
overrides:
foo: bar

通过属性覆盖配置的参数不会被Config Client修改，并且Config Client获取配置信息时就会得到这些信息，使用这种特性可以方便我们为客户端应用配置一些共同属性或默认属性。这些属性不是强制的，可以通过改变客户端中的更高优先我级的配置方式来选择是否使用这些属性覆盖的默认值。

9. 安全保护

配置中心存储的内容很敏感，所以必需做一些安保措施，使用Spring Security更方便一些。

只需要引入依赖并配置用户名和密码

<!--Spring Security依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-security</artifactId>
</dependency>

默认情况下会得到一名为user的用户，并在配置中心启动的时候在log中打印出来随机密码，当然大多数情况下我们不会使用这个随机密码，我们可以在配置文件中指定用户和密码

security:
user:
name: user
password: xxxxxxx

通过上边的配置，配置中心已经开启了安全保护，这时候连接配置中心的客户端没有密码的情况下会返回401错误

只需要在客户端中加入账号密码来通过安全校验，举例

spring:
cloud:
config:
username: user
password: xxxxxxx

10. 加密解密

微服务开发中往往都是所属组织成员自行维护，在配置文件中会有很多敏感信息，比如数据库密码等，这些信息如果以明文存储和传输是很危险的，为解决这个问题，Config提供了对属性加密解密的功能，只需要在敏感信息的值加密后加上前缀

{cipher}

{JAVA_HOME}/jre/lib/security

用数据源举例：

spring:
datasource:
username: dbuser
password: '{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'

相关端点

完成了JCE的安装后，可以尝试启动配置中心，Spring Cloud 暴露出了几个端点

• /encrypt/status：查看加密功能状态的端点
• /key：查看密钥的端点
• /encrypt：对请求的body内容进行加密的端点
• /decrypt：对请求的body内容进行解密的端点

在没有设置密钥的时候，访问/encrypt/status端点会出现

{
"description":"No key was installed for encryption service",
"status":""
}

在bootstrap.yml中设置密钥(对称性密钥)

encrypt:
key: hellxz

重启Config Server，使用/encrypt端点测试加密效果：

/decrypt解密测试：

非对称加密

非对称加密相对对称加密的密钥生成与配置更加复杂，耗时也更多，但是更安全。

这里我们使用jdk自带的keytool工具来生成证书，它的位置在%JAVA_HOME%\bin\keytool.exe

生成密钥的命令如下，请酌情修改：

PS C:\Program Files\java\jdk1.8.0_161\bin> keytool -genkeypair -alias config-server -keyalg RSA -keystore D:\\config-server.keystore
输入密钥库口令:
再次输入新口令:
您的名字与姓氏是什么?
[Unknown]:  Hellxz Zhang
您的组织单位名称是什么?
[Unknown]:  SN
您的组织名称是什么?
[Unknown]:  SN
您所在的城市或区域名称是什么?
[Unknown]:  JiNan
您所在的省/市/自治区名称是什么?
[Unknown]:  ShanDong
该单位的双字母国家/地区代码是什么?
[Unknown]:  ZH
CN=Hellxz Zhang, OU=SN, O=SN, L=JiNan, ST=ShanDong, C=ZH是否正确?
[否]:  y

输入 <config-server> 的密钥口令
(如果和密钥库口令相同, 按回车):

Warning:
JKS 密钥库使用专用格式。建议使用 "keytool -importkeystore -srckeystore D:\\config-server.keystore -destkeystore D:\\conf
ig-server.keystore -deststoretype pkcs12" 迁移到行业标准格式 PKCS12。

这里使用的是PowerShell，在win下测试的，这样操作后，在D盘生成了config-server.keystore的文件，我们将这个文件放到Config Server 的resources下（classpath），然后在bootstrap.yml加入相关配置信息

encrypt:
key: hellxz
key-store:
location: config-server.keystore
alias: config-server
password: hellxz
secret: hellxz

加密测试：

解密测试：

11. 高可用配置

为了实现配置中心的高可用，主要有两种方式

1. 传统模式：不需做任何额外配置，起多个配置中心服务，所有配置中心都指向同一个Git仓库，客户端通过负载均衡进行调用配置中心服务，从而实现服务的高可用
2. 服务模式：将配置中心注册为微服务到注册中心，通过Eureka的服务治理进行负载均衡，而且也实现了自维护，这块在后边的客户端详解中讲。

客户端详解

1. URI指定配置中心

Spring Clout Config的客户端在启动的时候，默认会从工程的classpath下加载配置信息并启动应用，只有配置了

spring.cloud.config.uri

举例：

spring:
application:
name: hellxztest
cloud:
config:
uri: http://localhost:7001/
profile: dev

2. 服务化配置中心

服务端详解那一块说过可以把配置中心注册到注册中心，通过服务发现来访问Config Server拉取Git仓库中的配置信息。

下面的内容需要改造ConfigServer和ConfigClient

为ConfigServer和ConfigClient的pom.xml中分别加入Eureka的依赖

<!-- Spring Cloud Eureka的依赖 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>

在上边说过，bootstrap.yml的优化级大于application.yml，这里我们需在将这两个服务都注册到注册中心，所以我选择在ConfigServer的resources下创建一个application.yml，在其中配置连接注册中心的通用信息

applicaiton.yml

eureka:
client:
serviceUrl:
defaultZone: http://localhost:1111/eureka/

将这个applicaiton.yml 的内容复制到ConfigClient的resources下的bootstrap.yml中。

依赖有了，注册中心的地址也有了，别忘了将这两个模块的主类加上

@EnableDiscoveryClient

完成这一步我们可以先启动注册中心、ConfigServer、ConfigClient 看一看是否注册成功，如图，

ConfigServer至此配置完毕。接下来我们为客户端使用服务发现的方式去调用ConfigServer

只需要在ConfigClient的bootstrap.yml中注掉spring.cloud.config.uri那一项，

spring.cloud.discovery.enabled=true

spring.cloud.discovery.serviceId=config-server

spring:
application:
name: hellxztest                     #指定了配置文件的应用名
cloud:
config:
#      uri: http://localhost:7001/    #Config server的uri
profile: dev                          #指定的环境
label: master                        #指定分支
discovery:
enabled: true                     #开启配置服务发现
serviceId: config-server        #配置中心服务名
server:
port: 7002
management:
security:
enabled: false     #SpringBoot 1.5.X 以上默认开通了安全认证，如果不关闭会要求权限
eureka:
client:
serviceUrl:
defaultZone: http://localhost:1111/eureka/

重启ConfigClient项目，我们之前提供了一个接口

/api/from

测试成功，服务化配置中心配置完成。

3. 失败快速响应与重试

Spring Cloud Config的客户端会预先加载很多配置信息，然后才开始连接Config Server进行属性的注入，当应用复杂的时候，连接ConfigServer时间过长会直接影响项目的启动速度，我们还希望能知道Config Client 是否能从Config Server中取到信息。此时，只需在bootstrap.yml（.properties）中配置属性

spring.cloud.config.failfast=true

关闭Config Server，重启Config Client，项目直接报错无法启动

java.lang.IllegalStateException: Could not locate PropertySource and the fail fast property is set, failing
…… 省略其他错误信息 ……

直接失败似乎代价有些高，所以Config客户端还提供了自动重试的功能，开启前请确认

spring.cloud.config.failfast=true

<!-- 连接配置中心重试的依赖 -->
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>

只需加入如上两个依赖就能实现自动重试，当第6次重试失败之后，那么就会上边那个快速失败报的错误

如果对最大重试次数和重试间隔等设置不满意，可以通过下面有参数进行调整。

spring:
cloud:
fail-fast: true                 #快速失败
retry:
initial-interval: 1100        #首次重试间隔时间，默认1000毫秒
multiplier: 1.1D              #下一次重试间隔时间的乘数，比如开始1000，下一次就是1000*1.1=1100
max-interval: 2000            #最大重试时间，默认2000
max-attempts: 3               #最大重试次数，默认6次

结束

看了上一篇文章的可能等着急了，本人看书很慢，最近有在学半音阶口琴，这些文字内容都是工作清闲时候写成的，相比上次更新已有5天，所有文字均为手打，全文7k多字，书中写的表达好的地方直接就引用了，再次感谢《Spring Cloud微服务实战》的作者

下一节 继续学习 Spring Cloud Bus，请大家耐心等待

手打不易，本文内容如需转载请注明出处