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