本文是Spring Cloud專欄的第十二篇文章,瞭解前十一篇文章內容有助於更好的理解本文:html
Spring Cloud第四篇 | 客戶端負載均衡Ribbonbootstrap
因爲在沒有使用消息總線的時候,咱們若是須要修改某個配置,若是涉及修改的微服務節點比較多,咱們須要手動的一個節點一個節點的刷新很是麻煩,在微服務架構的系統中,咱們一般會使用輕量級的消息代理來構建一個共用的消息主題讓系統中全部微服務實例都鏈接上來,因爲該主題中產生的消息會被全部實例監聽和消費,因此咱們稱它爲消息總線。在總線上的各個實例均可以方便地廣播一些須要讓其餘鏈接在該主題上的實例都知道的消息,例如配置信息的變動或者其餘一些管理操做等。
因爲消息總線在微服務架構系統中被普遍使用,因此它同配置中心同樣,幾乎是微服務架構中的必備組件。Spring Cloud做爲微服務架構綜合性的解決方案,對此天然也有本身的實現,經過使用Spring Cloud Bus能夠很是容易地搭建起消息總線,同時實現了一些消息總線中的經常使用功能,好比配合Spring Cloud Config實現微服務應用配置信息的動態更新等,架構如圖所示:
目前版本,Spring Cloud Bus僅支持兩款中間件產品,RabbitMQ和Kafka,本案例使用RabbitMQ實現Spring Cloud Bus的應用
RabbitMQ安裝步驟以及使用自行百度啦。。。
一、修改之前的springcloud-config-server,springcloud-config-client塊添加消息總線依賴,actuator依賴在前幾篇案例中已經在父模塊(springcloud-learn)中引入,此處不須要再次引入
<!--spring cloud bus 整合rabbitmq --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId> </dependency>
二、rabbitmq服務地址:http://47.112.11.147:15672/ rabbitmq用戶名爲:admin密碼爲:123456
三、在springcloud-config-server模塊基礎上往application.yml添加bus和rabbitmq的相關配置以及暴露bus-refresh端點
spring: cloud: bus: #控制bus消息總線是否能用 enabled: true #打開bus追蹤 trace: enabled: true rabbitmq: addresses: 47.112.11.147 port: 5672 username: admin password: 123456 virtual-host: / management: endpoints: web: exposure: include: ["info","health","bus-refresh"]
四、在springcloud-config-client模塊基礎上往application.yml添加rabbitmq相關配置就好了
spring: rabbitmq: addresses: 47.112.11.147 port: 5672 username: admin password: 123456 virtual-host: /
五、啓動配置中心服務端(springcloud-config-server)查看bus相應的轉換器Exchange以及Type對應的topic,而且同時在控制檯上經過日誌能夠看到bus-refresh端點暴露出來了
RabbitMQ的Topic模式如圖所示:
若是不懂RabbitMQ的話也不影響你的Bus使用
查看rabbitmq控制檯看到bus相應對列建立了
查看綁定關係,springcloud bus相應對列已經綁定到了springcloud bus轉換器上了
六、啓動配置中心客戶端(springcloud-config-client)能夠看到該對列也綁定到spirngcloud bus轉換器上了
七、咱們在複製springcloud-config-client的配置,新建文件bootstrap-configclient8882.yml配置文件以下,創鍵啓動類啓動SpringcloudConfigClient8882Application
server: port: 8882 spring: application: name: springcloud-config-client cloud: config: #uri則表示配置中心的地址 #uri: http://localhost:8888 #注:config 客戶端在沒有 spring.cloud.config.name屬性的時候,服務端{application} 獲取的是客戶端 #spring.application.name的值,不然,獲取的是 spring.cloud.config.name的值。 #1)、當沒有spring.cloud.config.name時,客戶端獲取的是spring.application.name 所對應的git庫中的文件,而且只能 #獲取一個文件, #2)、當一個項目中有需求要獲取多個文件時,就須要用到spring.cloud.config.name這個屬性,以逗號分割 name: configclient profile: dev #label對應了label部分 label: master # username: coding-farmer # password: 123456 discovery: #表示開啓經過服務名來訪問config-server enabled: true #則表示config-server的服務名 service-id: springcloud-config-server #失敗快速響應 fail-fast: true retry: #配置重試次數,默認爲6 max-attempts: 6 #初始重試間隔時間,默認1000ms initial-interval: 1000 #間隔乘數,默認1.1 multiplier: 1.1 #最大間隔時間,默認2000ms max-interval: 2000 rabbitmq: addresses: 47.112.11.147 port: 5672 username: admin password: 123456 virtual-host: / eureka: client: service-url: defaultZone: http://localhost:8700/eureka #客戶端每隔30秒從Eureka服務上更新一次服務信息 registry-fetch-interval-seconds: 30 #須要將個人服務註冊到eureka上 register-with-eureka: true #須要檢索服務 fetch-registry: true #心跳檢測檢測與續約時間 instance: #告訴服務端,若是我10s以內沒有給你發心跳,就表明我故障了,將我剔除掉,默認90s #Eureka服務端在收到最後一次心跳以後等待的時間上限,單位爲秒,超過則剔除(客戶端告訴服務端按照此規則等待本身) lease-expiration-duration-in-seconds: 10 #每隔2s向服務端發送一次心跳,證實自已依然活着,默認30s #Eureka客戶端向服務端發送心跳的時間間隔,單位爲秒(客戶端告訴服務端本身會按照該規則) lease-renewal-interval-in-seconds: 2 # 啓用ip配置 這樣在註冊中心列表中看見的是以ip+端口呈現的 prefer-ip-address: true # 實例名稱 最後呈現地址:ip:2002 instance-id: ${spring.cloud.client.ip-address}:${server.port} management: endpoints: web: exposure: include: ["info","health","refresh"]
八、碼雲倉庫值默認以下
訪問http://localhost:8881/index
訪問http://localhost:8882/index
九、修改倉庫內容
而後向springcloud-config-server服務bus-refresh端點發送POST請求http://localhost:8888/actuator/bus-refresh
十、再次訪問客戶端8881,882顯示以下
在上面案例中咱們看到當你觸發/actuator/bus-refresh端點時,它就會刷新全部實例的服務配置,有時候咱們可能只須要刷新某個具體的實例。
Spring Cloud Bus對這種場景也有很好的支持,/actuator/bus-refresh/{destination}接口提供了一個destination參數,RESTFUL風格請求,用來定位具體要刷新的應用程序。好比:咱們能夠請求/actuator/bus-refresh/springcloud-config-client:8882,此時總線上的各應用實例會根據destination屬性的值來判斷是否爲本身的實例名,若符合才進行配置刷新,若不符合就忽略該消息。
destination參數除了能夠定位具體的實例以外,還能夠用來定位具體的服務。定位服務的原理是經過使用Spring的PathMatecher(路徑匹配)來實現的,好比/actuator/bus-refresh/springcloud-config-client:**,該請求會觸發customers服務的全部實例進行刷新。
一、之前倉庫信息爲:
例如:修改成以下
二、向http://localhost:8888/actuator/bus-refresh/springcloud-config-client:8882發送POST請求
三、訪問客戶端8881,8882服務內容以下
使用/actuator/bus-refresh發送到咱們其中一個config-client中也能刷新配置(前提是該客戶端的bus-refresh端點須要暴露出來),可是這樣這個實例就跟其餘實例不同了,它還額外承擔了刷新配置的功能。因此,咱們將發送post請求刷新配置的任務交由config-server配置服務中心來處理,這樣全部服務實例都是對等的,由配置服務中心發送消息通知消息總線更新整個集羣中的配置。這樣,服務實例就不須要再承擔觸發配置更新的任務。儘量讓服務集羣中的各個節點是對等的未來利於運維工做。
詳細參考案例源碼:https://gitee.com/coding-farmer/springcloud-learn
原文出處:https://www.cnblogs.com/coding-farmer/p/12080563.html