使用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也提供了兩個對應的介面

1. /actuator/bus-env，相對於/actuator/env ， 使用鍵值對更新每個例項的Environment，預設不暴露，需配置management.endpoints.web.exposure.include=bus-env 來開放介面訪問
2. /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來實現服務配置動態更新的結構圖如下

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

案例演示

我們還是以前面的springcloud-config， springcloud-eureka， springcloud-eureka-client三個專案來完成本文的案例演示。原始碼地址

使用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
@RefreshScope
public 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，預設值為application
• index：優先使用vcap.application.instance_index，如果不存在則依次使用spring.application.index、local.server.port、server.port， 預設值為0
• id：如果vcap.application.instance_id存在，使用vcap.application.instance_id，否則給一個隨機值

我們可以在服務專案中開啟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結合來實現配置自動更新的具體流程及可能遇到的問題。

---

認真生活，快樂分享！如果你覺得文章對你有幫助，歡迎分享轉發！
歡迎關注微信公眾號：空山新雨的技術空間
獲取Spring Boot，Spring Cloud，Docker等系列技術文章

相關推薦