您好,登錄后才能下訂單哦!
假如說我們的配置從遠(yuǎn)程倉庫獲取失敗了,那么該如何去處理呢?這里就要使用到 Spring Cloud Config 為我們提的動態(tài)刷新重試功能了,Spring Cloud Config 是服務(wù)化的。那么什么是服務(wù)化呢?
服務(wù)化
我們在前面的配置中,當(dāng) Config Client 需要從 Config Server 上獲取配置數(shù)據(jù)時(shí),我們都是直接在 Config Client 的配置文件中寫上 Config Server 的地址,類似下面這種架構(gòu):
這種寫法相當(dāng)于將 Config Client 和 Config Server 綁定死了,以后 Config Server 的地址不能變,Config Server 也不能掛,否則 Config Client 就獲取不到信息了,而且這種方式也破壞了我們微服務(wù)的整體架構(gòu),即服務(wù)之間互相調(diào)用,獲取對方的信息都是去服務(wù)注冊中心上獲取,所以我們要對這種結(jié)構(gòu)進(jìn)行改造,改造成下面這種結(jié)構(gòu):
當(dāng) Config Server 啟動時(shí),將自己注冊到服務(wù)注冊中心 Eureka 上,所有 Config Client 都從 Eureka 上去獲取 Config Server 的信息,這樣我們就成功將 Config Server 和 Config Client 解耦了,Eureka 在這里依然扮演了數(shù)據(jù)中心的角色。
那么下面我們來演示如何服務(wù)化,大家可以根據(jù)上一篇的例子進(jìn)行改造。當(dāng)然也可以再創(chuàng)建一個(gè)項(xiàng)目來實(shí)現(xiàn)。這里我選擇重新創(chuàng)建來帶著大家來搭建。
首先我們依然是創(chuàng)建一個(gè)cloudConfig-fwh普通maven工程來作為父工程。然后再從cloudConfig-fwh中創(chuàng)建一個(gè)普通的文件夾configRepo來存放github配置文件,然后再分別創(chuàng)建eureka、config_server、config_client。
創(chuàng)建好后,項(xiàng)目結(jié)構(gòu)如下:
然后我們分別將config_client 和 config_server 注冊到eureka實(shí)例上。
我們訪問localhost:7000
發(fā)現(xiàn)已經(jīng)注冊上去了。
那么我們還需要對Config Client配置,這里我們在bootstrap.yml中配置,bootstrap.yml優(yōu)先級比application.yml高,spring cloud config 優(yōu)先配置都會放在這里:
bootstrap.yml 配置如下:
spring: application: name: config-server # 本地配置 # profiles: # active: native cloud: config: profile: dev label: master discovery: service-id: config-server3 enabled: true server: port: 8002 eureka: client: service-url: defaultZone: http://localhost:7000/eureka/
這里新增的兩個(gè)配置我說一下,其中discovery.service-id
代替了原來的cloud.config.uri
原來的uri需要寫很長。而且如果ip地址端口號發(fā)生了變化,那么還需要去Config Server去修改,這里使用了service-id完美了解決了這個(gè)問題。通過service-id去eureka中心尋找Config Server的實(shí)例。discovery.enabled=true
是開啟通過eureka來獲取Config Server。
注意這里有一個(gè)小坑。就是這個(gè)spring.application.name的名稱是你在github倉庫的配置文件的前綴如下圖:
這里取config-server就可以了。
配置好了后,我們訪問http://localhost:8002/love
訪問結(jié)果如下:
這樣就訪問成功了,說明我們的配置沒有問題。下面我們來說一下動態(tài)刷新。
動態(tài)刷新
接下來我們再來看一下配置文件動態(tài)刷新的問題,當(dāng) Git 倉庫中配置文件發(fā)生改變后,如果我們刷新 Config Server 中的請求地址,會發(fā)現(xiàn)數(shù)據(jù)也跟著變化了,即 Config Server 是能夠及時(shí)感知到配置文件的變化的,但是這種感知卻不能夠傳遞到 Config Client 中去,即 Config Client 是無法及時(shí)感知到配置文件的變化的,默認(rèn)情況下,只有 Config Client 重啟,才能夠加載到最新的配置文件數(shù)據(jù),如何讓 Config Client 也能動態(tài)刷新配置數(shù)據(jù)呢?
我們只需要在Config Client 中加入如下依賴就能動態(tài)刷新配置:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
添加完成后我們還需要對refresh接口暴露,這里注意,除了G版本的Cloud需要額外手動的暴露refresh接口外,其它版本的Cloud不用配置下面這段配置來進(jìn)行手動暴露
management: endpoints: web: exposure: include: 'refresh'
這里配置好了后,我們對HelloController增加一個(gè)注解@RefreshScope
當(dāng)調(diào)用refresh
接口當(dāng)時(shí)候動態(tài)刷新:
@RefreshScope @RestController public class HelloController { @Value("${love}") String love; @GetMapping("/love") public String name() { return love; } }
配置好了后,我們重啟Config Client項(xiàng)目,然后可以看到idea的控制臺/actuator/refresh
接口已經(jīng)暴露出來了。
這個(gè)接口用來動態(tài)刷新配置文件。
當(dāng)然配置好了這個(gè)動態(tài)刷新接口,我們肯定要訪問來測試下。接口是否正常。
我們訪問http://localhost:8002/actuator/refresh
注意這里使用post請求訪問,如果如下圖一樣就說明接口正常:
但細(xì)心的人可能這里會發(fā)現(xiàn)一個(gè)問題,不重啟Config Client的情況下,也能實(shí)現(xiàn)動態(tài)刷新配置,但是所有的微服務(wù)都要一個(gè)個(gè)的去發(fā)送/actuator/refresh
接口請求,很麻煩,那么有什么簡便的方式呢?肯定是有的下面我會介紹。
請求失敗重試
請求失敗了肯定要重試啊,不可能失敗了,就讓它一直失敗。這肯定是不行的。細(xì)心的朋友看過我之前的文章的話,我是講了如何失敗重試的,比如網(wǎng)絡(luò)的波動,當(dāng)網(wǎng)絡(luò)質(zhì)量很差的情況下,就會導(dǎo)致服務(wù)調(diào)用的失敗。那么我們就要做到請求失敗了,就要重試。
要實(shí)現(xiàn)失敗重試也是非常簡單的,之前看過我文章的朋友,肯定知道這里需要加兩個(gè)依賴:
<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency>
加上這個(gè)依賴后,我們需要在Config Client 的bootstrap.yml中加入如下配置:
fail-fast: true
這個(gè)配置的意思是失敗快速響應(yīng),在默認(rèn)情況下 我們的Config Client 去訪問Config Server 失敗時(shí)候,并不會馬上報(bào)錯(cuò)
而是要等到使用到Config Server 的某個(gè)數(shù)據(jù)
的時(shí)候才會報(bào)錯(cuò)
,通俗的意思就是我們之前不是有個(gè)love變量嗎?如果這個(gè)love變量并不存在,而我們的Config Client又在調(diào)用使用的話,那么就會報(bào)錯(cuò)并拋出異常。所以當(dāng)我們的Config Client 訪問 Config Server 失敗的時(shí)候,就要開啟快速響應(yīng),這里可以是失敗重試,也可以拋出自定義異常信息。
添加完這個(gè)配置之后,為了演示執(zhí)行效果,接下來我們再做一點(diǎn)點(diǎn)修改,由于目前我們的 Config Server 是有安全認(rèn)證的,Config Client 必須要有用戶名密碼才能訪問到 Config Server 中的數(shù)據(jù)。我們暫時(shí)先注釋掉 Config Client 中訪問 Config Server 的用戶名密碼,即如下兩行:
#spring: # cloud: # config: # username: jishu # password: 123456
這里的username 和 password 是在Config Server 中配置的Security的賬戶密碼信息,這里我們注釋掉后,重啟Config Client 項(xiàng)目,我們來看下失敗重試的效果:
可以看到,一共發(fā)了6次請求,第一失敗后,還繼續(xù)重試了5次,這就是默認(rèn)的請求策略,我們可以配置請求策略:
spring: cloud: config: retry: initial-interval: 1000 multiplier: 1.1 max-interval: 2000
這四個(gè)配置解釋如下:
開啟了請求重試機(jī)制之后,即使在弱網(wǎng)環(huán)境下,我們也能有效保證服務(wù)的可用性。
總結(jié)
本文主要向大家介紹了分布式配置中心 Spring Cloud Config 中三個(gè)常見的問題,服務(wù)化、配置數(shù)據(jù)動態(tài)刷新以及請求失敗重試。服務(wù)化降低了 Config Server 和 Config Client 之間的耦合度,使我們的項(xiàng)目架構(gòu)更加規(guī)范;動態(tài)刷新則讓我們在不重啟 Config Client 的情況下,能夠刷新配置數(shù)據(jù);最后的請求重試則保證了弱網(wǎng)環(huán)境下服務(wù)的可用性,在實(shí)際生產(chǎn)項(xiàng)目中,這三個(gè)基本上也都是必配的,大家需要認(rèn)真掌握。
項(xiàng)目地址
github
以上就是本文的全部內(nèi)容,希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持億速云。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。