【Spring Cloud总结】40.Spring Cloud Config配置属性刷新之自动刷新

接上篇《39.Spring Cloud Config配置属性刷新之手动刷新》  Spring Cloud版本为Finchley.SR2版

上两篇我们讲解了有关Spring Cloud Config配置的手动刷新机制，本篇我们来讲解如何实现Spring Cloud Config配置属性的自动刷新功能。

本部分官方文档：https://cloud.spring.io/spring-cloud-static/Finchley.SR4/single/spring-cloud.html#_push_notifications_and_spring_cloud_bus
注：好像Finchley.SR2的文档已经挂了，最新的是Finchley.SR4的文档。

上一章我们讲解我如何进行Config属性的手动刷新操作（使用refresh端点），但是也分析了手动刷新的一些弊端，例如集群情况下，手动刷新所有节点的效率太低。所以我们需要一个自动刷新的策略，来实现当远端配置更新后，系统可以批量更新所有客户端配置信息的效果。

其实批量自动刷新的策略很简答，即在Config客户端集群之间架设一个中间件，当其中一个Config客户端调用refresh服务进行远程仓库配置更新时，该更新操作会推动至中间件，其它连接了该中间件的Config客户端，感知到中间件的消息变化，也会同时进行配置的refresh更新，从而实现一步操作，整个Config客户端集群自动刷新的效果。具体如何操作呢？用什么中间件呢？且看下文一一道来。

一、Spring Cloud自动刷新策略

在Spring Cloud的官方文档中，有“Push Notifications and Spring Cloud Bus”的一章，其意思大致是“推送消息和Spring Cloud Bus”。大家一提到“推送消息”应该就会想到常用的消息中间件MQ（例如ActiveMQ，RabbitMQ，Kafka、RocketMQ等），一般MQ就是存储一个消息队列，生产消息的生产者进行消息信息的生产，消费者进行消息信息的消费。
注：想详细了解MQ相关基础知识，请阅读我的【RabbitMQ消息中间件】专栏：

专栏地址：https://blog.csdn.net/u013517797/category_9276117.html

而其中的“Spring Cloud Bus”，是Spring Cloud的一个子项目，它基于AMQP协议（高级消息队列协议，用于消息的生产和消费），我们可以使用RabbitMQ或Kafka来实现一个基本的基于AMQP协议的应用，来支持消息中间件的接入。

以上就是Spring Cloud自动刷新的策略，我们只需要架设好消息中间件，编写好属性服务端和远端仓库之间的连接，即可实现自动刷新，那么开始吧。

二、下载安装消息中间件

我们这里使用RabbitMQ的消息中间件，我们先来下载和配置它。
由于之前我已经写有相关的博客专栏了，这里我就不在赘述，需要了解安装和配置详情的小伙伴，请移步至下面的博文连接：

【RabbitMQ消息中间件】2.安装RabbitMQ：https://blog.csdn.net/acmman/article/details/79371312
我们这里下载了RabbitMQ 3.8.4的windows版本：

配置好环境变量等参数后，在RabbitMQ文件目录的“sbin”文件夹下执行相关的指令（具体参见上面“安装RabbitMQ”的博文连接）。

注：常用指令：
rabbitmq-plugins enable rabbitmq_management 开启插件
rabbitmq-service remove 移除服务
rabbitmq-service install 安装服务
rabbitmq-service start 或者 net start rabbitmq 启动服务
rabbitmq-service stop 或者 net stop rabbitmq 停止服务
rabbitmqctl status 查看服务状态
rabbitmq-server restart 重启服务

启动完相关服务后，我们浏览器中输入地址http://127.0.0.1:15672/查看，就可以看到RabbitMQ的Web管理页面：

Web管理页面的功能介绍详见下面的博文链接：
【RabbitMQ消息中间件】3.管理界面中的功能：https://blog.csdn.net/acmman/article/details/79438143

这里我们就安装好了MQ消息中间件了，接下来我们就要使用Spring Cloud Bus来实现配置的批量刷新了。

三、客户端整合Spring Cloud Bus并测试

我们拷贝原来的microserver-config-client-refresh工程进行修改，创建一个microserver-config-client-refresh-bus工程：

其中，pom.xml中引入spring-cloud-starter-bus-amqp的依赖，用于连接RabbitMQ：

<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>
  <artifactId>microserver-config-client-refresh-bus</artifactId>
  <name>microserver-config-client-refresh-bus</name>
  
  <parent>
        <groupId>com.microserver.cloud</groupId>
        <artifactId>microserver-spring-cloud</artifactId>
        <version>0.0.1-SNAPSHOT</version>
    </parent>
  
  <dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-client</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    
    <!-- spring-cloud-starter-bus-amqp -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-bus-amqp</artifactId>
    </dependency>
    
</dependencies>
  
</project>

然后修改bootstrap.yml配置文件，添加连接RabbitMQ的配置：

spring:
  cloud:
    config:
      uri: http://localhost:8090
      username: user
      password: password123
      profile: dev
      label: master  #如果ConfigServer的后端存储是Git，默认就为master
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

这里RabbitMQ的默认管理账号和密码都是guest。

Spring Cloud Bus提供了一个批量刷新的端点“bus/refresh”，来实现刷新本服务的同时，将刷新动作推送至消息中间件，通知其它连接了消息中间件的客户端进行自动刷新操作。
注：spring boot2.0之前，是通过访问“bus/refresh”来实现批量刷新的，但是spring boot2.0之后，/bus/refresh全部整合到actuator里面了，所以之前1.x的management.security.enabled全部失效，不适用于2.0，访问路径变为“actuator/bus-refresh”，所以必须在actuator配置端点中暴露“bus-refresh”节点，这里在application.yml中的include配置下增加bus-refresh：

server:
  port: 8092
spring:
  application:
    name: microserver-config-client
management:
  endpoints:
    web:
      exposure:
        include: refresh,bus-refresh
    
type: abcd

然后我们分别启动Config Server和两个我们上面新建的Config Client（一个端口为8091，一个端口为8092）：

我们观察microserver-config-client-refresh-bus的控制台，可以看到已经连接上了MQ：

再看上面的端点加载环节，加载了bus-refresh的刷新端点：

此时我们访问两个客户端的“profileType”节点，都是“client-dev-refresh”：

此时我们修改本地仓库中的microserver-config-client-dev.yml文件，将原来的“client-dev-refresh”修改为“client-dev-refresh-bus”，然后提交至远程仓库：

然后我们使用“actuator/bus-refresh”来进行批量刷新测试，这里用postman访问端口为8091的客户端的“actuator/bus-refresh”服务：

此时我们再刷新8091和8092的“profileType”节点，发现远端仓库的更新，被同步过来了：

消息中间件的作用，使得某个客户端进行刷新，可以促使整个客户端集群全部刷新的效果。

四、自动批量刷新的原理

上面我们使用Bus实现了客户端批量自动刷新配置的效果，那么它的原理是什么呢？
首先，我访问的“actuator/bus-refresh”节点，它触发了一个事件，该事件传播到了其它的节点，其它节点获取事件后，也进行了刷新的效果。

我们重新在8091执行一下“actuator/bus-refresh”节点，可以看一下RabbitMQ的控制台的Queues模块，找到我们的消息队列，可以看到刷新事件被推送到了该队列中：

然后可以看到，过了几秒后，该消息事件就被8092消费了：

8092得到信息后，也进行了配置刷新的操作。

以上就是自动批量刷新的基本原理，在深入学习了RabbitMQ的相关消息模式后，会更加理解该原理。

五、绝对的全自动刷新

我们上面只是实现了半自动刷新的效果，即我们还需要手动调用“actuator/bus-refresh”节点。要想实现全自动刷新，我们还需要做一些操作。

自动刷新的机制，我们需要借助远程仓库里的“WebHooks”功能来实现。所谓的“WebHooks”，明面上翻译是“Web钩子函数”，所谓的“Web钩子函数”函数，即是在Web程序上执行了一个操作后，可以反向向远程服务发送一个请求，以此来实现一些操作。

这里我们使用的是码云，我们打开之前设置的远端仓库，选择“WebHooks”：

我们可以看到，上面有一个关于“WebHooks”的说明，即“每次您 push 代码后，都会给远程 HTTP URL 发送一个 POST 请求”，这里聪明的小伙伴可能已经想到了，在push之后，配置8091的“actuator/bus-refresh”节点作为远端调用的POST请求路径，这样不就可以实现全自动刷新了吗？没错，大致的配置如下：

当然，我们的服务是跑在本地的，这里的localhost地址在gitee上是无法访问的，这里就没有办法进行测试了，如果有公网映射的小伙伴，可以试验一下，或者使用如花生壳之类的有公网映射服务的软件来暴露出一个公网地址，在这里我就不展开了。

以上就是实现pring Cloud Config配置自动刷新效果的全部内容。

下一篇我们来深入讲解一下上面使用的Spring Cloud Bus的插件，如何优化Config的配置和刷新。

参考：《51CTO学院Spring Cloud高级视频》

转载请注明出处：https://blog.csdn.net/acmman/article/details/106440320