SpringCloud 之Bus訊息匯流排

流程總結

架構優化

之前使用actuator監控中心完成重新整理功能，但是在config client服務端需要傳送post請求來手動重新整理，如果config client有很多的話，那麼需要乙個乙個地傳送post請求，這顯然是不現實的做法。

使用訊息佇列中的topic，通過訊息實現通知。

目前spring cloud bus訊息匯流排只是實現了對rabbitmq以及kafka的支援。

需要裝rabbitmq

參考《rabbitmq教程》

在pom檔案加上起步依賴spring-cloud-starter-bus-amqp。

>
>
org.springframework.cloudgroupid
>
>
spring-cloud-starter-bus-amqpartifactid
>
dependency
>

在bootstrap.yml新增rabbitmq的配置

spring:: name : config-client cloud :bus :enabled :true trace :enabled :true rabbitmq :host : 127.0.0.1 port :5672 username : guest password : guest #開啟所有端點 management :endpoints :web :exposure :include :"*"

保證rabbit的服務開啟。

rabbitmq後台管理：

帳號密碼：guest/guest

啟動config-client工程後檢視rabbitmq中的交換機：

檢視佇列：

檢視該佇列繫結到了springcloudbus

修改config-client服務的埠，再啟動乙個config-client例項，進行測試。

發現，有2個佇列，分別都繫結到springcloudbus的交換機。

在git上修改配置檔案的內容進行測試。

然後傳送post請求：curl -x post http://localhost:8096/actuator/bus-refresh

會發現所有config-client的配置都更新了。

更新檔案到git伺服器，傳送post請求/bus/refresh，例項將訊息傳送到springcloudbus的交換機，由於這個例項的佇列頁繫結到交換機，所以其他例項也獲取到了更新的通知，然後去config server獲取最新的資料。

在前面實現的架構中，config-client例項應該是乙個具體業務相關的服務，但是我們讓它負責了傳送更新的訊息到rabbitmq。

這其實是違反了微服務架構中的職責單一的原則。

其實這個架構是可以改進的，就是將原有的config server不僅僅提供配置查詢的服務，而且還要負責更新訊息的傳送。

匯入依賴。

>
>
org.springframework.bootgroupid
>
>
spring-boot-starter-actuatorartifactid
>
dependency
>
>
>
org.springframework.cloudgroupid
>
>
spring-cloud-starter-bus-amqpartifactid
>
dependency
>

然後config-server服務上傳送actuator/bus-refreshpost請求就可以將配置更新到所有的config-client服務上。

SpringCloud 之Bus訊息匯流排

SpringCloud學習十三 Bus

Spring Cloud 訊息匯流排 Bus

Spring Cloud中bus元件配置

SpringCloud 之Bus訊息匯流排

SpringCloud學習 十三 Bus

Spring Cloud 訊息匯流排 Bus

Spring Cloud中bus元件配置

相關推薦

SpringCloud學習十三 Bus