客戶端獲取到最新的配置信息需要執行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