配置中心：Spring Cloud Config

声明：
1.本节将会把配置中心集成在Eureka的服务中心里，所以将会使用Spring Cloud Netflix Eureka + Spring Cloud Config来完成本节内容
2.入门级文档，更多内容会持续更新，不足之处，望不吝指点

一、简介

Spring Cloud Config和Nacos不同，它虽然也支持自身发布配置，但是其主要的配置来源还是其他的存储类应用，比如Git、SVN、Valut、数据库等等，Spring Cloud Config的作用就是提供一个抽象，不用让用户得知配置的具体来源，具体的操作细节等等。它就像是一个代理人，由它帮我们将配置从目标地方取出来，然后按照我们设置的策略分享给需要这些配置的服务。Spring Cloud Config的默认配置仓库是Git，这也是使用得最多得一种方案，故本节也将使用Git来进行讲解和演示。

二、配置中心（服务端，配置发布者）

• 依赖（不显示Eureka相关依赖）

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

• 配置（基于Git）
  • 端口号
    Spring Cloud Config Client默认会从8888端口获取配置，所以你可以为了图个方便将配置中心的端口号也改为8888，本节示例使用的端口号是8089
  • 关闭Spirng Cloud Config Client
    服务端不需要

  spring.cloud.config.enabled=false
  

  • （可选）配置的发布路径前缀
    默认为空字符串，即从根目录下直接访问就可以了，但是本节为了和Eureka服务中心的相关的配置不冲突，我修改了前缀为config-mtk，这样所有的配置将会发布在/config-mtk/下

  spring.cloud.config.server.prefix=/config-mtk
  

  • Git仓库的路径
    • 可以使用本地的Git仓库，如果仓库路径的开头是file://的话，就代表启用本地的Git仓库作为配置来源，注意Windows下应当是以file:///开头
    • 可以在路径名中使用特殊的占位符，具体可看Placeholders in Git URI

  spring.cloud.config.server.git.uri=https://xxx/shiinamutsuki/config-center
  

  • Git仓库用户名及密码

  spring.cloud.config.server.git.username=
  spring.cloud.config.server.git.password=
  

  • （极其重要）SSL验证
    如果你想通过SSL来保证访问的安全性，那请跳过这段。如果你不知道SSL验证是啥，我建议这里关闭SSL验证，否则你将会陷入PKIX path building failed: sun.security.provider .certpath.SunCertPathBuilderException: unable to find valid certifi cation path to requested target的错误，而为此痛苦不已，当然你也可以选择直接面对它，这时你需要下载对应网站的证书，并将其添加到你jre的证书库中，然后稍等一会儿。

  spring.cloud.config.server.git.skip-ssl-validation=true
  

  • （可选）配置默认分支
    如果客户端没有指定从哪个分支获取配置，将会从默认分支中提取

  spring.cloud.config.server.git.default-label=<分支名>
  

  • （可选）配置配置获取的超时时间，默认5s

  spring.cloud.config.server.git.timeout=5
  

  • （可选）强制拉取更新
    Spring Cloud Config会在本地保存一个克隆的仓库，但是如果因为意外导致这个克隆的仓库文件发生了变化，那么Spring Cloud Config将无法把克隆的仓库进行更新，这时如果配置了强制拉取更新，那么这个问题就会得以解决。

  spring.cloud.config.server.git.force-pull=true
  

  • （可选）强制删除未匹配到的分支
    Spring Cloud Config默认不会删除任何本地仓库的任何分支，即使远程仓库中的对应分支已经删除，除非重启配置中心，这样将会新建一个本地仓库。你可能不太清楚这会产生什么问题，让我举个例子，假设远端仓库有两个分支一个是test，另外一个是master，你在你的客户端中配置了spring.cloud.config.label=test,master，想达到我无需改动配置，只要将远端仓库的test分支删除，就可以实现从测试环境到正式环境的转换的目的。这时你会发现就算你删除了test分支，但是你的应用依旧在测试环境中，因为本地的仓库压根就没有删除test分支。

  spring.cloud.config.server.git.delete-untracked-branches=true
  

  • （可选）缓存配置的持续的时间
    由于有本地仓库的存在，所以如果你的应用配置更新不频繁，且对在配置做出变化时需要应用立刻进行响应的要求不高，那么你可以进行这项配置，Spring Cloud Config将会每隔一段时间将本地仓库更新，而不是在每次请求配置的时候更新

  # 默认是0
  spring.cloud.config.server.git.refresh-rate=5
  

  • （可选）如果你想使用SSH的链接，你可以参照Authentication
    和Git SSH configuration using properties
  • （可选）配置多个Git仓库，可以参照Pattern Matching and Multiple Repositories
  • （可选）全局配置
    Spring Cloud Config也支持像Nacos那样自己发布配置，不过这个配置是全局配置，对所有从配置中心获取配置的人都会返回额外返回一份这个全局配置。附加说一点，全局配置不仅仅只可以配置在配置中心本身里，也可以配置在远端仓库中，当你的远端仓库存在一个application.yaml或者是application.properties文件时，该配置文件的内容也将额外作为全局配置一起呗返回。这两种全局配置的方式可以一起使用。下列例子中，我将Eureka Client的配置作为全局配置设置在了配置中心中。

  spring
    cloud:
      config:
        server:
          overrides:
            eureka.client.service-url.defaultZone: http://mtk:123456@localhost:8089/eureka/
            eureka.instance.prefer-ip-address: true
            eureka.instance.instance-id: $\{spring.application.name}:$\{spring.cloud.client.ip-address}:$\{server.port}
  

  $\{}将会被解析为${}，如果直接使用${}你会发现有趣的现象

• 使能配置中心@EnableConfigServer

@SpringBootApplication
@EnableConfigServer
public class EurekaServerApplication {

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

• 验证
  • 启动配置中心
  • 访问配置

  $ curl localhost:8089/config-mtk/eureka-test/eureka-test-provider.properties
  cn.mtk.hello: hello
  eureka.client.service-url.defaultZone: http://mtk:123456@localhost:8089/eureka/
  eureka.instance.instance-id: ${spring.application.name}:${spring.cloud.client.ip-address}:${server.port}
  eureka.instance.prefer-ip-address: true
  

  需要说明的是，即使没有找到对应的配置，全局配置也会被返回。附加：支持的访问url格式可以参照：
  {prefix}/{application}/{profile}[/{label}]
{prefix}/{application}-{profile}.yml
{prefix}/{label}/{application}-{profile}.yml
{prefix}/{application}-{profile}.properties
{prefix}/{label}/{application}-{profile}.properties

三、配置客户端（客户端，配置接收者）

• 依赖

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

• 配置
  注意：客户端由于要在接受本地配置要前先接受远端配置，故需要将Spring Cloud Config相关的配置配置在启动配置文件中bootstrap.yaml
  • 服务名
    服务名将会作为配置获取路径的组成部分之一，所以需要配置好
  • 配置中心地址
    注意配置到访问前缀为止

  spring.cloud.config.uri=http://localhost:8089/config-mtk
  

  • 访问的配置分支

  spring.cloud.config.label=eureka-test
  

  • （可选）快速失败操作
    如果你需要客户端在没有接收到配置时抛出异常并中止服务，你可以进行该项配置

  spring.cloud.config.fail-fast=true
  

  • （可选）（承接快速失败操作）如果你不想单纯一次就判定为失败，你可以尝试使用spring.cloud.config.retry.*系列的配置来进行失败重试的相关配置，不过你得添加额外的依赖spring-retry和spring-boot-starter-aop，具体请看Config Client Retry
  • （可选）超时相关配置

  spring.cloud.config.request-read-timeout=
  spring.cloud.config.request-connect-timeout=
  

• 启动
• 额外说明
  • ConfigServicePropertySourceLocator这个Bean包含了许多配置文件中不能配置的配置，比如RestTemplate实例等等，如果需要可以尝试对该Bean进行自定义，具体操作可查Providing A Custom RestTemplate
  • 你会发现本节是将服务发现相关的配置放在了配置中心中，而每个客户端都只配置了配置中心的配置，那么你会想，如果配置中心发生了变更，要一个个客户端去更改配置不是太过麻烦，能不能让服务中心运行在配置中心之前呢，答案是可以的，但是那样同样会造成几个问题，每个客户端需要配置服务中心的地址了，且启动阶段时间将会大大延长，因为需要在启动期间进行服务发现的配置，然后获取配置中心的服务，然后获取配置，然后进行配置。关于这部分内容你可以参考Discovery First Bootstrap

参考文档：
[1] Spring Cloud Config官方文档2.2.2.RELEASE