SpringCloud Config Server和Client的配置使用
對於配置的重要性,我想我不用進行任何強調,大家都可以明白其重要性。在普通單體應用,我們常使用配置檔案(application(*).properties(yml))管理應用的所有配置。這些配置檔案在單體應用中非常勝任其角色,並沒有讓我們感覺到有頭疼的地方。但隨著微服務框架的引入,微服務數量就會在我們產品中不斷增加,之前我們重點考慮的是系統的可伸縮、可擴充套件性好,但隨之就是配置管理的問題就會一一暴露出來。起初微伺服器各自管各自的配置,在開發階段並沒什麼問題,但到了生產環境管理就會很頭疼,如果要大規模更新某項配置,困難就可想而知。
為此,在分散式系統中,Spring Cloud提供一個Config子專案,該專案核心就是配置中心,通過一個服務端和多個客戶端實現配置服務。我們可使用配置伺服器集中的管理所有服務的各種環境配置檔案。配置服務中心預設採用Git的方式進行儲存,因此我們很容易部署修改,並可以對環境配置進行版本管理。
Spring Cloud Config具有中心化、版本控制、支援動態更新和語言獨立等特性。其特點是:
- 提供服務端和客戶端支援(Spring Cloud Config Server和Spring Cloud Config Client);
- 集中式管理分散式環境下的應用配置;
- 基於Spring環境,實現了與Spring應用無縫整合;
- 可用於任何語言開發的程式;
- 預設實現基於Git倉庫(也支援SVN),從而可以進行配置的版本管理;
Spring Cloud Config的結構圖如下:
Config-結構圖
從圖中可以看出Spring Cloud Config有兩個角色(類似Eureka): Server和Client。Spring Cloud Config Server作為配置中心的服務端承擔如下作用:
- 拉取配置時更新Git倉庫副本,保證是配置為最新;
- 支援從yml、json、properties等檔案載入配置;
- 配合Eureke可實現服務發現,配合Cloud Bus(這個後面我們在詳細說明)可實現配置推送更新;
- 預設配置儲存基於Git倉庫(可以切換為SVN),從而支援配置的版本管理.
而對於,Spring Cloud Config Client則非常方便,只需要在啟動配置檔案中增加使用Config Server上哪個配置檔案即可。
1. 示例程式碼
1.1 構建Config-Server
編寫POM.XML檔案
Config-Server
pom.xml
也是繼承之前的Parent:
twostepsfromjava.cloud twostepsfromjava-cloud-parent 1.0.0-SNAPSHOT ../parent config-server Spring Cloud Sample Projects: Config Server org.springframework.cloud spring-cloud-config-server
編寫啟動類
/** * TwoStepsFromJava Cloud -- Config Server * * @author CD826([email protected]) * @since 1.0.0 */ @SpringBootApplication @EnableConfigServer public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
這裡最重要的就是增加 @EnableConfigServer
,其它與之前的應用一致。
編寫配置檔案
server.port=8280 spring.application.name=config-server spring.cloud.config.server.git.uri=https://github.com/cd826/SpringcloudSamplesConfig spring.cloud.config.server.git.username=your git username spring.cloud.config.server.git.password=your git password
這裡最重要的是需要配置Git倉庫的地址及登入使用者名稱和口令。
建立測試配置檔案
我們在 SpringcloudSamplesConfig 倉庫中增加量個配置檔案。
mallWeb.properties
,檔案內容如下:
foo = bar
mallWeb-dev.properties
,檔案內容如下:
bar = cd826
注意:這裡編寫檔案後記得提交,否則會測試失敗。
啟動測試
啟動 config-server
. 在終端中我們輸入以下命令(或者使用postman):
curl localhost:8280/mallWeb/dev
在終端中會輸出以下內容:
{"name":"mallWeb","profiles":["dev"],"label":null,"version":null,"state":null,"propertySources":[ {"name":"https://github.com/cd826/SpringcloudSamplesConfig/mallWeb-dev.properties","source":{"bar":"cd826"}}, {"name":"https://github.com/cd826/SpringcloudSamplesConfig/mallWeb.properties","source":{"foo":"bar"}} ]}
這裡可以看到,我們提交到Git中的配置檔案已經能夠被 config-server
正確的讀取到。
CONFIG-SERVER預設配置
當我們檢視原始碼會發現在 spring-cloud-config-server.jar 包中有一個預設配置檔案configserver.yml
配置檔案,也就是說當我們設定 spring.application.name=configserver
時,就會預設載入該配置檔案,該配置檔案內容如下:
info: component: Config Server spring: application: name: configserver jmx: default_domain: cloud.config.server cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo repos: - patterns: multi-repo-demo-* uri: https://github.com/spring-cloud-samples/config-repo server: port: 8888 management: context_path: /admin
預設使用 8888
埠,並且從 https://github.com/spring-cloud-samples/config-repo
這個Git倉庫中查詢配置檔案。
因為,在上面的示例中我們重新定義了應用名稱和服務埠。
1.2 構建config-client
config-client可以是任何一個基於Spring boot的應用,這裡為了講解方便,我們構建一個非常簡單的web工程。
編寫POM.XML檔案
我們的 config-client
專案需要引入對 spring-cloud-starter-config
的依賴,如下:
twostepsfromjava.cloud twostepsfromjava-cloud-parent 1.0.0-SNAPSHOT ../parent config-client Spring Cloud Sample Projects: Config Client org.springframework.cloud spring-cloud-starter-config org.springframework.boot spring-boot-starter-web
編寫啟動類
一個標準的Spring Boot啟動類:
/** * TwoStepsFromJava Cloud -- Config Client Project * * @author CD826([email protected]) * @since 1.0.0 */ @SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
編寫測試CONTROLLER
這個測試Controller主要就是驗證我們可以從Git倉庫中獲取配置內容。
/** * Config Client Test Controller * * @author CD826([email protected]) * @since 1.0.0 */ @RestController @RequestMapping("/cfg") public class ConfigController { @Value("${foo}") String foo; @Value("${bar}") String bar; @RequestMapping(value = "/foo") public String foo(){ return foo + "——" + bar; } }
編寫配置檔案
這裡編寫的配置檔名稱為: bootstrap.properties
,內容如下:
server.port=8080 spring.application.name=mallWeb spring.cloud.config.profile=dev spring.cloud.config.uri= http://localhost:8280/
定義了微服務的名稱和profile以及配置伺服器的地址。
注意: 這些配置不能夠配置在 application.properties
檔案中,因為在Spring Boot啟動時有引導上下文和應用上下文的概念,只有將配置伺服器資訊定義在引導上下文中,才能夠從配置伺服器中獲取到配置資訊。否則,服務啟動時會報找不到foo變數定義的錯誤。
1.3 啟動測試
啟動後我們可以訪問: http://localhost:8080/cfg/foo ,可以看到如下介面:
Config-010
說明,我們的 config-client 已經成功從 config-server 上獲取到配置的資料了。
1.4 Spring專案配置載入順序
- 這裡是列表文字命令列引數
- SPRING_APPLICATION_JSON 引數
- 從java:comp/env 載入 JNDI 屬性
- Java系統屬性 (System.getProperties())
- 作業系統環境變數
- 如果有使用 random.* 屬性配置,則使用 RandomValuePropertySource 產生
- 外部特定應用配置檔案 例如:application-{profile}.properties 或者 YAML variants
- 內部特定應用配置檔案 例如:application-{profile}.properties 或者 YAML variants
- 外部應用配置檔案 例如:application.properties 或者 YAML variants
- 內部應用配置檔案 例如:application.properties 或者 YAML variants
- 載入@Configuration類的 @PropertySource 或者 @ConfigurationProperties 指向的配置檔案
- 預設配置,通過SpringApplication.setDefaultProperties 設定
2. 配置規則詳解
下面我們來看一看Config Client從Config Server中獲取配置資料的流程:
-
- Config Client 啟動時,根據
bootstrap.properties
中配置的應用名稱(application)、環境名(profile)和分支名(label),向 Config Server 請求獲取配置資料;
- Config Client 啟動時,根據
-
- Config Server 根據 Config Client 的請求及配置,從Git倉庫(這裡以Git為例)中查詢符合的配置檔案;
-
- Config Server 將匹配到的Git倉庫拉取到本地,並建立本地快取;
-
- Config Server 建立Spring的
ApplicationContext
例項,並根據拉取的配置檔案,填充配置資訊,然後將該配置資訊返回給 Config Client ;
- Config Server 建立Spring的
-
- Config Client 獲取到 Config Server 返回的配置資料後,將這些配置資料載入到自己的上下文中。同時,因為這些配置資料的優先順序高於本地Jar包中的配置,因此將不再載入本地的配置。
那麼, Config Server 又是如何與Git倉庫中的配置檔案進行匹配的呢?通常,我們會為一個專案建立類似如下的配置檔案:
- mallweb.properties : 基礎配置檔案;
- mallweb-dev.properties : 開發使用的配置檔案;
- mallweb-test.properties : 測試使用的配置檔案;
- mallweb-prod.properties : 生產環境使用的配置檔案;
當我們訪問 Config Server 的端點時,就會按照如下對映關係來匹配相應的配置檔案:
-
- /{application}/{profile}[/{label}]
-
- /{application}-{profile}.yml
-
- /{label}/{application}-{profile}.yml
-
- /{application}-{profile}.properties
-
- /{label}/{application}-{profile}.properties
上面的Url將會對映為格式為:{application}-{profile}.properties(yml)的配置檔案。另外, label 則對應Git上分支名稱,是一個可選引數,如果沒有則為預設的 master 分支。
而 Config-Client 的 bootstrap.properties
配置對應如下:
- spring.application.name application;
- spring.cloud.config.profile profile;
- spring.cloud.config.label label.
2.1 Git倉庫配置
Config Server預設使用的就是Git,所以配置也非常簡單,如上面的配置(application.properties):
spring.cloud.config.server.git.uri=http:// spring.cloud.config.server.git.username=username spring.cloud.config.server.git.password=password
那麼客戶端在請求時服務端就會到該倉庫中進行查詢。
2.1.1 使用佔位符
在服務端配置中我們也可以使用 {application} 、 {profile} 和 {label} 佔位符,如下:
spring.cloud.config.server.git.uri=http://github.com/cd826/{application} spring.cloud.config.server.git.username=username spring.cloud.config.server.git.password=password
這樣,我們就可以為每一個應用客戶端建立一個單獨的倉庫。
這裡需要注意的是,如果Git的分支或標籤中包含"/"時,在{label}引數中需要使用"(_)"替代,這個主要是避免與Http URL轉義符處理的衝突。
2.1.2 使用模式匹配
我們也可以使用 {application} / {profile} 進行模式匹配,以便獲取到相應的配置檔案。配置示例如下:
spring.cloud.config.server.git.uri=https://github.com/spring-cloud-samples/config-repo spring.cloud.config.server.git.repos.simple=https://github.com/simple/config-repo spring.cloud.config.server.git.repos.special.pattern=special*/dev*,*special*/dev* spring.cloud.config.server.git.repos.special.uri=https://github.com/special/config-repo spring.cloud.config.server.git.repos.local.pattern=local* spring.cloud.config.server.git.repos.local.uri=file:/home/configsvc/config-repo
如果模式中需要配置多個值,那麼可以使用逗號分隔。
如果 {application} / {profile} 沒有匹配到任何資源,則使用spring.cloud.config.server.git.uri
配置的預設URI。
當我們使用yml型別的檔案進行配置時,如果模式屬性是一個YAML陣列,也可以使用YAML陣列格式來定義。這樣可以設定成多個配個配置檔案,如:
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo repos: development: pattern: - */development - */staging uri: https://github.com/development/config-repo staging: pattern: - */qa - */production uri: https://github.com/staging/config-repo
2.1.3 搜尋目錄
當我們把配置檔案存放在Git倉庫中子目錄中時,可以通過設定 serch-path
來指定該目錄。同樣,serch-path
也支援上面的佔位符。示例如下:
spring.cloud.config.server.git.uri=https://github.com/spring-cloud-samples/config-repo spring.cloud.config.server.git.searchPaths=foo,bar*
這樣系統就會自動搜尋foo的子目錄,以及以bar開頭的資料夾中的子目錄。
2.1.4 SSH配置
如果你不想使用HTTPS和使用者認證,也可以直接使用SSH,這時候我們只需要將ssh需要的keys儲存在~/.ssh
目錄即可,並將所配置的uri指向SSH地址即可,如:[email protected]:cd826/SpringcloudSamplesConfig
。
如果你清楚的知道你的 ~/.git
目錄,那麼你可以使用 git config --global
來配置。否則可以使用全域性配置,比如: git config --global http.sslVerify false
。
2.1.4 代理
Config-Server會使用JGit訪問配置庫,因此我們可以在 ~/.git/config
下配置HTTPS所使用的代理,也可以使用JVM系統屬性 -Dhttps.proxyHost
和 -Dhttps.proxyPort
來配置。
2.1.5 本地快取
當Config-Server從Git(或SVN)中獲取了配置資訊後,將會在本地的檔案系統中儲存一份。預設將儲存在系統臨時目錄下,並且以 config-repo-
作為開頭,在Linux系統中預設儲存的目錄為 /tmp/config-repo-
。Config-Server將配置資訊儲存在本地可以有效的防止當Git倉庫出現故障而無法訪問的問題,當Config-Server無法訪問到Git倉庫時就會讀取之前儲存在本地檔案中的配置,然後將這些配置資訊返回給Config-Client。比如,當我們斷開網路進行測試,當我們啟動Config-Server時會在控制檯中看到以下輸出:
17:18:01 285 [http-nio-8280-exec-1] WARN o.s.c.c.s.e.MultipleJGitEnvironmentRepository - Could not fetch remote for master remote: https://github.com/cd826/SpringcloudSamplesConfig 17:18:01 660 [http-nio-8280-exec-1] INFO o.s.c.a.AnnotationConfigApplicationContext - Refreshing 17:18:01 710 [http-nio-8280-exec-1] INFO o.s.b.f.a.AutowiredAnnotationBeanPostProcessor - JSR-330 'javax.inject.Inject' annotation found and supported for autowiring 17:18:01 782 [http-nio-8280-exec-1] INFO o.s.c.c.s.e.NativeEnvironmentRepository - Adding property source: file:/Users/cd826/MyWork/springcloud-sample-projects/config/config-server/tmp/mallWeb-dev.properties 17:18:01 782 [http-nio-8280-exec-1] INFO o.s.c.c.s.e.NativeEnvironmentRepository - Adding property source: file:/Users/cd826/MyWork/springcloud-sample-projects/config/config-server/tmp/mallWeb.properties
Spring Cloud 官方文件建議我們在Config-Server中指定本地檔案路徑,以避免出現不可預知的錯誤。可以使用下面的屬性配置來指定本地檔案路徑:
## Git倉庫 spring.cloud.config.server.git.basedir=tmp/ ## SVN倉庫 spring.cloud.config.server.svn.basedir=tmp/
2.2 SVN配置
如果你的專案中使用的是SVN而不是Git,那麼只需要在Config-Server中進行如下修改就可以支援SVN倉庫。
2.2.1 修改POM.XML
在pom檔案中增加以下依賴:
org.tmatesoft.svnkit svnkit
2.2.2 修改APPLIACTION.PROPERTIES
spring.cloud.config.server.svn.uri={your svn server} spring.cloud.config.server.svn.username=username spring.cloud.config.server.svn.password=password
2.3 檔案系統
如果你的Config-Server中不想使用Git或SVN,那麼我們也可以直接從當前classpath或檔案系統中載入相應的配置檔案,只需在配置檔案中設定如下:
spring.profiles.active=native
注意Config-Server預設會從classpath下載入,我們可以使用spring.cloud.config.server.native.searchLocations
屬性來設定配置檔案的目錄。對於檔案路徑,我們的配置必須以 file:
開頭,如果是Windows系統對於絕對路徑我們還得對/進行轉義,比如,在Windows下我們需要配置如下: file:///${user.home}/config-repo
。
此外,當我們使用檔案系統作為配置檔案倉庫時,spring.cloud.config.server.native.searchLocations
的配置也是支援{application} 、{profile} 和 {label} 佔位符的。
Spring Cloud 官方還是推薦在測試和開發的時候可以使用檔案系統,但是在正式環境中儘量還是使用Git或者SVN。
另,Spring Cloud Config中還支援另外一種配置檔案方式:Vault Server,這個後面有空我們再探討。
3. 安全保護
3.1 Config-Server訪問安全
對於我們儲存在配置中心的一些配置內容,總會有一些是敏感資訊,比如資料庫連線的使用者名稱和密碼,你總不能直接裸奔吧,所以我們還是需要對Config-Server做一些安全控制。當然,對於Config-Server的安全控制有很多種,比如:物理網路限制、OAuth2授權等。但是,在這裡因為我們使用的是SpringBoot,所以使用SpringSecurity會更容易也更簡單。這時候,我們只需要在Config-Server中增加如下依賴:
org.springframework.boot spring-boot-starter-security
此時,當我們啟動Config-Server時,SpringSecurity會預設為我們生產一個訪問密碼,這種方式常常不是我們需要的,所以一般我們還需要在配置檔案中配置使用者名稱和密碼,比如:
security.user.name=cd826 security.user.password=pwd
這樣,當我們需要訪問Config-Server時就會彈出使用者認證對話方塊。此時,對於Config-Client我們需要在配置檔案中增加使用者和訪問口令的配置,如下:
spring.cloud.config.username=cd826 spring.cloud.config.password=pwd
3.2 加密與解密
訪問安全是對整體的控制,多數情況下我們還需要對敏感內容加密後儲存,比如之前所說的資料庫訪問的使用者名稱稱和登入口令。很幸運,Spring Cloud Config為我們提供相應的支援。
Spring Cloud Config提供了兩種加解密方式: 1)對稱加密; 2)非對稱加密。在描述如何使用之前,我們先看看一些使用前提。
3.2.1 安裝JCE(JAVA CRYPTOGRAPHY EXTENSION)
Spring Cloud Config所提供的加解密依賴JCE,因為,JDK中沒有預設提供,所以我們需要先安裝JCE。安裝方法也比較簡單,就是下載相應的Jar包,然後把這些包替換 $JDK_HOME/jar/lib/security
相應的檔案,對於JDK8下載地址為:JCE for JDK8.
3.2.2 加解密端點
另外,Spring Cloud Config還提供了兩個端點進行加密和解密,如下:
- /encrypt : 加密端點,使用格式如下:
curl $CONFIG_SERVER/encrypt -d 所要加密的內容
- /decrypt : 解密端點,使用格式如下:
curl $CONFIG_SERVER/decrypt -d 所要解密的內容
注意:當你測試中所加解密中包含特殊字元時,需要進行URL編碼,這時候你需要使用 --data-urlencode
而不是 -d
.
3.2.3 對稱加密
對稱加解密的配置非常簡單。我們只需要在配置檔案中增加加解密所使用的金鑰即可,如:
encrypt.key=cd826_key
配置好之後,你可以啟動Config-Server,並使用上面所說的端點進行加解密測試。
對於,配置檔案我們需要為加密的內容增加一個 {cipher}
前導符。如:
spring.datasource.username=dbuser spring.datasource.password={cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ
但是,如果你使用的配置檔案是yml格式,那麼需要使用單引號把加密內容引起來,如下:
spring: datasource: username:dbuser password:'{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'
3.2.4 非對稱加密
非對稱加密相對於對稱加密來說複雜了一些,首先我們需要藉助Java的keytool生成金鑰對,然後建立Key Store並複製到伺服器目錄下。對於keytool的使用可以參考這裡: 《Spring Cloud入門教程(番外篇四): Keytool證書工具》 。
- 使用keytool生成Key Store,命令如下:
$ keytool -genkeypair -alias tsfjckey -keyalg RSA -dname "CN=Mall Web,OU=TwoStepsFromJava,O=Organization,L=city,S=province,C=china" -keypass javatwostepsfrom -keystore server.jks -storepass twostepsfromjava
-
將所生成
server.jks
拷貝到專案的resources
目錄下(Config-Server)。 -
修改配置檔案:
encrypt.key-store.location=server.jks encrypt.key-store.alias=tsfjckey encrypt.key-store.password=twostepsfromjava encrypt.key-store.secret=javatwostepsfrom
非對稱加密相對於對稱加密來說配置也複雜,但安全性也會高很多。
3.2.5 使用多個加密KEY
也許,我們需要對不同的敏感資訊使用不同的加密key,這時候我們的配置檔案只需要按如下進行編寫:
foo.bar={cipher}{key:testkey}...
Config-Server在解密的時候就會嘗試從配置檔案中獲取 testkey
的做為金鑰。
4. 高可用配置
4.1 整合Eureka
看到這裡,可能有些童鞋已經發現,我們在Config-Client中配置 config.uri
時使用的具體的地址,那麼是否可以使用之前的Eureka呢?答案是肯定,我們可以把Config-Server和其它微服務一樣作為一個服務基本單元。我們只需要進行如下修改即可。
4.1.1 CONFIG-SERVER改造
在pom.xml中增加如下依賴:
org.springframework.cloud spring-cloud-starter-eureka
在配置檔案中配置我們服務的名稱,及之前我們所編寫Eureka伺服器的地址:
spring.application.name=config-server eureka.client.service-url.defaultZone=http://localhost:8260/eureka
啟動類:
/** * TwoStepsFromJava Cloud -- Config Server * * @author CD826([email protected]) * @since 1.0.0 */ @SpringBootApplication @EnableConfigServer @EnableDiscoveryClient public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
增加 @EnableDiscoveryClient
註解。
Ok,到這裡為止,Config-Server修改已經完成。如果我們啟動Config-Server就會在Eureka伺服器上看到相應的服務註冊。
4.1.2 CONFIG-CLIENT改造
在pom.xml中增加如下依賴:
org.springframework.cloud spring-cloud-starter-eureka
配置檔案修改,注意這裡的配置檔案為: bootstrap.properties
:
spring.application.name=mallWeb spring.cloud.config.profile=dev eureka.client.service-url.defaultZone=http://localhost:8260/eureka spring.cloud.config.discovery.enabled=true spring.cloud.config.discovery.service-id=config-server
修改啟動類:
/** * TwoStepsFromJava Cloud -- Config Client Project * * @author CD826([email protected]) * @since 1.0.0 */ @EnableDiscoveryClient @SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
這樣就完成了從Eureka中獲取Config-Server的服務資訊。
這裡最重要的就是在配置中增加: spring.cloud.config.discovery.enabled=true
,並將原來所配置的 spring.cloud.config.uri
,修改為 spring.cloud.config.discovery.service-id
。
4.2 快速失敗與響應
4.2.1 開啟CONFIG-SERVER啟動載入
預設情況下,只有當客戶端請求時服務端才會從配置的Git倉庫中進行載入,我們可以通過設定 clone-on-start
,讓服務端在啟動時就會載入。
spring.cloud.config.server.git.uri=https://git/common/config-repo.git spring.cloud.config.server.git.repos.team-a.pattern=team-a-* spring.cloud.config.server.git.repos.team-a.clone-on-start=true spring.cloud.config.server.git.repos.team-a.uri=http://git/team-a/config-repo.git spring.cloud.config.server.git.repos.team-b.pattern=team-b-* spring.cloud.config.server.git.repos.team-b.clone-on-start=false spring.cloud.config.server.git.repos.team-b.uri=http://git/team-b/config-repo.git spring.cloud.config.server.git.repos.team-c.pattern=team-c-* spring.cloud.config.server.git.repos.team-c.uri=http://git/team-a/config-repo.git
上面的配置,對於 team-a
的則在 Config-Server 啟動時就會載入相應的配置,而對於其它則不會。當然,我們可以通過設定 spring.cloud.config.server.git.clone-on-start
的值來進行全域性配置。
4.2.2 開啟CONFIG-CLIENT快速失敗
在一些情況下,我們希望啟動一個服務時無法連線到服務端能夠快速返回失敗,那麼可以通過下面的配置來設定:
spring.cloud.config.fail-fast=true
4.2.3 設定CONFIG-CLIENT重試
如果在啟動時Config-Server碰巧不可以使用,你還想後面再進行重試,那麼我們開始開啟Config-Client的重試機制。首先,我們需要配置:
spring.cloud.config.fail-fast=true
然後,我們需要在我們的的依賴中增加:
org.springframework.retry spring-retry org.springframework.boot spring-boot-starter-aop
這樣,我們就可以為Config-Client開啟了重試機制,當啟動連線Config-Server失敗時,Config-Client會繼續嘗試連線Config-Server,預設會嘗試連線6次,時間間隔初始為1000毫秒,後面每次嘗試連線會按照1.1倍數增加嘗試連線時間的間隔,如果最後還不能夠連線到Config-Server才會返回錯誤。我們可以通過在配置檔案中複寫 spring.cloud.config.retry.*
來進行相關配置。
如果你想全權控制重試機制,可以實現一個型別為: RetryOperationsInterceptor
的類,並把bean的id設定為: configServerRetryInterceptor
。
4.3 動態重新整理配置
Config-Client中提供了一個 refresh
端點來實現配置檔案的重新整理。要想使用該功能,我們需要在Config-Client的pom.xml檔案中增加以下依賴:
org.springframework.boot spring-boot-starter-actuator
這樣,當修改配置檔案並提交到Git倉庫後,就可以使用: http://localhost:8080/refresh 重新整理本地的配置資料。
但是,最好的方式還是和Spring Cloud Bus進行整合,這樣才能實現配置的自動分發,而不是需要手工去重新整理配置。