使用Spring Cloud Config我們能實現服務配置的集中化管理，在服務啟動時從Config Server獲取需要的配置屬性。但如果在服務執行過程中，我們需要將某個配置屬性進行修改，比如將驗證碼的失效時間從五分鐘調整為十分鐘，如何將這個更新在服務端不重啟服務就能動態生效，是本文討論的內容。

Spring Cloud Bus

Spring Cloud Bus可以理解為Spring Cloud體系架構中的訊息匯流排，通過一個輕量級的Message Broker來將分散式系統中的節點連線起來。可用來實現廣播狀態更新（如配置更新），或其它管理指令。Spring Cloud Bus 就像是一個分散式的Spring Boot Actuator， 目前提供了兩種型別的訊息佇列中介軟體支援：RabbitMQ與Kafka（對應的pom依賴分別為spring-cloud-starter-bus-amqp， spring-cloud-starter-bus-kafka）。

Spring Cloud 在spring-cloud-context中添加了兩個actuator管理介面（POST請求）： /actuator/env 與 /actuator/refresh， 前者可用於更新當前服務例項Environment物件中的配置屬性，後者可用於重新整理當前服務例項的配置資訊。

Spring Cloud Bus也提供了兩個對應的介面

/actuator/bus-env，相對於/actuator/env ， 使用鍵值對更新每個例項的Environment，預設不暴露，需配置management.endpoints.web.exposure.include=bus-env 來開放介面訪問/actuator/bus-refresh，相對於/actuator/refresh，對每個例項，清空RefreshScope快取，重新繫結@ConfigurationProperties， 預設不暴露，可通過配置management.endpoints.web.exposure.include=bus-refresh 來開放介面訪問

綜上，/actuator/env 與 /actuator/refresh 是針對單個服務例項修改或重新整理其配置資訊，而 /actuator/bus-env 與 /actuator/bus-refresh 則是藉助於Spring Cloud Bus的訊息機制作用於分散式系統中的所有服務例項，因此前面有Spring Cloud Bus 就像是一個分散式的Spring Boot Actuator的說法。

使用Spring Cloud Bus來實現服務配置動態更新的結構圖如下

更新配置倉庫中的配置檔案，push到遠端Git倉庫遠端Git倉庫通過Webhook呼叫配置伺服器的通知更新介面配置伺服器傳送配置更新訊息到訊息匯流排其它服務節點監聽到配置伺服器傳送的配置更新訊息其它服務節點向配置伺服器傳送拉取最新配置的請求配置伺服器向配置倉庫拉取最新的配置返回給其它服務節點案例演示

我們還是以前面的springcloud-config， springcloud-eureka， springcloud-eureka-client三個專案來完成本文的案例演示。https://github.com/ronwxy/springcloud-demos

使用Actuator

在不引入Spring Cloud Bus的情況下，我們可以通過Spring Cloud提供的actuator介面來實現單個例項的配置動態更新。

依次啟動springcloud-eureka， springcloud-config， springcloud-eureka-client專案，然後修改springcloud-eureka-client的啟動埠，將8080改為8081，再啟動一個springcloud-eureka-client的服務例項。

springcloud-eureka-client 的測試介面程式碼如下

@RestController@RefreshScopepublic class HelloController { @Autowired private Environment env; @Value("${app}") private String app; @RequestMapping("/hello") public String hello(){ return "Hello, welcome to spring cloud 2. env: " + env.getProperty("app") + ", value: " + app; }}

此時依次請求兩個例項的hello介面，得到結果如下

我們通過/actuator/env介面來修改埠8080例項的屬性app的值，使用postman操作如圖

此時再請求介面返回結果如下

可以看到Environment物件中app屬性的值已更新，但是 @Value註解的屬性值未變，可見 /actuator/env 介面只是更新了Environment物件，並不負責重新整理其它方式引用的屬性值。此時請求另一個埠為8081的例項介面，其屬性值都未更新，也可見 /actuator/env 只作用於當前例項本身。

如果要讓8080例項的@Value屬性也動態更新，則可再呼叫/actuator/refresh介面，如圖

此時再請求測試介面，得到結果如下（@Value註解的屬性也已經更新了）

使用Spring Cloud Bus

前面我們使用 /actuator/env 與 /actuator/refresh 兩個介面可以實現單個服務例項配置的動態更新，但在微服務架構中，服務例項可能達幾十甚至幾百個，一個個呼叫來做動態更新就有點太不方便了。這時就該Spring Cloud Bus登場了。

1.新增依賴與配置

在springcloud-config， 與springcloud-eureka-client兩個專案中，新增spring cloud bus的依賴與配置。在pom.xml檔案中新增依賴

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

在application.yml配置檔案中新增RabbitMQ的相關配置

spring: rabbitmq: host: 127.0.0.1 port: 5672 username: rabbitmq password: passw0rd

2.依次啟動springcloud-eureka， springcloud-config， springcloud-eureka-client專案，並以8081埠再啟動一個springcloud-eureka-client的服務例項。

3.我們使用postman對配置伺服器呼叫/actuator/bus-env介面，

請求兩個服務例項的測試介面，得到結果

兩個例項的Environment物件都已經更新，如果要將@Value註解的屬性也更新，則可再呼叫配置伺服器的/actuator/bus-refresh介面。

/actuator/bus-env介面是直接更新的記憶體Environment例項屬性，如果服務重啟，則又還原到之前的配置了， 所以還是需要藉助配置倉庫來永久更新。配置更新後還需要手動呼叫介面使其生效？DevOps時代了，能自動化的就自動化吧，我們可以藉助Git的webhook機制來實現自動化。

自動化

本文開頭的“使用Spring Cloud Bus來實現服務配置動態更新的結構圖”已經示例了使用Git倉庫的webhook來觸發自動更新配置的流程。但是在Git（如Github）中，我們不能直接使用/actuator/bus-refresh介面來作為webhook（因為介面協議不一致，會出現解析異常），也有人通過提供自己的介面來作為webhook，在自己介面中再轉發請求到/actuator/bus-refresh來實現。但實際上，spring-cloud-config-monitor已經提供了對Git webhook的支援。

如下圖，spring-cloud-config-monitor提供了對Github，Gitlab，Gitee，BitBucket等的支援

1.在配置伺服器springcloud-config的pom.xml檔案中新增依賴

<dependency>    <groupId>org.springframework.cloud</groupId>    <artifactId>spring-cloud-config-monitor</artifactId></dependency>

2.在配置倉庫的設定頁面配置webhook，比如Github的配置如圖

Payload URL 配置為配置伺服器的monitor介面地址，path引數必須。如果你的配置伺服器在內網，比如做本地測試時，還需要實現一下內網穿透（如frp）。在配置倉庫專案中修改配置屬性，提交程式碼，Github webhook就會觸發自動更新，上圖下方紅色框為觸發自動更新的記錄。

自動更新配置未生效排查

如果出現Github觸發了自動更新，但服務的配置更新未生效的情況，則需要檢視webhook的匹配規則與服務例項的ServiceID是否匹配，webhook的匹配規則為 spring.application.name:spring.cloud.config.profile:**，服務例項的ServiceID可通過spring.cloud.bus.id配置，如果沒有配置，則預設為

${vcap.application.name:${spring.application.name:application}}:${vcap.application.instance_index:${spring.application.index:${local.server.port:${server.port:0}}}}:${vcap.application.instance_id:${random.value}}

遵循app:index:id的格式，

app：如果vcap.application.name存在，使用vcap.application.name，否則使用spring.application.name，預設值為applicationindex：優先使用vcap.application.instance_index，如果不存在則依次使用spring.application.index、local.server.port、server.port， 預設值為0id：如果vcap.application.instanceid存在，使用vcap.application.instanceid，否則給一個隨機值

我們可以在服務專案中開啟spring cloud bus的debug日誌

logging: level: org.springframework.cloud.bus: debug

通過DefaultBusPathMatcher的debug日誌來檢視是否匹配，如

DEBUG 286196 --- [7O8XC9KNWbyDA-1] o.s.cloud.bus.DefaultBusPathMatcher : In match: hello-service:8081:c96f04c81dfce6dffaa9d116811d127c, hello-service:8081:c96f04c81dfce6dffaa9d116811d127c

如果沒有匹配則可以按照webhook的匹配規則設定spring.cloud.bus.id值或vcap.application.instance_index值，如

spring: application: name: hello-service cloud: config: discovery: service-id: config-server enabled: true profile: ${spring.profiles.active:default} bus: id: ${spring.application.name}:${spring.cloud.config.profile}:${random.value}#或vcap: application: instance_index: ${spring.cloud.config.profile}

配置更新未生效的另一個情況是檢視是否用了@RefreshScope註解。

@RefreshScope

細心的人會發現本文開頭的測試介面類上加了@RefreshScope註解。 @RefreshScope是Spring Cloud提供的用來實現配置、例項熱載入的註解。被@RefreshScope修飾的@Bean都是延遲載入的，即在第一次訪問（呼叫方法）時才會被初始化，並且這些bean存於快取中。當收到配置更新的訊息時，快取中的@RefreshScope bean會被清除，這樣下次訪問時將會重新建立bean，此時使用的就是最新的配置資訊，從而實現配置的熱載入。

總結

本文分別示例了使用spring boot actuator與spring cloud bus來實現服務配置的更新及兩者之間的區別， spring cloud bus一定程度上像是一個分散式的spring boot actuator。同時演示了使用webhook與spring cloud bus，monitor結合來實現配置自動更新的具體流程及可能遇到的問題。