Spring Cloud 之消息总线

客户端获取到最新的配置信息需要执行refresh，可以利用webhook的机制每次提交代码发送请求来刷新客户端，当客户端越来越多的时候，需要每个客户端都执行一遍，这种方案就不太适合了。使用Spring Cloud Bus可以完美解决这一问题。

Spring cloud bus通过轻量消息代理连接各个分布的节点，消息代理中间件可以将消息路由到一个或多个目的地。

方案一

1. 外部通过给客户端A发送 post 请求 bus/refresh

2. 客户端A接收到请求从Server端更新配置并且发送给Spring Cloud Bus

3. Spring Cloud bus接到消息并通知给其它客户端

4. 其它客户端接收到通知，请求Server端获取最新配置

5. 全部客户端均获取到最新的配置

客户端 config-client 改造步骤：

1. 添加依赖

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-bus-amqp</artifactId>

</dependency>

2. 配置文件

## 刷新时，关闭安全验证

management.security.enabled=false

## 开启消息跟踪

spring.cloud.bus.trace.enabled=true

spring.rabbitmq.host=192.168.1.101

spring.rabbitmq.port=5672

spring.rabbitmq.username=admin

spring.rabbitmq.password=123456

注： pom.xml中引入了spring-cloud-starter-bus-amqp，就需要配置rabbitmq，否则启动报错

3. 测试

config-client 启动时会发现 mapped 中有 /bus/refresh

在win下使用下面命令来模拟webhook，会发现所有 config-client 端都已更新配置

curl -X POST http://localhost:8002/bus/refresh

4. 结果

config-client A先执行，然后 config-client B/config-client C 执行

存在缺陷

在上面的流程中，我们已经到达了利用消息总线触发一个客户端bus/refresh,而刷新所有客户端的配置的目的。但这种方式并不优雅。原因如下：

1. 打破了微服务的单一职责原则。微服务本身是业务模块，它本不应该承担配置刷新的职责。

2. 破坏了微服务各节点的对等性。

3. 有一定的局限性。例如，微服务在迁移时，它的网络地址常常会发生变化，此时如果想要做到自动刷新，那就不得不修改WebHook的配置。

改进版本

1. 外部通过给 config-server 发送 post 请求 bus/refresh

2. config-server 端接收到请求并发送给Spring Cloud Bus

3. Spring Cloud bus接到消息并通知给各个客户端

4. 各个客户端接收到通知，请求Server端获取最新配置

5. 全部客户端均获取到最新的配置

服务端 config-server 改造步骤：

1. 添加依赖

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-bus-amqp</artifactId>

</dependency>

2. 配置文件

## 刷新时，关闭安全验证

management.security.enabled=false

## 开启消息跟踪

spring.cloud.bus.trace.enabled=true

spring.rabbitmq.host=192.168.1.101

spring.rabbitmq.port=5672

spring.rabbitmq.username=admin

spring.rabbitmq.password=123456

注： pom.xml中引入了spring-cloud-starter-bus-amqp，就需要配置rabbitmq，否则启动报错

3. 测试

config-server 启动时会发现 mapped 中有 /bus/refresh

在win下使用下面命令来模拟webhook，会发现所有 config-client 端都已更新配置

curl -X POST http://localhost:8002/bus/refresh

4. 结果

config-client A/config-client B/config-client C 同时执行更新

刷新后的数据在 /env 断点中可以查看。数据更新效果类似于 spring-boot-admin

5. 客户端大概的获取更新配置步骤：

Fetching config from server at: http://localhost:7001

Shutting down DiscoveryClient ...

Unregistering ...

registering service...

registration status: 204

局部刷新

某些场景下（例如灰度发布），我们可能只想刷新部分微服务的配置，此时可通过/bus/refresh端点的destination参数来定位要刷新的应用程序。

例如：/bus/refresh?destination=config-clientA:test:8003，这样消息总线上的微服务实例就会根据destination参数的值来判断是否需要要刷新。其中，config-client:testA:8003指的是各个微服务的ApplicationContext ID。SpringBoot在 ContextIdApplicationContextInitializer 中设置该ApplicationContext ID，默认为 spring.application.name:active profiles:server.port 的组合值，如config-clientA:test:8003，注意：该ID与 instance-id 没任何关系。

destination参数也可以用来定位特定的微服务。例如：/bus/refresh?destination=config-clientA:**，这样就可以触发 config-clientA 微服务所有实例的配置刷新，而 config-clientB 不会更新。

跟踪总线事件

一些场景下，我们可能希望知道Spring Cloud Bus事件传播的细节。此时，我们可以跟踪总线事件（RemoteApplicationEvent的子类都是总线事件）。

跟踪总线事件非常简单，只需设置spring.cloud.bus.trace.enabled=true，这样在/bus/refresh端点被请求后，访问/trace端点就可获得结果。

想要对接受到的消息自定义自己的处理方式的话，可以添加@EventListener注解的AckRemoteApplicationEvent和SentApplicationEvent类型到你自己的应用中。或者到TraceRepository类中，直接处理数据。

gitlab等更新后自动刷新

默认gitlab的webhook更新调用config server的/monitor(spring-cloud-config-monitor)触发RefreshRemoteApplicationEvent事件，然后spring cloud bus的StreamListener监听RemoteApplicationEvent，通过mq发布到每个config client，然后client接收RemoteApplicationEvent事件来实现refresh。

config-server需引入 spring-cloud-config-monitor

实例源码： config-bus

参考文档： https://www.cnblogs.com/ityouknow/p/6931958.html