SpringCloud微服务（五）——Config分布式配置中心

wzq_55552

已于 2022-11-23 13:57:22 修改

阅读量453

点赞数 1

分类专栏： java java后端文章标签： spring cloud 微服务分布式

于 2022-11-21 23:03:22 首次发布

本文链接：https://blog.csdn.net/qq_43409401/article/details/127974466

版权

java 同时被 2 个专栏收录

91 篇文章 7 订阅

订阅专栏

java后端

49 篇文章 2 订阅

订阅专栏

SpringCloud Config分布式配置中心

SpringCloud

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。

SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自己带着一个application.yml，上百个配置文件的管理…/(ㄒoㄒ)/~~

简介

官网：https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.2.1.RELEASE/reference/html/

SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

SpringCloud Config分为服务端和客户端两部分。

服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口

客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。

在这里插入图片描述

作用：

集中管理配置文件
运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息
当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置
将配置信息以REST接口的形式暴露，post、curl访问刷新均可…

由于SpringCloud Config默认使用Git来存储配置文件(也有其它方式,比如支持SVN和本地文件)，但最推荐的还是Git，而且使用的是http/https访问的形式。

服务端配置与测试

创建

远程配置中心是在github上面

新建配置中心微服务

依赖配置

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

application.yml:

server:
  port: 3344

spring:
  application:
    name: cloud-config-center
  cloud:
    config:
      server:
        git:
          uri: https://github.com/wzq-55552/springcloud-config.git #配置远程的仓库地址springcloud-config
          search-paths:
            - springcloud-config
      label: master #进到仓库的主分支

eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

启动类：

/**
 * @author zzyy
 */
@SpringBootApplication
@EnableConfigServer
public class ConfigCenterMain3344 {
    public static void main(String[] args) {
        SpringApplication.run(ConfigCenterMain3344.class, args);
    }
}

测试

配置中心读取github配置以REST方式暴露出来

读取方式很多：

在这里插入图片描述

一个一个文件也行，一个yml文件包含多个环境也行，通过profiles区分。

github创建：

在这里插入图片描述

如果有其他分支，都可以访问，直接url上把master改成其他分支

访问github上面的文件：http://localhost:3344/master/application.yml

http://localhost:3344/application.yml效果一样，不加分支默认配置中的分支，为master

在这里插入图片描述

读取github上面application.yml文件中的不同环境内容

dev环境的值：http://localhost:3344/application/dev/master

在这里插入图片描述

test环境的值：http://localhost:3344/application/test/master

在这里插入图片描述

客户端配置与测试

创建

依赖配置

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

两种模式：根据具体场景

**一、**github上文件是config(application)-dev.yml、config(application)-test.yml、config(application)-prod.yml多个环境文件细分的，如下配置：

http://localhost.com:3344/master/config-dev.yml

http://localhost.com:3344/master/application-dev.yml

bootstrap.yml（该配置是与配置中心互通的，读取公有配置），applicaiton.yml是该微服务独有，特有的配置。该微服务需要2个配置文件。

server:
  port: 3355

spring:
  application:
    name: config-client
  cloud:
    config:
      label: master # 分支名称
      name: config # 配置文件名称，可自定义，最好application/config
      profile: dev # 读取的后缀，上述三个综合，为master分支上的config-dev.yml的配置文件被读取，http://localhost.com:3344/master/config-dev.yml
      uri: http://localhost:3344 #配置中心的地址

eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

applicaiton.yml是用户级的资源配置项
bootstrap.yml是系统级的，优先级更加高

Spring Cloud会创建一个Bootstrap Context，作为Spring应用的Application Context的父上下文。初始化的时候，Bootstrap Context负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment。Bootstrap属性有高优先级，默认情况下，它们不会被本地配置覆盖。 Bootstrap context和Application Context有着不同的约定，所以新增了一个bootstrap.yml文件，保证Bootstrap Context和Application Context配置的分离。

**二、**github上文件是一个application.yml，比如：

http://localhost:3344/application/dev/master

github配置内容

spring:
  profiles:
    active:
    - dev
---
spring:
  profiles: dev     #开发环境
  application: 
    name: microservicecloud-config-atguigu-dev
---
spring:
  profiles: test   #测试环境
  application: 
    name: microservicecloud-config-atguigu-test
#  请保存为UTF-8格式

如下配置：

bootstrap.yml（该配置是与配置中心互通的，公有配置），applicaiton.yml是该微服务独有，特有的配置。

server:
  port: 3355

spring:
  #application:
  #  name: config-client
  cloud:
    config:
      label: master # 分支名称
      name: application # 配置文件名称，可自定义，最好application/config
      profile: dev # 文件中的dev profile内容，上述三个综合，为master分支上的application.yml的配置文件中的dev内容被读取http://localhost:3344/application/dev/master
      uri: http://localhost:3344 #配置中心的地址

eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

测试

这里测试，我采用第二种方式，都一样。

首先，我们客户端微服务是没有配置application.name的，但是却可以注册到服务注册中心，因为优先加载bootstrap.yml配置文件，读取到了github上的配置，这里测试例子的github配置有实例名。

controller测试读取配置中心的配置

@RestController
//@RefreshScope
public class ConfigClientController {

    @Value("${spring.application.name}")
    private String applicationName;

    @GetMapping("/applicationName")
    public String getApplicationName(){
        return applicationName;
    }
}

配置中心的配置读取，github上的：

在这里插入图片描述

客户端读取：

在这里插入图片描述

客户端动态刷新配置

问题：

linux运维修改Github上的配置文件内容

刷新3344,发现ConfigServer配置中心立刻响应

刷新3355,发现ConfigClient客户端的没有任何响应

3355没有变化除非自己重启或者重新加载，实际生产各种微服务都要重启？

为了避免每次更新配置都要重启客户端微服务3355，还需要完善配置中心

加上监控的依赖，服务端和客户端都加。

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

客户端完整bootstrap.yml配置

server:
  port: 3355

spring:
#  application:
#    name: config-client
  cloud:
    config:
      label: master # 分支名称
      name: application # 配置文件名称，可自定义，最好application/config
      profile: dev # 文件中的dev profile内容，上述三个综合，为master分支上的application.yml的配置文件中的dev内容被读取http://localhost:3344/application/dev/master
      uri: http://localhost:3344 #配置中心的地址

eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka

#暴露监控端口
management:
  endpoints:
    web:
      exposure:
        include: "*"