SpringCloud之远程分布式配置(Config)

最新推荐文章于 2024-04-18 06:44:38 发布

代码忘烦恼

最新推荐文章于 2024-04-18 06:44:38 发布

阅读量1.4k

点赞数 2

分类专栏： SpringCloud 文章标签： springcloud springboot springcloudconfig

本文链接：https://blog.csdn.net/qwe86314/article/details/100828255

版权

SpringCloud 专栏收录该内容

20 篇文章 118 订阅

订阅专栏

通过前面的学习，相信大家已经掌握了SpringCloud许多组件的用法，能够熟练的搭建基本的微服务，应该感受到微服务和我们传统架构的项目最大区别在于微服务中要部署的项目数量非常多，每个服务的配置也非常繁杂。如果将这些配置文件都放在各个微服务之中，随着项目不断变大，配置文件会越来越多，越来越复杂，每一次项目上线估计运维工程师都要崩溃了，维护也非常不方便，因为要改的数据太多了。那么有没有一种办法可以让我们对这些配置文件进行统一管理呢？有！那就是我们今天要说的 Spring Cloud Config。

可能有人已经听说过 Spring Cloud Config，但分布式配置解决方案却不止 Spring Cloud Config，还有其它一些框架，例如 360 的 QConf 、淘宝的 diamond 、百度的 disconf 等都可以解决分布式配置中心问题。国外也有很多开源的配置中心例如 Apache Commons Configuration 、owner 、cfg4j 等等，但是 Spring Cloud Config 的功能更为强大，而且可以和 Spring 家族无缝结合，非常方便。

SpringConfig 介绍

Spring Cloud Config 项目是一个解决分布式系统的配置管理方案。它包含了 Client 和 Server 两个部分，Server 提供配置文件的存储，然后以接口的形式将配置文件的内容提供出去，Client 通过接口获取数据，然后依据此数据初始化自己的应用。Spring cloud 支持使用 Git 或者 Svn 存放配置文件，默认情况下使用 Git，考虑到目前企业开发的实际情况，我们这里主要通过 Git 来向大家演示 Spring Cloud Config 的用法。

那么Spring Cloud Config 有那些功能？

提供服务端和客户端的支持
集中管理各种环境的配置文件
配置文件修改后，可以快速生效
因为配置文件通过 Git 或者 Svn 进行管理，所以配置文件天然具备版本回退等功能
支持大的并发查询
支持多种开发语言
那么我们马上开始使用Spring Cloud Config ，让我们来感受远端配置文件的魅力把。

在创建项目之前，我们需要前置知识，至少熟悉并使用Git命令。

首先我们在github创建一个公共仓库名字cloud-config-repo备用，然后我们在本地创建如下文件夹：

假设这三个文件就是用户微服务在不同环境下（如图分别表示开发环境、生产环境、测试环境以及默认配置）的配置文件，三个文件的内容分别如下：

client1-dev.yml
```
love=小蕾
```
client1-test.yml
```
love=java
```
client1-prod.yml
```
love=SpringCloud
love=SpringBoot
```
这样创建好后，我们使用git命令上传到我们之前创建的仓库。
```
git init
git add .
git commit -m "微服务配置"
git remote add origin 您的github仓库地址
git push -u origin master
```
上传完成后，我们看下上传后的结构：

Config Server

下面我们来看一下Spring Cloud Config 的运作原理图：

ConfigServer 从 Git 仓库获取到配置文件，然后 ConfigClient（就是我们前文中和大家分享的一个一个的微服务）再从 ConfigServer 中获取各自的配置文件，大致就是这样一个工作流程。

然后我们创建一个cloudConfig的普通maven项目，创建好后，我们再创建一个config-server的SpringBoot工程作为子模块。依赖如下：
```
 <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
    </dependencies>
```
创建好后，然后在启动类上加入注解@EnableConfigServer
```
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
    public static void main(String[] args) {
        SpringApplication.run( ConfigServerApplication.class, args );
    }
}
```
然后我们在application.yml中配置远端仓库配置：
```
spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://github.com/zhoubiao188/cloud-config-repo.git
          search-paths: client1
          username: 您的github账号
          password: 您的github密码
server:
  port: 8081
```
上面的这段重要配置解释如下：uri 代表github仓库地址，就是存放您远端配置信息。search-paths 表示仓库中配置文件的地址，由于 ConfigServer 是 Git 仓库和微服务之间的一个桥梁，不同微服务的仓库在 Git 仓库中放在不同的目录下，这里是指具体的目录，有人会说这样把地址写死了没有任何意义，这个问题一会和大家详细分析；，这里是client1开始，接下来两个配置就是自己的 GitHub 的用户名和密码，但是这两个配置并非必须的，如果你的仓库就是公开的，那么可以不必配置，实际生产环境中，仓库往往是私有的，因此这里就需要配置用户密码来获取仓库的访问权限。

完成后，我们启动项目，然后访问http://localhost:8081/client1/dev/master 然后返回如下信息则成功：

我们发现idea的控制台输出了如下内存：
```
Adding property source: file:/var/folders/07/dpdds6t50qjf_b3g2cst81cm0000gn/T/config-repo-3486861953494449034/client1/client1-dev.yml
```
进入这里提到的目录，发现 config_server 已经将远程 git 仓库中的内容 clone 下来了：

事实上，仓库中的配置文件会被转换成web接口，访问可以参照以下的规则：
/{application}/{profile}[/{label}]
/{application}/{profile}.yml
/{application}/{profile}.properties
/{label}/{application}-{profile}.yml
/{label}/{application}-{profile}.properties
这里，各个占位符含义分别如下：
{application} 表示配置文件的文件名
{profile} 表示配置文件的 profile ，例如我们上文提到的 test、dev 以及 prod
{label} 表示配置文件的 git 分支
此时我们尝试修改本地仓库的配置文件，例如修改 client1-dev.yml 文件内容如下：
```
love=xiaolei
```
然后提交到 Git 仓库，再通过 ConfigServer 进行访问，发现访问到的数据已经发生了变化，说明 ConfigServer 中的数据可以实时更新。

Config Client

我们再创建一个叫config-client的SpringBoot作为子模块，同时添加如下依赖：
```
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-config</artifactId>
    </dependency>
</dependencies>
```
创建成功后，添加配置文件，注意配置文件添加在 bootstrap.properties 文件中，这时需要大家手动在 classpath 下添加 bootstrap.properties 配置文件，相对于 application.properties 文件，bootstrap.properties 文件加载时机更早，适合于目前的场景，bootstrap.properties 中的配置内容如下：
```
spring:
  application:
    name: client1
server:
  port: 8082
  cloud:
    config:
      profile: dev
      label: master
      uri: http://localhost:8081/
```
上面重要的配置解释如下:
1. 前两个是应用名称和端口号
2. 大家还记得 config_server 中的访问地址问题吧。上文我们提到的访问规则是 /{application}/{profile}[/{label}] ，当 Config Client 去访问 Config Server 时，spring.application.name 、spring.cloud.config.profile 以及、spring.cloud.config.label 的值分别对应上面三个占位符，所以这三个地方不能乱写，要根据实际情况来，特别是 spring.application.name 不能写错，因为之前我们定义名称时都是可以随意取的，这里不可以
3. spring.cloud.config.uri 则表示 config_server 的地址。
配置完成后，当我们的 config_client 项目启动时，配置文件会被自动加载到项目中，我们就可以像使用普通配置文件一样来使用仓库中的配置文件，我们写一个简单的 HelloController 来测试下，如下：
```
@RestController
public class HelloController {
    @Value("${document}")
    private String love;

    @GetMapping("/love")
    public String love() {
        return love;
    }
}
```
配置完成后，分别启动configServer和configClient 然后访问控制器地址

成功访问到我们需要的配置文件，如果想访问 client1-prod.yml，只需要修改 bootstrap.properties 中 spring.cloud.config.profile 的值为 prod 即可。

其它配置方式

由于配置细节较多，这里主要和大家说一下关于路径的配置细节，其它的细节将在本章后面的小节中和大家介绍。

前面和大家说过，spring.application.name 、spring.cloud.config.profile 以及 spring.cloud.config.label 的值分别对应 {application} 、 {profile} 以及 {label} 三个占位符，即在 config_server 中，我们可以通过 {application} 、 {profile} 以及 {label} 分别访问到 config_client 中对应的 spring.application.name 、 spring.cloud.config.profile 以及 spring.cloud.config.label 的值。利用这种特性我们就可以实现对 config_server 中 search-paths 属性的动态配置，例如我们可以将 search-paths 的值和 config_client 的 spring.application.name 绑定在一起，这样就可以实现动态修改配置文件的文件夹了。例如我们上文提到的配置方案，我们现在可以直接修改 config_server 的配置文件，如下：
```
     git:
          uri: https://github.com/zhoubiao188/cloud-config-repo.git
          username: zhoubiao188
          password:
          search-paths: {application}
```
这里我们主要是修改了 search-paths 的值，将之用一个 {application}
占位符代替，然后重启 config_server ，发现运行效果和前面的一样。

如此之后，我们就可以通过灵活使用 {application} 、{profile} 、{label} 三个占位符，来动态地从 client 中控制 server 所访问的仓库了。读者可以根据自己的实际情况，把这三个占位符玩的更加精彩。

本地配置

上文我们提到的配置是在 Git 仓库中完成的，Spring Cloud Config 也提供本地存储配置的方式，例如我们可以添加如下将配置，表示让 config_server 在 classpath 下查找配置文件：
```
spring:
 # 本地配置
  profiles:
    active: native
```
也可以添加如下配置，通过绝对路径来定位配置文件位置：
```
spring:
  cloud:
    config:
      server:
        native:
          searchLocations=file:E:/properties/:
```
这些方式，大家作为一个了解即可，不必深究，项目中，我们一般还是以 Git 仓库中的配置为主。

总结

本文主要向读者介绍了 Spring Cloud Config 的一个基本使用，涉及到 Spring Cloud Config Server 和 Spring Cloud Config Client 的搭建，其中 Config Client 就是我们一个一个的微服务，整个过程并不复杂，不过还有很多细节没有讲到，例如 config_server 的安全管理、配置文件的加密等，这些我们将在下篇文章和大家介绍。

源码地址

github

代码忘烦恼

关注

2
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
SpringCloud之远程分布式配置(Config)

通过前面的学习，相信大家已经掌握了SpringCloud许多组件的用法，能够熟练的搭建基本的微服务，应该感受到微服务和我们传统架构的项目最大区别在于微服务中要部署的项目数量非常多，每个服务的配置也非常繁杂。如果将这些配置文件都放在各个微服务之中，随着项目不断变大，配置文件会越来越多，越来越复杂，每一次项目上线估计运维工程师都要崩溃了，维护也非常不方便，因为要改的数据太多了。那么有没有一种办法可以让...
复制链接

扫一扫