假如說我們的配置從遠(yuǎn)程倉庫獲取失敗了，那么該如何去處理呢？這里就要使用到 Spring Cloud Config 為我們提的動(dòng)態(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 啟動(dòng)時(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)先配置都會(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è)配置我說一下，其中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é)果如下：

這樣就訪問成功了，說明我們的配置沒有問題。下面我們來說一下動(dòng)態(tài)刷新。

動(dòng)態(tài)刷新

接下來我們再來看一下配置文件動(dòng)態(tài)刷新的問題，當(dāng) Git 倉庫中配置文件發(fā)生改變后，如果我們刷新 Config Server 中的請求地址，會(huì)發(fā)現(xiàn)數(shù)據(jù)也跟著變化了，即 Config Server 是能夠及時(shí)感知到配置文件的變化的，但是這種感知卻不能夠傳遞到 Config Client 中去，即 Config Client 是無法及時(shí)感知到配置文件的變化的，默認(rèn)情況下，只有 Config Client 重啟，才能夠加載到最新的配置文件數(shù)據(jù)，如何讓 Config Client 也能動(dòng)態(tài)刷新配置數(shù)據(jù)呢？

我們只需要在Config Client 中加入如下依賴就能動(dòng)態(tài)刷新配置：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

添加完成后我們還需要對refresh接口暴露，這里注意，除了G版本的Cloud需要額外手動(dòng)的暴露refresh接口外，其它版本的Cloud不用配置下面這段配置來進(jìn)行手動(dòng)暴露

management:
 endpoints:
  web:
   exposure:
    include: 'refresh'

這里配置好了后，我們對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)暴露出來了。

這個(gè)接口用來動(dòng)態(tài)刷新配置文件。

當(dāng)然配置好了這個(gè)動(dòng)態(tài)刷新接口，我們肯定要訪問來測試下。接口是否正常。
我們訪問http://localhost:8002/actuator/refresh 注意這里使用post請求訪問，如果如下圖一樣就說明接口正常：

但細(xì)心的人可能這里會(huì)發(fā)現(xiàn)一個(gè)問題，不重啟Config Client的情況下，也能實(shí)現(xiàn)動(dòng)態(tài)刷新配置，但是所有的微服務(wù)都要一個(gè)個(gè)的去發(fā)送/actuator/refresh 接口請求，很麻煩，那么有什么簡便的方式呢？肯定是有的下面我會(huì)介紹。

請求失敗重試

請求失敗了肯定要重試啊，不可能失敗了，就讓它一直失敗。這肯定是不行的。細(xì)心的朋友看過我之前的文章的話，我是講了如何失敗重試的，比如網(wǎng)絡(luò)的波動(dòng)，當(dāng)網(wǎng)絡(luò)質(zhì)量很差的情況下，就會(huì)導(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í)候，并不會(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 訪問 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è)配置解釋如下:

• max-attempts 表示最大請求次數(shù)，默認(rèn)值為 6 ，就是大家在上圖看到的情況
• initial-interval 表示請求重試的初始時(shí)間間隔
• multiplier 表示時(shí)間的間隔乘數(shù)，由于網(wǎng)絡(luò)抖動(dòng)一般都是有規(guī)律的，為了防止請求重試時(shí)連續(xù)的沖突，我們需要一個(gè)時(shí)間間隔乘數(shù)，這里我設(shè)置了間隔乘數(shù)為 1.2 ，表示第一次重試間隔時(shí)間為 1 s，第二次間隔時(shí)間為 1.2 秒，第三次間隔時(shí)間為 1.44 秒…
• max-interval 表示重試的最大間隔時(shí)間
  

開啟了請求重試機(jī)制之后，即使在弱網(wǎng)環(huán)境下，我們也能有效保證服務(wù)的可用性。

總結(jié)

本文主要向大家介紹了分布式配置中心 Spring Cloud Config 中三個(gè)常見的問題，服務(wù)化、配置數(shù)據(jù)動(dòng)態(tài)刷新以及請求失敗重試。服務(wù)化降低了 Config Server 和 Config Client 之間的耦合度，使我們的項(xiàng)目架構(gòu)更加規(guī)范；動(dòng)態(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í)有所幫助，也希望大家多多支持腳本之家。

最新評論