Spring Boot + Spring Cloud 實現權限管理系統後端篇（二十三）：配置中心（Config、Bus）

時間 2019-11-06

標籤 spring boot cloud 實現權限管理系統後端二十三配置中心 config bus 欄目 Spring 简体版

原文原文鏈接

在線演示

演示地址：http://139.196.87.48:9002/kittyhtml

用戶名：admin 密碼：admin前端

技術背景

現在微服務架構盛行，在分佈式系統中，項目日益龐大，子項目日益增多，每一個項目都散落着各類配置文件，且隨着服務的增長而不斷增多。此時，每每某一個基礎服務信息變動，都會致使一系列服務的更新和重啓，運維也是苦不堪言，並且還很容易出錯。因而，配置中心便由此應運而生了。java

目前市面上開源的配置中心有不少，像Spring家族的Spring Cloud Config， Apache的Apache Commons Configuration，淘寶的diamond，百度的disconf， 360的QConf等等，都是爲了解決這類問題。當下Spring體系大行其道，咱們固然也優先選擇Spring Cloud Config了。git

Spring Cloud Config

Spring Cloud Config 是一套爲分佈式系統中的基礎設施和微服務應用提供集中化配置的管理方案，它分爲服務端與客戶端兩個部分。服務端也稱爲分佈式配置中心，它是一個獨立的微服務應用，用來鏈接配置倉庫併爲客戶端提供獲取配置信息。客戶端則是微服務架構中的各個微服務應用或基礎設施，它們經過指定的配置中心來管理服務相關的配置內容，並在啓動的時候從配置中心獲取和加載配置信息。web

Spring Cloud Config對服務端和客戶端中的環境變量和屬性配置實現了抽象映射，因此它除了適用於 Spring 應用，也是能夠在任何其餘語言應用中使用的。Spring Cloud Config 實現的配置中心默認採用 Git 來存儲配置信息，因此使用 Spring Cloud Config 構建的配置服務器，自然就支持對微服務應用配置信息的版本管理，而且能夠經過 Git 客戶端工具很是方便的管理和訪問配置內容。固然它也提供了對其餘存儲方式的支持，好比：SVN 倉庫、本地化文件系統等。spring

實現案例

準備配置文件

首先在GIT下，新建config-repo目錄，用來存放配置文件，以下圖所示，分別模擬了三個環境的配置文件。docker

分別編輯三個文件，配置 comsumer.hello 屬性的值爲 comsumer.hello=hello, this is xx configurations.bootstrap

服務端實現

新建工程

新建 kitty-conifg 工程，做爲配置中心的服務端，負責把GIT倉庫的配置文件發佈爲RESTFul接口。後端

添加依賴

除了Spring Cloud依賴以外，添加配置中心依賴包。跨域

pom.xml

<!--spring config-->
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-server</artifactId>
    </dependency>
</dependencies>

啓動類

啓動類添加註解 @EnableConfigServer，開啓配置服務支持。

KittyConfigApplication.java

package com.louis.kitty.config;

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

@EnableConfigServer
@EnableDiscoveryClient
@SpringBootApplication
public class KittyConfigApplication {

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

配置文件

修改配置文件，添加以下內容。若是是私有倉庫須要填寫用戶名密碼，若是是公開倉庫，能夠不配置密碼。

application.yml

server:
  port: 8020
spring:
  application:
    name: kitty-config
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        serviceName: ${spring.application.name}    # 註冊到consul的服務名稱
    config:
　　   label: master  # git倉庫分支
      server:
        git:
          uri: https://gitee.com/liuge1988/kitty.git  # 配置git倉庫的地址
          search-paths: config-repo  # git倉庫地址下的相對地址，能夠配置多個，用,分割。
          username: username  # git倉庫的帳號
          password: password  # git倉庫的密碼

Spring Cloud Config也提供本地存儲配置的方式，只需設置屬性spring.profiles.active=native，Config Server會默認從應用的src/main/resource目錄下檢索配置文件。另外也能夠經過spring.cloud.config.server.native.searchLocations=file:D:/properties/屬性來指定配置文件的位置。雖然Spring Cloud Config提供了這樣的功能，可是爲了更好的支持內容管理和版本控制，仍是比較推薦使用GIT的方式。

測試效果

啓動註冊中心，配置中心，訪問 http://localhost:8020/kitty-consumer/dev，返回結果以下。

{
    "name": "kitty-consumer",
    "profiles": ["dev"],
    "label": null,
    "version": "1320259308dfdf438f5963f95cbce9e0a76997b7",
    "state": null,
    "propertySources": [{
        "name": "https://gitee.com/liuge1988/kitty.git/config-repo/kitty-consumer-dev.properties",
        "source": {
            "consumer.hello": "hello, this is dev configurations. "
        }
    }]
}

訪問 http://localhost:8020/kitty-consumer/pro，返回結果以下。

{
    "name": "kitty-consumer",
    "profiles": ["pro"],
    "label": null,
    "version": "1320259308dfdf438f5963f95cbce9e0a76997b7",
    "state": null,
    "propertySources": [{
        "name": "https://gitee.com/liuge1988/kitty.git/config-repo/kitty-consumer-pro.properties",
        "source": {
            "consumer.hello": "hello, this is pro configurations. "
        }
    }]
}

上述的返回的信息包含了配置文件的位置、版本、配置文件的名稱以及配置文件中的具體內容，說明server端已經成功獲取了git倉庫的配置信息。

訪問：http://localhost:8020/kitty-consumer-dev.properties，返回結果以下。

修改一下dev配置文件內容以下（末尾加了一個 2）：

再次訪問：http://localhost:8020/kitty-consumer-dev.properties，返回結果以下。

發現讀取的是修改後提交的信息，說明服務端會自動讀取最新提交的數據。

倉庫中的配置文件會被轉換成相應的WEB接口，訪問能夠參照如下的規則：

/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties

以kitty-consumer-dev.properties爲例子，它的application是kitty-consumer，profile是dev。client會根據填寫的參數來選擇讀取對應的配置。

客戶端實現

添加依賴

打開kitty-consumer工程，添加相關依賴。

pom.xml

<!-- spring-cloud-config -->
<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

配置文件

添加一個bootstrap.yml配置文件，添加配置中心，並把註冊中心的配置移到這裏，由於在經過配置中心查找配置時須要經過註冊中心的發現服務。

bootstrap.yml

spring:
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        serviceName: ${spring.application.name}    # 註冊到consul的服務名稱
    config:
      discovery:
        enabled: true  # 開啓服務發現
        serviceId: kitty-config # 配置中心服務名稱
      name: kitty-consumer  # 對應{application}部分
      profile: dev  # 對應{profile}部分
      label: master  # 對應git的分支，若是配置中心使用的是本地存儲，則該參數無用

配置說明：

spring.cloud.config.uri：配置中心的具體地址
spring.cloud.config.name：對應{application}部分
spring.cloud.config.profile：對應{profile}部分
spring.cloud.config.label：對應git的分支。若是配置中心使用的是本地存儲，則該參數無用
spring.cloud.config.discovery.service-id：指定配置中心的service-id，便於擴展爲高可用配置集羣。

特別注意：

上面這些與spring cloud相關的屬性必須配置在bootstrap.yml中，這樣config部份內容才能被正確加載。

由於config的相關配置會先於application.yml，而bootstrap.yml的加載也是先於application.yml文件的。

application.yml

server:
  port: 8005
spring:
  application:
    name: kitty-consumer
  boot:
    admin:
      client:
        url: "http://localhost:8000"
  zipkin:
    base-url: http://localhost:9411/
  sleuth:
    sampler:
      probability: 1 #樣本採集量，默認爲0.1，爲了測試這裏修改成1，正式環境通常使用默認值
# 開放健康檢查接口
management:
  endpoints:
    web:
      exposure:
        include: "*"
  endpoint:
    health:
      show-details: ALWAYS
#開啓熔斷器
feign:
  hystrix:
    enabled: true

控制器

添加一個 SpringConfigController 控制器，添加註解 @Value("${comsumer.hello}")，聲明hello屬性從配置文件讀取。

SpringConfigController.java

package com.louis.kitty.consumer.controller;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
class SpringConfigController {
    
    @Value("${comsumer.hello}")
    private String hello;

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

測試效果

啓動註冊中心、配置中心，訪問： http://localhost:8500，確認相關服務啓動並註冊。

訪問 http://localhost:8005/hello，返回結果。

說明客戶端已經成功從服務端讀取了配置信息。

如今手動修改一下倉庫配置文件的內容，移除末尾數字 2，修改完成並提交。

再次訪問 http://localhost:80052/hello，效果以下。

咱們發現返回結果並無讀取最新提交的內容，這是由於Spring Boot項目只有在啓動的時候纔會獲取配置文件的內容，雖然GIT配置信息被修改了，可是客戶端並無從新去獲取，因此致使讀取的信息仍然是舊配置。那麼該如何去解決這個問題呢？這就是咱們下一章要講的 Spring Cloud Bus。

Refresh機制

咱們在上面講到，Spring Boot程序只在啓動的時候加載配置文件信息，這樣在GIT倉庫配置修改以後，雖然配置中心服務器可以讀取最新的提交信息，可是配置中心客戶端卻不會從新讀取，以致於不能及時的讀取更新後的配置信息。這個時候就須要一種通知刷新機制來支持了。

refresh機制是Spring Cloud Config提供的一種刷新機制，它容許客戶端經過POST方法觸發各自的/refresh，只要依賴spring-boot-starter-actuator包就擁有了/refresh的功能，下面咱們爲咱們的客戶端加上刷新功能，以支持更新配置的讀取。

添加依賴

咱們的 kitty-consumer 在以前已經添加過actuator依賴，因此這裏就不用添加了，若是以前沒有添加須要加上。actuator是健康檢查依賴包，依賴包裏攜帶了 /refresh 的功能。

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

在使用配置屬性的類型加上 @RefreshScope 註解，這樣在客戶端執行 /refresh 的時候就會刷新此類下面的配置屬性了。

package com.louis.kitty.consumer.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;

@RefreshScope
@RestController
class SpringConfigController {
    
    @Value("${consumer.hello}")
    private String hello;

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

修改配置

健康檢查接口開放須要在配置文件添加如下內容，開放refresh的相關接口，由於這個咱們在以前也配置過了，因此也不需添加了。

management:
  endpoints:
    web:
      exposure:
        include: "*"

經過上面的接口開放配置，之後以post請求的方式訪問 http://localhost:8005/actuator/refresh 時，就會更新修改後的配置文件了。

特別注意：

這裏存在着版本大坑，1.x跟2.x的配置不太同樣，咱們用的是2.0+版本，務必注意。

1.安全配置變動

新版本

management.endpoints.web.exposure.include="*"

老版本

management.security.enabled=false

2.訪問地址變動

新版本

http://localhost:8005/actuator/refresh

老版本

http://localhost:8005/refresh

這裏仍是解釋一下上面這個配置起到了什麼具體做用，其實actuator是一個健康檢查包，它提供了一些健康檢查數據接口，refresh功能也是其中的一個接口，可是爲了安全起見，它默認只開放了health和info接口（啓動信息會包含以下圖所示信息），而上面的配置就是設置要開放哪些接口，咱們設置成「*」，是開放全部接口。你也能夠指定開發幾個，好比： health，info，refresh，而這裏由於咱們須要用的refresh功能，因此須要把refresh接口開放出來。

設置成「*」後，啓動信息會包含如下信息，而這個叫refresh的post方法，就是咱們須要的，上面說的接口地址變動從這裏也能夠看得出來。

測試效果

從新啓動服務，訪問 http://localhost:8005/hello，返回結果以下。

修改倉庫配置內容，末尾加個數字 5，以下圖所示。

再次訪問 http://localhost:8005/hello，如咱們所料，結果並無更新，由於咱們尚未調refresh方法。

經過工具或自寫代碼發送post請求 http://localhost:8005/actuator/refresh，刷新配置。

這裏經過在線測試網站發送，地址：https://getman.cn/Mo2FX 。

注意：先讓你的Chrome支持跨域。設置方法：在快捷方式的target後加上 --disable-web-security --user-data-dir，重啓便可。

刷新以後，再次訪問 http://localhost:8005/hello，返回結果以下。

查看返回結果，刷新以後已經能夠獲取最新提交的配置內容，可是每次都須要手動刷新客戶端仍是很麻煩，若是客戶端數量一多就簡直難以忍受了，有沒有什麼比較好的辦法來解決這個問題呢，那是固然的，答案就是：Spring Cloud Bus。

Spring Cloud Bus

Spring Cloud Bus，被你們稱爲消息總線，它經過輕量級的消息代理來鏈接各個分佈的節點，能夠利用像消息隊列的廣播機制在分佈式系統中進行消息傳播，經過消息總線能夠實現不少業務功能，其中對於配置中心客戶端刷新，就是一個很是典型的使用場景。

下面這張圖能夠很好的解釋消息總線的做用流程（圖片描述來源：純潔的微笑：配置中心博文）。

Spring Cloud Bus 進行配置更新步驟以下:

一、提交代碼觸發post請求給/actuator/bus-refresh

二、server端接收到請求併發送給Spring Cloud Bus

三、Spring Cloud bus接到消息並通知給其它客戶端

四、其它客戶端接收到通知，請求Server端獲取最新配置

五、所有客戶端均獲取到最新的配置

安裝RabbitMQ

由於咱們須要用到消息隊列，咱們這裏選擇RabbitMQ，使用Docker進行安裝。

拉取鏡像

執行如下命令，拉取鏡像。

docker pull rabbitmq:management

完成以後執行如下命令查看下載鏡像。

docker images

建立容器

執行如下命令，建立docker容器。

docker run -d --name rabbitmq -p 5671:5671 -p 5672:5672 -p 4369:4369 -p 25672:25672 -p 15671:15671 -p 15672:15672 rabbitmq:management

啓動成功以後，能夠執行如下命令查看啓動容器。

docker ps

登陸界面

容器啓動以後就能夠訪問web管理界面了，訪問 http://宿主機IP:15672。

系統提供了默認帳號。用戶名：guest 密碼： guest

管理界面

客戶端實現

添加依賴

打開客戶端 kitty-consumer，添加消息總線相關依賴。

pom.xml

<!-- bus-amqp -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

修改配置

修改配置，添加RebbitMq的相關配置，這樣客戶端代碼就改造完成了。

bootstrap.yml

spring:
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        serviceName: ${spring.application.name}    # 註冊到consul的服務名稱
    config:
      discovery:
        enabled: true  # 開啓服務發現
        serviceId: kitty-config # 配置中心服務名稱
      name: kitty-consumer  # 對應{application}部分
      profile: dev  # 對應{profile}部分
      label: master  # 對應git的分支，若是配置中心使用的是本地存儲，則該參數無用
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

服務端實現

添加依賴

修改 kitty-conifg，添加相關依賴。

pom.xml

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

修改配置，添加RabbitMq的和接口開放相關配置，這樣服務端代碼也改造完成了。

application.yml

server:
  port: 8020
spring:
  application:
    name: kitty-config
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        serviceName: ${spring.application.name}    # 註冊到consul的服務名稱
    config:
      label: master  # git倉庫分支
      server:
        git:
          uri: https://gitee.com/liuge1988/kitty.git  # 配置git倉庫的地址
          search-paths: config-repo  # git倉庫地址下的相對地址，能夠配置多個，用,分割。
          username: username  # git倉庫的帳號
          password: password  # git倉庫的密碼
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
management:
  endpoints:
    web:
      exposure:
        include: "*"

測試效果

1.啓動服務端，成功集成消息總線後，啓動信息中能夠看到以下圖中的信息。

2.啓動客戶端，發現竟然報錯了，網上也找不到相關資料，也沒見其餘人提過相關問題。猜想是網上教程可能是使用Euraka，而這裏用的時Consul，瞎鼓搗了很久，反正是不想換回Euraka，2.0中止開發消息出來之後，未來還不定什麼狀況，只能硬着頭皮解決了。

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'configServerRetryInterceptor' available
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:685) ~[spring-beans-5.0.8.RELEASE.jar:5.0.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1210) ~[spring-beans-5.0.8.RELEASE.jar:5.0.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) ~[spring-beans-5.0.8.RELEASE.jar:5.0.8.RELEASE]
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:204) ~[spring-beans-5.0.8.RELEASE.jar:5.0.8.RELEASE]
    at org.springframework.retry.annotation.AnnotationAwareRetryOperationsInterceptor.getDelegate(AnnotationAwareRetryOperationsInterceptor.java:180) ~[spring-retry-1.2.2.RELEASE.jar:na]
    at org.springframework.retry.annotation.AnnotationAwareRetryOperationsInterceptor.invoke(AnnotationAwareRetryOperationsInterceptor.java:151) ~[spring-retry-1.2.2.RELEASE.jar:na]
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:185) ~[spring-aop-5.0.8.RELEASE.jar:5.0.8.RELEASE]
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688) ~[spring-aop-5.0.8.RELEASE.jar:5.0.8.RELEASE]
    at org.springframework.cloud.config.client.ConfigServerInstanceProvider$$EnhancerBySpringCGLIB$$dd44720b.getConfigServerInstances(<generated>) ~[spring-cloud-config-client-2.0.0.RELEASE.jar:2.0.0.RELEASE]
    at org.springframework.cloud.config.client.DiscoveryClientConfigServiceBootstrapConfiguration.refresh(DiscoveryClientConfigServiceBootstrapConfiguration.java:84) [spring-cloud-config-client-2.0.0.RELEASE.jar:2.0.0.RELEASE]
    at org.springframework.cloud.config.client.DiscoveryClientConfigServiceBootstrapConfiguration.startup(DiscoveryClientConfigServiceBootstrapConfiguration.java:69) [spring-cloud-config-client-2.0.0.RELEASE.jar:2.0.0.RELEASE]
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_131]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_131]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_131]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_131]

而後就跟蹤代碼，發現是在下圖中的位置找不到相應的Bean，那麼答案就比較明顯了，要麼是程序有BUG，不過可能性不大，那應該是就是缺包了，在缺失的包裏有這個Bean。可是這個Bean是在哪一個包？排查了半天也沒找到，網上也沒有想過資料，對比了一下網上消息總線的配置，依賴也沒有少加什麼。

沒有辦法，最後只能本身上手了，不就是在刷新的時候缺乏一個攔截器嗎，本身給他弄一個試試唄。

使用就加了一個配置類，並在resources下新建了META-INF目錄和一個spring。factories文件。

RetryConfiguration.java

package com.louis.kitty.consumer;

import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.context.annotation.Bean;
import org.springframework.retry.interceptor.RetryInterceptorBuilder;
import org.springframework.retry.interceptor.RetryOperationsInterceptor;

public class RetryConfiguration {
    @Bean
    @ConditionalOnMissingBean(name = "configServerRetryInterceptor")
    public RetryOperationsInterceptor configServerRetryInterceptor() {
        return RetryInterceptorBuilder.stateless().backOffOptions(1000, 1.2, 5000).maxAttempts(10).build();
    }
}

spring.factories

org.springframework.cloud.bootstrap.BootstrapConfiguration=com.louis.kitty.consumer.RetryConfiguration

在這裏指定新建的攔截器，這樣系統初始化時會加載這個Bean。

而後重啓啓動，果真沒有報錯了，仍是先別高興，看看能不能用先。

4.先訪問一下 http://localhost:8005/hello，效果以下圖所示。

5.修改倉庫配置文件，把數字5改爲15，修改完成提交。

再次訪問發現仍是舊信息。

6.再用工具發送post請求 http://localhost:8020/actuator/bus-refresh 。

注意此次是向註冊中心服務端發送請求，發送成功以後服務端會經過消息總線通知全部的客戶端進行刷新。

另外開啓消息總線後的請求地址是 /actuator/bus-refresh，再也不是refresh了。

7.給服務端發送刷新請求以後，再次訪問 http://localhost:8005/hello，結果以下(須要一點刷新時間)。

咱們愉快的發現客戶端已經可以經過消息總線獲取最新配置了。

源碼下載

後端：https://gitee.com/liuge1988/kitty

前端：https://gitee.com/liuge1988/kitty-ui.git

做者：朝雨憶輕塵
出處：https://www.cnblogs.com/xifengxiaoma/ 版權全部，歡迎轉載，轉載請註明原文做者及出處。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。

Spring Boot + Spring Cloud 實現權限管理系統 後端篇（二十三）：配置中心（Config、Bus）

在線演示

技術背景

Spring Cloud Config

實現案例

準備配置文件

服務端實現

新建工程

添加依賴

啓動類

配置文件

測試效果

客戶端實現

添加依賴

配置文件

控制器

測試效果

Refresh機制

添加依賴

修改配置

測試效果

Spring Cloud Bus

安裝RabbitMQ

拉取鏡像

建立容器

登陸界面

客戶端實現

添加依賴

修改配置

服務端實現

添加依賴

測試效果

源碼下載

Spring Boot + Spring Cloud 實現權限管理系統後端篇（二十三）：配置中心（Config、Bus）