[菜鳥SpringCloud實戰入門]第七章：配置中心客戶端主動刷新機制 + 配置中心服務化和高可用改造

時間 2019-11-30

標籤菜鳥 springcloud 實戰入門第七配置中心客戶端主動刷新機制服務可用改造简体版

原文原文鏈接

前言

歡迎來到菜鳥SpringCloud實戰入門系列(SpringCloudForNoob)，該系列經過層層遞進的實戰視角，來一步步學習和理解SpringCloud。html

本系列適合有必定Java以及SpringBoot基礎的同窗閱讀。git

每篇文章末尾都附有本文對應的Github源代碼，方便同窗調試。github

Github倉庫地址：web

github.com/qqxx6661/sp…算法

菜鳥SpringCloud實戰入門系列

你能夠經過如下兩種途徑查看菜鳥SpringCloud實戰入門系列：spring

關注個人公衆號：Rude3Knife 點擊公衆號下方：技術推文——SpringCloud
菜鳥SpringCloud實戰入門專欄導航頁(CSDN)

前文回顧：bootstrap

實戰版本

SpringBoot：2.0.3.RELEASE
SpringCloud：Finchley.RELEASE

-----正文開始-----

配置中心客戶端主動刷新機制 + 配置中心服務化和高可用改造

客戶端Refresh：客戶端主動獲取配置信息

通過上一章節配置好Spring Cloud Config後，客戶端（config-client模塊）可以得到從服務端（config-server模塊）傳來的配置文件信息。後端

文末寫出了一個問題，客戶端並不能獲取更新後的配置信息，想要刷新信息，必須重啓config-client模塊，這顯然不切實際。安全

實驗：驗證客戶端沒法更新

下面作一個實驗，啓動客戶端和服務端，隨後更新dev配置文件，新加了（new）：springboot

隨後push到遠程倉庫，咱們再次直接訪問服務端的 http://localhost:8769/spring-cloud-config-dev.properties ：

發現更新成了新的配置文件。

以後訪問客戶端：

發現依然是老的配置文件信息，客戶端只在啓動時獲取了當時的配置文件信息。

開啓更新機制

咱們只須要在config-server模塊中進行改動。

實現Refresh機制須要添加依賴spring-boot-starter-actuator，這個依賴在咱們的root模塊中就已經添加，在config-server模塊就不須要重複添加了。若是你在root父模塊沒有添加，那麼就須要加上。

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
複製代碼

大坑：

對須要刷新的類加上註解@RefreshScope：

當配置更改時，標有@RefreshScope的Bean將獲得特殊處理來生效配置。

注意這裏不是直接加載主類上，除非你的controller寫在了主類裏。

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RefreshScope
public class HelloController {
    @Value("${config.hello}")
    private String hello;

    @RequestMapping("/hello")
    public String from() {
        return this.hello;
    }
}
複製代碼

對於springboot 1.5.X 以上版本，須要在配置文件中關閉安全認證。

management.security.enabled=false
複製代碼

對於springboot 2，上述配置不起做用，須要修改server端配置文件，將端口暴露：

management:
  endpoints:
    web:
      exposure:
        include: "*"
複製代碼

還要將客戶端端口暴露：

management:
  endpoints:
    web:
      exposure:
        include: refresh
複製代碼

測試：

咱們開啓服務端和客戶端，先測試下未更新前獲取的配置信息：

隨後咱們修改配置文件並push：

而後以post請求訪問 curl -v -X POST "http://localhost:8002/actuator/refresh" ：

獲得了：

若是在不變動的狀況下，再次發送POST請求：

使用Webhook監聽配置更新

WebHook是當某個事件發生時，經過發送http post請求的方式來通知信息接收方。Webhook來監測你在Github.com上的各類事件，最多見的莫過於push事件。若是你設置了一個監測push事件的Webhook，那麼每當你的這個項目有了任何提交，這個Webhook都會被觸發，這時Github就會發送一個HTTP POST請求到你配置好的地址。

如此一來，你就能夠經過這種方式去自動完成一些重複性工做，好比，你能夠用Webhook來自動觸發一些持續集成（CI）工具的運做，好比Travis CI；又或者是經過 Webhook 去部署你的線上服務器。下圖就是github上面的webhook配置。

這種機制適用於只有少數微服務的狀況，在大量未服務的狀況下，這種機制就顯得捉襟見肘。

消息總線機制

若是項目少配置少的狀況能夠經過/refresh來手動刷新配置，若是項目比較複雜的狀況呢這種確定是行不通的，Spring Cloud Bus消息總線能夠解決配置修改的真正的動態刷新。咱們放在下一章進行學習。

配置中心服務化和高可用改造

目前咱們的兩個子模塊config-server和config-client是相互耦合的，client須要輸入server的地址來調用它，這樣的調用違反了低耦合原則（低耦合：就是A模塊與B模塊存在依賴關係，那麼當B發生改變時，A模塊仍然能夠正常工做，那麼就認爲A與B是低耦合的。）

如今咱們就是用以前學習的Eureka來對配置中心進行改造。

服務端改造

改造集中在兩方面，一個是在註冊中心註冊，一個是開啓多個服務端達到高可用的目的。

添加依賴（因爲eureka的依賴在咱們的父模塊已經添加，因此對於config-server模塊咱們不須要改動）：

<dependencies>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-config-server</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-eureka</artifactId>
	</dependency>
</dependencies>
複製代碼

配置文件新增註冊配置：

server:
  port: 8769
spring:
  application:
    name: spring-cloud-config-server
  cloud:
    config:
      server:
        git:
          uri: https://xxxxxxxxxxx.git # 配置git倉庫的地址
          search-paths: config-repo                              # git倉庫地址下的相對地址，能夠配置多個，用,分割。
          username: xxxxxx                                     # git倉庫的帳號
          password: xxxxx                                   # git倉庫的密碼
# 客戶端調用須要
management:
  endpoints:
    web:
      exposure:
        include: "*"
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
複製代碼

啓動類添加@EnableDiscoveryClient:

@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }
}
複製代碼

客戶端改造

依賴修改：同服務端相同，咱們不須要修改，父模塊將註冊中心等都已經引入（見第一章）

啓動類添加@EnableDiscoveryClient：同上。

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@SpringBootApplication
@EnableDiscoveryClient
public class ConfigClientApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigClientApplication.class, args);
    }

}
複製代碼

配置文件yml修改：

在前面咱們給config-client子模塊配置了兩個yml文件，一個是傳統application.yml一個是bootstrap.yml，bootstrap.yml的啓動優先於application.yml

咱們修改bootstrap.yml，添加註冊中心配置，並將config的配置加上：

spring.cloud.config.discovery.enabled ：開啓Config服務發現支持
spring.cloud.config.discovery.serviceId ：指定server端的name,也就是server端spring.application.name的值
刪除spring.cloud.config.uri

spring:
  cloud:
    config:
      name: spring-cloud-config
      profile: dev
      label: master
      discovery:
        enabled: true
        service-id: spring-cloud-config-server
eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
複製代碼

隨後咱們啓動三個模塊：