七. SpringCloud服务配置

1. SpringCloud Config概述

1.1 分布式系统面临的配置问题

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

SpringCloud提供了Config Server来解决这个问题，否则我们每一个微服务自己带着一个application.yml，上百个配置文件的管理会令人头疼。

1.2 是什么

如图，服务配置中心从远端读取配置文件，然后客户端服务再通过服务配置中心读取配置。

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

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

• 服务端也称为 分布式配置中心，它是一个独立的微服务应用 ，用来连接配置服务器并为客户端提供获取配置信息，加密/解密信息等访问接口，将配置信息以REST接口的形式暴露给客户端（客户端可以用REST风格方式读取到该配置信息）。

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

1.3 作用

• 集中管理配置文件
• 不同环境不同配置，动态化的配置更新，分环境比如dev/test/prod/beta/release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心同意拉取配置自己的信息
• 当配置发生改变时，服务不需要重启即可感知到配置的变化并应用新的配置
• 将配置信息以REST接口的形式暴露 （post/crul访问刷新即可）

1.4 与GitHub整合配置

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

2. Config 服务端配置与测试

2.1 Gitee仓库

在Gitee上新建一个用作配置中心的新仓库，并克隆到本地开发硬盘目录

然后根据新建的Git地址，将Gitee上的仓库克隆到本地

git clone https://gitee.com/mp2333/springcloud-config.git

2.2 建Module

新建Module：cloud-config-center-3344作为配置中心微服务

在其POM文件中引入服务配置中心的依赖：

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

修改其配置文件application.yml如下：

server:
  port: 3344

spring:
  application:
    name:  cloud-config-center # 注册进Eureka服务器的微服务名
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/mp2333/springcloud-config.git # GitHub上面的git仓库名字
          # 搜索目录
          search-paths:
            - springcloud-config
          # 注意：如果仓库私有则需要添加username/password
      # 读取分支
      label: master

# 服务注册到eureka地址
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka

编写主启动类，在主启动类上添加注解 @EnableConfigServer 使3344微服务具有配置中心功能：

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

修改hosts文件，增加映射，使本机模拟网址服务配置中心网址：

127.0.0.1 config-3344.com

2.3 GitHub仓库建配置文件

如图，就是创建了一个简单的配置文件，用来测试能否通过配置中心微服务获取内容。

2.4 测试

配置读取规则 (五种)

• /{label}/{application}-{profile}.yml

# master分支
http://config-3344.com:3344/master/config-dev.yml
http://config-3344.com:3344/master/config-prod.yml
# dev分支
http://config-3344.com:3344/dev/config-dev.yml
http://config-3344.com:3344/dev/config-prod.yml

• /{application}-{profile}.yml 默认master分支

http://config-3344.com:3344/config-dev.yml
http://config-3344.com:3344/config-prod.yml

• /{application}/{profile}[/{label}]

# master分支
http://config-3344.com:3344/config/dev/master
http://config-3344.com:3344/config/prod/master
# dev分支
http://config-3344.com:3344/config/dev/dev
http://config-3344.com:3344/config/prod/dev

先启动Eureka服务注册中心，然后启动服务配置中心微服务3344，访问 http://config-3344.com:3344/master/config-dev.yml ，我们可以看到3344微服务可以成功的读取到远端的配置文件。

所以现在，服务配置中心从远端Git仓库读取配置文件这一部分已经搭建完成：

3. Config 客户端配置与测试

3.1 建Moudle

新建Module：cloud-config-client-3355作为访问配置中心的客户端

在其POM文件中引入Config配置中心客户端的启动类：

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

3.2 编写配置文件bootstrap.yml

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

所以，要将Client模块下的application.yml文件改为bootstrap.yml，这是很关键的，因为bootstrap.yml是比application.yml先加载的。编写bootstrap配置文件如下：

server:
  port: 3355

spring:
  application:
    name: config-client
  cloud:
    # Config客户端配置
    config:
      label: master # 分支名称
      name: config # 配置文件名称
      profile: dev # 读取后缀名称   
      # 上述3个综合：master分支上config-dev.yml的配置文件被读取
      uri: http://localhost:3344 # 配置中心地址
      # http://config-3344.com:3344/master/config-dev.yml

# 服务注册到eureka地址
eureka:
  client:
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka

编写3355服务的主启动类，之后编写其业务类：

@RestController
public class ConfigClientController {

    @Value("${server.info}") //配置中心config-dev.yml配置的内容
    private String configInfo;

    @GetMapping("/configInfo")
    public String getConfigInfo() {
        return configInfo;
    }
}

3.3 测试

下面测试客户端是否能够通过访问配置中心获取配置信息

按顺序启动Eureka服务注册中心，Config服务配置中心后，启动我们的服务配置中心客户端3355进行测试：

3.4 存在的问题

我们在GitHub上修改配置文件内容，刷新3344配置中心服务端，发现Config Server配置中心立刻响应并刷新了配置信息，但是！我们刷新3355客户端Config Client，发现没有任何响应，配置信息仍然是原来的配置信息。

难道每次远端修改了配置文件后，客户端都需要重启来进行对配置信息的重新加载吗？

4. Config 客户端之动态刷新

为了避免每次远端更新配置信息都需要重启客户端微服务3355来加载更新的配置信息，我们需要使用动态刷新。

4.1 修改3355模块

在POM中引入actuator监控：

其实actuator依赖几乎处了是网关的微服务外都得加。

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

4.2 修改配置文件

在bootstrap.yml中加入如下配置 暴露监控端点：

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

4.3 @RefreshScope注解

在业务类Controller上添加@RefreshScope注解使客户端服务具有刷新功能：

@RestController
@RefreshScope
public class ConfigClientController {

    @Value("${config.info}")
    private String configInfo;

    @GetMapping("/configInfo")
    public String getConfigInfo() {
        return configInfo;
    }

}

4.4 发送Post请求刷新客户端3355

该刷新请求必须发送后，客户端才能获得刷新后的信息，刷新客户端的请求必须是POST请求：

curl -X POST "http://127.0.0.1:3355/actuator/refresh"

当出现以上信息时激活刷新客户端3355成功，再次访问客户端，发现已经可以得到刷新后的配置信息。

但是假设如果我们有多个微服务客户端呢？难道每个微服务都需要执行一次POST请求进行手动刷新吗？事实上我们可以通过广播的方式进行一次通知，处处生效，这里就要知道消息总线 => SpringCloud Bus。