通過消息總線Spring Cloud Bus實現配置文件刷新（使用Kafka或RocketMQ）

如果需要客戶端獲取到最新的配置信息需要執行refresh，我們可以利用webhook的機制每次提交代碼發送請求來刷新客戶端，當客戶端越來越多的時候，需要每個客戶端都執行一遍，這種方案就不太適合了。使用Spring Cloud Bus可以完美解決這一問題。

Spring bus的一個核心思想是通過分布式的啟動器對spring boot應用進行擴展，也可以用來建立一個多個應用之間的通信頻道。目前唯一實現的方式是用AMQP消息代理作為通道，同樣特性的設置（有些取決於通道的設置）在更多通道的文檔中。其實本質是利用了MQ的廣播機制在分布式的系統中傳播消息，目前常用的有Kafka和RabbitMQ。

更新客戶端配置文件整個流程是：

1. 提交代碼觸發post請求給bus/refresh
2. server端接收到請求並發送給Spring Cloud Bus
3. Spring Cloud bus接到消息並通知給其它客戶端
4. 其它客戶端接收到通知，請求Server端獲取最新配置
5. 全部客戶端均獲取到最新的配置

 RocketMQ實現

在《Spring Boot中使用RabbitMQ》一文中，我們已經介紹了關於消息代理、AMQP協議以及RabbitMQ的基礎知識和使用方法。下面我們開始具體介紹Spring Cloud Bus的配置，並以一個Spring Cloud Bus與Spring Cloud Config結合的例子來實現配置內容的實時更新。

RabbitMQ實現

下面我們來具體動手嘗試整個配置過程：

• 准備工作：這里我們不做新的應用，但需要用到上一章中，我們已經實現的關於Spring Cloud Config的幾個工程，若讀者對其還不了解，建議先閱讀第4章的內容。
  • config-repo：定義在Git倉庫中的一個目錄，其中存儲了應用名為didispace的多環境配置文件，配置文件中有一個from參數。
  • config-server-eureka：配置了Git倉庫，並注冊到了Eureka的服務端。
  • config-client-eureka：通過Eureka發現Config Server的客戶端，應用名為didispace，用來訪問配置服務器以獲取配置信息。該應用中提供了一個/from接口，它會獲取config-repo/didispace-dev.properties中的from屬性返回。
• 擴展config-client-eureka應用
  • 修改pom.xml增加spring-cloud-starter-bus-amqp模塊（注意spring-boot-starter-actuator模塊也是必須的）。

1 2 3 4

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

• 在配置文件中增加關於RabbitMQ的連接和用戶信息

1 2 3 4

spring.rabbitmq.host=localhost spring.rabbitmq.port=5672 spring.rabbitmq.username=springcloud spring.rabbitmq.password=123456

• 啟動config-server-eureka，再啟動兩個config-client-eureka（分別在不同的端口上，比如7002、7003），我們可以在config-client-eureka中的控制台中看到如下內容，在啟動時候，客戶端程序多了一個/bus/refresh請求。

o.s.b.a.e.mvc.EndpointHandlerMapping : Mapped "{[/bus/refresh],methods=[POST]}" onto public void org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh(java.lang.String)

 

• 到這里，我們已經能夠通過Spring Cloud Bus來實時更新總線上的屬性配置了。先訪問兩個config-client-eureka的/from請求，會返回當前config-repo/didispace-dev.properties中的from屬性。
• 接着，我們修改config-repo/didispace-dev.properties中的from屬性值，並發送POST請求到其中的一個/bus/refresh。
• 最后，我們再分別訪問啟動的兩個config-client-eureka的/from請求，此時這兩個請求都會返回最新的config-repo/didispace-dev.properties中的from屬性。

原理分析

我們通過使用Spring Cloud Bus與Spring Cloud Config的整合，並以RabbitMQ作為消息代理，實現了應用配置的動態更新。

整個方案的架構如上圖所示，其中包含了Git倉庫、Config Server、以及微服務“Service A”的三個實例，這三個實例中都引入了Spring Cloud Bus，所以他們都連接到了RabbitMQ的消息總線上。

當我們將系統啟動起來之后，“Service A”的三個實例會請求Config Server以獲取配置信息，Config Server根據應用配置的規則從Git倉庫中獲取配置信息並返回。

此時，若我們需要修改“Service A”的屬性。首先，通過Git管理工具去倉庫中修改對應的屬性值，但是這個修改並不會觸發“Service A”實例的屬性更新。我們向“Service A”的實例3發送POST請求，訪問/bus/refresh接口。此時，“Service A”的實例3就會將刷新請求發送到消息總線中，該消息事件會被“Service A”的實例1和實例2從總線中獲取到，並重新從Config Server中獲取他們的配置信息，從而實現配置信息的動態更新。

而從Git倉庫中配置的修改到發起/bus/refresh的POST請求這一步可以通過Git倉庫的Web Hook來自動觸發。由於所有連接到消息總線上的應用都會接受到更新請求，所以在Web Hook中就不需要維護所有節點內容來進行更新，從而解決了通過Web Hook來逐個進行刷新的問題。

指定刷新范圍

上面的例子中，我們通過向服務實例請求Spring Cloud Bus的/bus/refresh接口，從而觸發總線上其他服務實例的/refresh。但是有些特殊場景下（比如：灰度發布），我們希望可以刷新微服務中某個具體實例的配置。

Spring Cloud Bus對這種場景也有很好的支持：/bus/refresh接口還提供了destination參數，用來定位具體要刷新的應用程序。比如，我們可以請求/bus/refresh?destination=customers:9000，此時總線上的各應用實例會根據destination屬性的值來判斷是否為自己的實例名，若符合才進行配置刷新，若不符合就忽略該消息。

destination參數除了可以定位具體的實例之外，還可以用來定位具體的服務。定位服務的原理是通過使用Spring的PathMatecher（路徑匹配）來實現，比如：/bus/refresh?destination=customers:**，該請求會觸發customers服務的所有實例進行刷新。

架構優化

既然Spring Cloud Bus的/bus/refresh接口提供了針對服務和實例進行配置更新的參數，那么我們的架構也相應的可以做出一些調整。在之前的架構中，服務的配置更新需要通過向具體服務中的某個實例發送請求，再觸發對整個服務集群的配置更新。雖然能實現功能，但是這樣的結果是，我們指定的應用實例就會不同於集群中的其他應用實例，這樣會增加集群內部的復雜度，不利於將來的運維工作，比如：我們需要對服務實例進行遷移，那么我們不得不修改Web Hook中的配置等。所以我們要盡可能的讓服務集群中的各個節點是對等的。

因此，我們將之前的架構做了一些調整，如下圖所示：

 

 

我們主要做了這些改動：

1. 在Config Server中也引入Spring Cloud Bus，將配置服務端也加入到消息總線中來。
2. /bus/refresh請求不在發送到具體服務實例上，而是發送給Config Server，並通過destination參數來指定需要更新配置的服務或實例。

通過上面的改動，我們的服務實例就不需要再承擔觸發配置更新的職責。同時，對於Git的觸發等配置都只需要針對Config Server即可，從而簡化了集群上的一些維護工作。

本文完整示例：

• 開源中國：http://git.oschina.net/didispace/SpringCloud-Learning/tree/master/Chapter1-1-7
• GitHub：https://github.com/dyc87112/SpringCloud-Learning/tree/master/Chapter1-1-7