spring cloud bus 实现config配置的动态更新

1 消息总线bus

简单理解就是一个消息中心，众多微服务实例可以连接到总线上，实例可以往消息中心发送或接收信息（通过监听）。比如：实例A发送一条消息到总线上，总线上的实例B可以接收到信息（实例B订阅了实例A），这样的话，消息总线就充当一个中间者的角色，使得实例A和实例B解偶了

2 Config遗留的问题

当config server中的配置修改后，config client不能及时的进行为当前客户端进行配置的更新与重载。当时使用的一个方式是通过git的Web Hook来处理，即当我们修改config sever中的配置时，同时触发Web Hook，触发后，为指定的客户端列表以post请求进行/refresh接口的调用，从而使得应用程序的属性能供实时更新，但是，如果所有的触发操作都需要我们手工维护Web Hook中的应用配置，那随着系统的壮大，就会很难维护，所以这个问题我们可以使用消息总线来解决

3 整合Spring Cloud Bus

需要3个项目：

eureka-server: eureka的注册中心

config-server-eureka: config server并注册到eureka注册中心

config-client-eureka: config client 并注册到eureka注册中心

还有一个仓库，连接远程仓库，用于动态刷新配置： config-repo

具体的项目就不写了。挺简单的

消息总线的实现是依赖于消息中间件的，和spring cloud bus整合的消息中间件目前就两个rabbitmq和kafka，我们这里用rabbitmq作为消息中间件；

rabbitmq的安装和在springboot中的使用可参考我的博客：https://blog.csdn.net/weixin_38312502/article/details/105959040

最好的动态更新方式在第7节总结中给出

3.1  扩展config-client-eureka

修改pom文件，添加依赖

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

配置文件application.yml中添加如下配置：

#关闭端口安全
management:
  endpoints:
    web:
      exposure:
        include: "*"
#连接rabbitmq
spring:
  rabbitmq:
    host: 127.0.0.1
    port: 5672
    username: springcloud
    password: springcloud

3.2 启动项目

依次启动eureka-server(8081) >config-server-eureka(9090) >config-client-eureka(9092)

1. config server: 访问http://localhost:9090/tanfp/prod查看config server是否能正确获取到配置

2. config client: 访问http://localhost:9092/user （该接口返回config-repo中的user配置）和config server 对比查看是否正确返回属性

3. 修改config-repo中user属性，并再次分别调用config server和config client，会发现config server中的配置已经刷新，但是config client返回的配置还没有更新

4.post请求config client:   http://localhost:9092/actuator/bus-refresh,用来刷新config client的配置

5.再次访问config client的user接口，发现返回值已经被更新了

到这里，就已经可以了，但是我么还需要进一步优化，因为你会发现，目前我们还是需要通过访问某个实例才能进行刷新，这样会增加集群内部的复杂度

4. 原理分析

 当系统启动后，图上"order"服务的多个实例会请求Config Server获取配置信息。此时若我们修改github上的user属性，这个修改是不会触发"order"实例的属性更新的。当我们向"order-1"（任意一个连接在总线上的实例都行）服务实例发送POST请求，访问/actuator/bus-refresh接口。此时"order-1"服务实例就会将刷新请求发送到消息总线中，该消息事件会被“order”的其它连接在消息总线上的实例获取到，并重新从Config Server中获取它们的配置信息，从而实现配置信息的动态更新。(即rabbitmq的发布订阅模式)

5 指定刷新范围

/actuator/bus-refresh?destination=XXX，指定destination参数可以用来定位具体要刷新的应用程序，有两种方式：

定位具体实例
/actuator/bus-refresh?destination=customers:9000，此时总线上的各应用实例会根据destination指定的属性值来判断是否是自己的实例ID，符合才进行配置刷新。这里我理解的是customers服务下，端口号为9000的实例才会进行配置更新。
定位具体服务
/actuator/bus-refresh?destination=customers:**，该请求会触发customers服务的所有实例来进行刷新。

destination值是指实例id，可以通过

spring.cloud.bus.id

来指定，也可以不指定，默认是spring.application.name:server.port

6. 架构优化

上面我们是通过向order服务的某个实例来发送配置更新请求，从而触发整个服务集群的配置请求。为了让服务集群中的各个节点对等，降低将来的运维工作。我们可以将触发实例配置更新的请求，移到config-server工程中，让Config Server也连接到消息总线上，由Config Server来触发请求。改造方案如下：

在config-server也引入Spring Cloud Bus
/actuator/bus-refresh请求发送到config-server上，并通过destination参数来制定需要更新配置的服务或实例。

7 总结架构

1. config server:

• 需引入

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

• 需要在application.yml中配置rabbitmq的连接属性
• 并注册到eureka的注册中心

2. config client:

• 需要引入spring-cloud-starter-bus-amqp包
• 不需要配置rabbitmq的连接属性
• 但是需要注册到注册中心

3. eureka server按正常配置创建

4. 当修改config-repo中的配置时，需要配置Web Hook,触发请求config server的/actuator/bus-refresh端口