目录

[TOC]

前面的文章为微服务架构引入了统一配置管理Spring cloud config，实现了各个微服务配置分布式管理。配置被修改后，我们不可能重新启动微服务，前面说到过Spring Cloud Config可以自动更新配置，本篇会对同步自动刷新配置进行学习记录。另外配置文件存储在GIT仓库中，很多场景下，对于某些敏感的配置内容(例如数据库账号，密码等)，应当加密存储。部分内容涉及上篇文章：微服务学习笔记–使用Spring Cloud Config 统一管理微服务配置

同步刷新

在项目中加入actuator，就会有一个/refresh端点，当配置被修改后，只需要手动通过POST方式去访问这个端口，项目配置即可被刷新。但这种手动刷新的方式只能针对单个项目刷新，如果所有的微服务节点的配置都需要手动去刷新则工作量会很大。因此这里介绍的是同步刷新的方式，使用Spring Cloud Bus实现。之所以它能实现同步刷新，是因为Spring Cloud Bus 使用了轻量级的消息代理(如rabbitmq,kafka)，通过广播的方式让所以有被修改配置的微服务节点都能被刷新。

添加依赖

在上篇文章的Config Server，用户微服务，电影微服务三个项目中都引入以下依赖：

1
2
3
4

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

添加RabbitMQ

1、RabbitMQ安装可以参考之前的文章：RabbitMQ学习系列:一、RabbitMQ 的安装
在三个项目的配置文件中添加rabbitmq配置

1
2
3
4
5

rabbitmq:
  host: localhost
  port: 5672
  username: guest
  password: guest

添加测试方法

其实这样就改造完成了，为了方便测试，我们把git上存储的各个配置文件添加相应配置：

profile: user-dev-v1.0

在用户与电影微服务中的Controller中添加以下红框中的内容以获取上面添加的配置值：

@RefreshScope 添加该注解的类会在类更改时得到特殊处理

通过这样改造，我们可以修改上面的属性，push到仓库，刷新后测试属性是否被更新来验证我们配置的Spring cloud bus 是否生效。

测试

首先我们访问用户与电影微服务的getProfile方法查看当前配置的profile值：


把microservice-provider-user-dev.yml与 microservice-consumer-movie-dev.yml中的profile配置值分别修改成：user-dev-v2.0 和 movie-dev-v2.0 并推送到git仓库。再次使用getProfile方法获取配置值发现没有变化。
通过POSTMAN访问Config Server的/bus/refresh 端口：

再次访问用户与电影微服务的getProfile方法：


发现获取的配置值已经改变，说明我们刷新配置生效了。
这里我们是访问Config Server的 /bus/refresh端口，其实访问用户或电影微服务的/bus/refresh端口效果也是一样的，不过在实际环境中，微服务被迁移，网络地址可能会发生改变，因此把Config Server也加入到消息总线中，它的地址一般比较固定，它的配置更新状态可以广播到其它微服务节点中。

设置自动刷新

前面其实还是使用手动通过POST方式去访问/bus/refresh端口进行刷新，但已经实现了同步刷新。关于自动刷新我们可以借助GIT仓库的WebHook配置，在PUSH时让GIT给指定网络地址发送一个POST请求。

由于这里是在本地进行学习测试，没有网络地址可以进行测试。

加密解密

Config Server 为配置内容的加密解密提供了两种方式。

对称加密

安装JCE

使用JCE,下载地址：
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
需要对应相应版本的JDK，上面地址是jdk8的。
下载后打开解压有两个jar文件，把它们替换JDK安装目录下：
%JAVA_HOME%\jre\lib\security
在Config Server的配置文件中添加密钥：

1
2

encrypt:
  key: wei

key 可以自己随意设置
需要注意的是，这个配置必须配置在bootstrap.yml中，因此在Config Server中我们需要新建bootstrap.yml并将配置写入。

存储加密内容

做好上面的工作后，重新启动Config Server 项目，可能在控制到看到打印了以下端点：

这两个端点可以进行加密与解密。我们用POSTMAN把上面添加的profile配置值加密：

然后把返回的加密值写入配置文件中，以{cipher}开关，以让Config Server识别这是需要解密的内容。

将修改后的配置文件push到git仓库，使用/bus/refresh刷新配置后访问用户微服务的getProfile方法以测试：

可以看到返回到Config Client的配置已经被自动解密了

非对称加密

非对称加密相对与对称加密来说更安全。
1、生成keyStore
非对称加密可以使用JDK自带的keytool工具，打开cmd输入以下命令：

keytool -genkeypair -alias config-server -keyalg RSA -keystore config-server.keystore

按下图方式填写内容：

方便测试，上图我只输入了红框中的内容，其它地方直接回车即可。

运行完后会在当前运行路径下生成一个config-server.keystore 把这个文件移动到Config Server项目的 \src\main\resources目录下。
2、添加配置
在Config Server 的bootstrap.yml配置下添加以下内容：

1
2
3
4
5
6

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

这里的password与secret分别是生成keystroe时第一次与第二次输入的密码。location 是指向config-server.keystore的放置路径。
3、非对称加密测试
配置好上面的内容后，重启Config Server ，和对称加密一样，通过POSTMAN生成加密内容，写到配置文件中PUSH到GIT仓库即可。