Spring Cloud Config 怎么通过Spring Cloud Bus实现动态刷新配置

上一节中介绍了怎么使用Git WebHooks来动态刷新配置，虽然实现了动态刷新的效果，但是也有不足之处，现在是一个客户端，可以通过配置Git WebHooks来实现动态刷新，那后面随着工程的壮大，变成了十个甚至几十个客户端的时候，难道要对每个客户端都配置一个Git WebHooks吗？这样后期维护就很难了，而且容易出错，针对这种问题，我们可以使用Spring Cloud Bus来解决。

在微服务系统架构中，我们通常会使用轻量级的消息代理来构建一个共用的消息主题让系统中所有的微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以我们称它为消息总线。我们使用Spring Cloud Bus可以很容易地搭建起消息总线。

Spring Cloud Bus支持的中间件产品：
1.RabbitMq
2.KafKa
本节我们使用RabbitMq作为消息代理中间件来实现消息总线并完成动态刷新的功能。
RabbitMq的安装可以参考：https://www.jianshu.com/p/5d1f7652107b

• 先看一下方案架构
  
  image.png
  
  从架构中可以看出，当Git仓库中的内容变更后，Git WebHooks会以Post方式发送/bus/refresh（现在路径换成了/actuator/bus-refresh）到Config Server中，而不是在发送到具体的实例上，Config Server就会将刷新请求发送到消息总线去，该事件会被Service B-1、Service B-2、Service A-1、Service A-2实例从总线中获取，并重新从Config Service中获取它们的配置信息，从而实现配置信息的动态更新。
  从上面的内容可以看出，具体的服务实例不再需要承担触发配置更新的职责，Git WebHooks只需要配置Config Server就可以实现N个实例动态刷新的功能，简化了集群上的维护工作。

实现

还是以前两节中创建的config-server和config-client两个服务来继续实现本节内容

• 修改config-client工程

1.编辑pom.xml，添加spring-cloud-starter-bus-amqp模块

  org.springframework.cloud
  spring-cloud-starter-bus-amqp

2.修改application.yml，添加RabbitMq的连接信息

management:
  endpoints:
    web:
      exposure:
        include: "*"

spring:
  rabbitmq:
    host: 59.110.164.147
    port: 5672
    username: guest
    password: guest
  application:
    name: configtest

• 修改config-server工程
  1.编辑pom.xml，添加spring-cloud-starter-bus-amqp模块

  org.springframework.cloud
  spring-cloud-starter-bus-amqp

2.修改application.yml，添加RabbitMq的连接信息添加management. endpoints.web. exposure. include="*"将endpoint信息全部暴露出来，不然访问不到/actuator/bus-refresh

spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          #Git仓库位置
          uri: https://gitee.com/songyu205110/config
          #访问Git仓库用户名
          username: [email protected]
          #访问Git仓库的用户密码
          password: songyu520...
          #配置仓库路径下的相对搜索位置，可以配置多个
          search-paths: /config-repo
  rabbitmq:
    host: 59.110.164.147
    port: 5672
    username: guest
    password: guest

server:
  port: 7000

management:
  endpoints:
    web:
      exposure:
        include: "*"

3.将config-client工程中的Filter包拷贝过来，解决Git WebHooks 发送通知的时候报错问题，上一节中提到过，拷贝后修改Filter类中的代码，如下：

//将actuator/refresh 修改为actuator/bus-refresh
if (!url.endsWith("actuator/bus-refresh")) {
  filterChain.doFilter(servletRequest, servletResponse);
  return;
}

• 修改Git仓库的WebHooks地址，修改为config-server的地址

  
  
  image.png

测试

启动config-server工程
启动两个config-client工程，端口分别是7001和7002

java -jar config-0.0.1-SNAPSHOT.jar --server.port=7001
java -jar config-0.0.1-SNAPSHOT.jar --server.port=7002

我们配置的是取configtest-dev.properties文件中的配置信息，先看一下当前Git仓库中configtest-dev.properties文件中的内容

image.png

都启动起来以后，我们访问一下7001和7002的/config-client/test接口，获取一下当前配置信息：

image.png

可以看到获取到的当前信息和Git仓库中的配置信息是一致的。

• 修改Git仓库中configtest-dev.properties文件的配置。
  把值改为jdbc:mysql://dev:3320/，端口号变成3320，修改完后，Push到Git仓库中。
  
  image.png
  Push完以后可以看到Git仓库中configtest-dev.properties值已经改变了，然后在重新访问一下7001和7002的/config-client/test接口：
  
  image.png
  可以看到7001和7002两个实例都取到了最新的配置内容。
  到Git仓库的WebHooks页面也可以看到内容变更后像config-service发送了/actuator/bus-refresh请求
  image.png

到此已经实现了使用Spring Cloud Bus来动态刷新配置的功能了，可以看到我们不需要再像上一节中看到的那样去为每个具体实例绑定Git WebHooks了，只需要对config-server实现Git WebHooks就可以了，大大的减少了维护成本，和降低了出错的概率。

在一些特殊场景下，如果只希望刷新某个具体的实例的配置，不需要所有实例都更新，针对这样的需求我们可以使用destination参数来定位具体要刷新的应用，避免总线上的所有服务实例都刷新，destination是通过Spring的PathMatecher来实现的，不了解的伙伴们可以自己找点资料看一下，这里就不啰嗦了。