09.Spring Cloud Config：配置中心的由来及实现方案

在微服务架构中，配置管理是一项重要而复杂的任务。分布式系统中，应用通常部署在多台服务器上，或者以多个实例的形式存在于云环境中，这种分布式部署给配置管理带来了巨大挑战。为了高效、动态地管理这些配置，配置中心的概念应运而生。

1. 配置中心的由来

在传统的单体应用中，配置文件通常是以静态的方式保存在项目中，修改配置需要重新部署应用。在分布式系统中，这种方式显得笨拙且低效，配置中心的出现解决了这些问题，它将配置集中管理，提供动态更新的能力。配置中心允许我们在一个地方管理不同环境和不同集群的配置信息，当配置发生变化时，能够实时地将更新推送到应用程序，从而实现动态更新。

2. 配置中心的基本功能要求

一个完善的配置中心应具备以下基本功能：

1. 静态配置管理：能够管理和分发静态配置信息。
2. 动态配置管理：支持动态更新配置信息，并实时推送到各个实例。
3. 统一管理：在一个地方统一管理不同环境、不同集群的配置信息。
4. 多维度管理：支持多维度、多层次的配置管理。
5. 本地配置缓存：支持本地缓存配置，保障在网络故障时应用的正常运行。
6. 配置更新策略：提供灵活的配置更新策略。
7. 配置锁：支持配置锁定，防止配置被误修改。
8. 配置校验：支持配置校验，确保配置的合法性。
9. 配置生效时间：支持配置实时生效，无需重启应用。
10. 配置更新推送：支持配置更新的实时推送。

3. 多种配置中心的选择与对比

在实际应用中，有多种配置中心可供选择，以下是几种常见配置中心的对比：

对比项	重要程度	Spring Cloud Config	Netflix Archaius	Ctrip Apollo	DisConf	Nacos
静态配置管理	高	基于file	无	支持	支持	支持
动态配置管理	高	支持	支持	支持	支持	支持
统一管理	高	无，需要git、数据库等	无	支持	支持	支持
本地配置缓存	高	无	无	支持	支持	支持
配置更新推送	高	需要手动触发	需要手动触发	支持	支持	支持
配置版本管理	高	git	无	支持	无，需要git、数据库等	支持
配置自动刷新	高	支持	不支持	支持	支持	支持
配置管理界面	中	无	无	支持	支持	支持
多种存储支持	中	支持（Git、数据库等）	不支持	支持	不支持	支持
社区活跃度	高	高	低	中	低	高

4. Spring Cloud Config的概述及实现

Spring Cloud Config是Spring Cloud微服务体系中的配置中心，它是一个集中化外部配置的分布式系统，由服务端和客户端组成，不依赖于注册中心，是一个独立的配置中心，支持多种存储配置信息形式，如jdbc、file、native、svn、git等，默认使用git。

Spring Cloud Config的实现方案有多种，这里主要介绍2种常见的实现方式：

1. 结合Git实现配置中心方案
2. 结合数据库（如MySQL）实现配置中心方案

5. 使用Git实现配置中心方案

5.1 Git版基本工作原理

配置客户端启动时会向服务器发起请求，服务端接收到客户端的请求后，根据配置的仓库地址将Git上的文件克隆到本地的一个临时目录中，然后服务端再读取本地文件返回给客户端。这样，即使Git服务器故障或网络异常，服务端仍能正常工作。

5.2创建config-server服务模块

导入相关依赖

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <artifactId>cloud-config-server</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>cloud-config-server</name>
    <description>cloud-config-server</description>
    <parent>
        <groupId>cn.ywenrou</groupId>
        <artifactId>spring-cloud-demo</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

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

    </dependencies>
</project>

5.3 配置远程仓库

创建application.yml，并进行配置，Git多种配置信息讲解

• 本地仓库：使用file://前缀配置本地仓库。
• 占位符配置URI：支持使用占位符｛application｝、｛profile｝、{label}配置Git的uri。
• 匹配并配置多个仓库：支持通过带有通配符的表达式来匹配多个仓库。
• 子目录存储：通过spring.cloud.config.server.git.searchPaths来定位到Git仓库的子目录中。
• 访问权限：通过username和password配置账户，支持HTTP认证和SSH认证。

server:
  port: 8888
spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/ywenrou/springcloud-config.git
          username: xxxx
          password: xxxx
          default-label: master #配置文件分支

5.4 测试远程配置中心

@SpringBootApplication
@EnableConfigServer // 启用配置中心服务端
public class CloudConfigServerApplication {

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

}

Spring Cloud Config使用应用程序名称、配置文件（环境）和标签（版本）来决定如何从配置仓库中加载配置文件。

端点和文档的映射规则：

• {application} 表示应用程序的名称（如myapp）。
• {profile} 表示激活的配置文件（如dev、test、prod等）。
• {label} 表示配置仓库中的版本（如Git分支或标签，默认是master）。

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

根据这些规则，可以将上述端点映射到相应的配置文件：

• /myapp/dev 将映射到 myapp-dev.properties 或 myapp-dev.yml，具体取决于文件格式。
• /myapp/dev/feature 将映射到 feature/myapp-dev.properties 或 feature/myapp-dev.yml，其中feature是Git分支或标签，若不指定默认分组是master。

例如我们访问localhost:8888/cloud/dev (opens new window) ，则会匹配到master分支下的cloud-dev配置文件

5.6 修改服务为动态配置

在服务中添加config客户端依赖，客户端获取配置中心的配置内容。：

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

5.7 配置bootstrap.yml

由于配置文件的加载优先级不同，Spring Boot会尝试加载以下配置文件（按照优先级从高到低）：

• bootstrap.yml
• application-dev.yml
• application-dev.yaml
• application.yml
• application.yaml

高的配置生效后，低的不会生效。获取配置中心的配置，应该在bootstrap.yml配置文件中进行配置才能确保获取得到配置中心的数据，我们在git远程仓库中修改了cloud-service1的端口为9001。

---
spring:
  profiles:
    active: dev   # 指定当前应用的配置文件
---
spring:
  profiles: dev
  application:
    name: cloud-service1
  cloud:
    config:
      uri: http://localhost:8888
      label: master
      profile: dev
---
spring:
  profiles: prod
  application:
    name: cloud-service1
  cloud:
    config:
      uri: http://localhost:8888
      label: master
      profile: prod

5.7 启动服务查看是否加载

通过测试发现原来的8080端口已经不能用了，说明配置成功加载了远端，但是还存在一个问题就是Spring Cloud Config是在项目启动的时候加载的配置内容，导致了它存在一个缺陷，配置文件修改后，需要重启服务才能生效，这个问题可以自行百度。

5.8 Spring Cloud Bus热刷新

为了避免重启项目才能获取最新的配置信息，可以进行手动刷新或结合Spring Cloud Bus进行热刷新。结合Spring Cloud Bus进行热刷新时，用户更新配置信息时，Config Server接收到请求并发布消息，Bus将消息发送到Config Client，Config Client接收到消息后重新发送请求加载配置。

6. 使用MySQL实现配置中心方案

将持久化从git迁移到MySQL上，可以针对配置中心方便开发出一些对外接口，例如用户可配置的动态更新参数，同时实现视图化和刷新机制。具体实现上，Config Server端需要增加服务中心jar包、配置中心jar包、连接MySQL数据库相关jar包，并配置好连接信息和SQL查询语句。具体实现参考https://www.cnblogs.com/qdhxhz/p/9624386.html

7. 总结

至此，已经介绍了Spring Cloud初学者需要学习的一些主要组件，从服务注册与发现，到服务调用、负载均衡、熔断与降级、配置管理以及API网关。掌握了这些基础后，下一步可以学习Spring Cloud Alibaba，这是一个更加强大和灵活的解决方案，它集成了Nacos、Sentinel、RocketMQ等组件，能够更好地支持分布式系统的开发与运维，本项目开源在github大家可以自行查看。