使用 Spring Cloud Bus 自動重新整理配置

Spring Cloud Bus 是和 Spring Cloud Config 配合起來使用的，Spring Cloud Config 負責提供配置（從 git 倉庫），Spring Cloud Bus 負責重新整理配置（利用 RabbitMQ）。

下面的圖片展示了 Spring Cloud Bus 重新整理流程和使用架構。

一、簡單使用

• 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: 192.168.1.11
      password: zolmk
      username: zolmk
      port: 5672
  

• 注意，還需要暴露 /actuator/bus-refresh（Spring Boot 版本 2.4.0以下） 或者 /actuator/busrefresh（Spring Boot 版本 2.4.0及以上）

• 啟動多個 Spring Cloud Bus 例項，可以在 RabbitMQ 管理介面看到如下資訊，由圖可知，我啟動了四個例項，這些例項各自建立了一個佇列，並且繫結到了 springCloudBus 交換器上。

當我們訪問某個微服務的 /actuator/bus-refresh 時，該微服務中的 bus 會自動向交換器中寫入配置改變訊息，然後訊息入所有交換器繫結的佇列，監聽這些佇列的微服務接收到配置改變訊息，從配置伺服器 Config Server 獲取最新配置。

二、架構演進

用上面的方式實現配置重新整理，但這種方式並不優雅。因為：

• 破壞了微服務的職責單一原則。業務微服務只應關注自身業務，不應該承擔配置重新整理的職責。
• 破壞了微服務各節點的對稱性。
• 有侷限性，因為微服務的 ip 會經常變化。

我們可以讓 Config Server 承擔 重新整理配置的職責。改進的架構圖如下：

三、進階使用

1、區域性重新整理

某些場景下，若只想重新整理部分微服務的配置，可通過 /bus/refresh 端點的 destination 引數來定位要重新整理的應用程式。

例如：

/actuator/bus-refresh?destination=customer:9000，這樣訊息匯流排的例項就會根據 destination 引數的值來判斷是否需要重新整理。其中，customers:9000 指的是各個微服務的 applicationContextID。預設情況下 customers 表示名稱為 customers 的微服務，9000 指微服務執行埠。

2、與 Git 內容同步重新整理

可以通過在 git 伺服器端配置 WebHooks 實現同步重新整理。