Spring Cloud Config 学习(二)

《Spring Cloud与Docker 微服务架构实战》学习笔记

Config Client

在上篇文章中，我们已经编写好了 Config Server 那个客户端是如何访问 Config Server 并且获取到对应的配置呢？

下面我们就来了解一下

集成

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

在application.properties中配置一下端口:

server.port=8081

创建配置文件bootstrap.yml，然后在其中添加一下内容

spring:
  application:
    # 对应Config Server 中的{application}
    name: microservice-foo
  cloud:
    config:
      # Config Server地址
      uri: http://localhost:8080/
      # profile 对应 Config Server 中的{profile}
      profile: dev
      # label 对应 Config Server 中的{label} Git分支
      label: master

这里只能使用指定的配置配置文件名称，使用其他的文件名称无效

按照书中的说法，Spring Cloud 中有"引导上下文"的概念，这是主应用程序的父上下文。引导上下文负责从配置服务器加载配置属性，以及解密外部配置文件中的属性。

和主应用程序加载application.*(yml或properties)中的属性不同，引导上下文加载bootstrap.*中的属性。配置在bootstrap.*中的属性有更高的优先级，因此默认情况下他们不能被本地

配置覆盖

按照我的理解，简单点来说bootstrap.* 就像是 application.* 的父类，但是有一点不同的是，bootstrap中的属性不会被application.*中的属性所覆盖

只需要这样简单的配置，就已经可以从Config Service 中拉取属性了

验证

验证一下

@RestController
public class ConfigClientController {

    @Value("${profile}")
    private String profile;

    @GetMapping("/profile")
    public String hello() {
        return this.profile;
    }

}

启动 Config Service 启动 Config Client，访问

http://localhost :8081/profile ，显示:

Config Server的Git 仓库配置

占位符支持

Config Service 的占位符支持{application}、{profile} 和 {label}

例如修改原来的Config Service的配置：

spring.application.name=microservice-config-server

# 这个uri使用可以clone的路径
spring.cloud.config.server.git.uri=https://github.com/wkkdhr/{application}.git

# github的账号密码
spring.cloud.config.server.git.username=***
spring.cloud.config.server.git.password=***

在Git上新增配置文件 Dome1-dev.properties 内容如下：

profile=dome1-dev-1.0

然后访问 http://localhost :8080/Dome1-dev.properties 即可得到如下结果：

profile: dome1-dev-1.0

书中说这样可以支持一个应用一个Git仓库。看到这里应该明白了，书中所说的占位符{application}、{profile} 和 {label} 指的是访问url中的对应的内容。例如访问路径是 http://localhost :8080/Dome1-dev.properties 时，其中 Dome1 就是{application}，dev 就是 {profile} ，{label} 被省略，默认 master。按照配置文件中的配置 https://github.com/wkkdhr/{application}.git 系统就会去 https://github.com/wkkdhr/Dom... 这个Git仓库中，找到 Dome1-dev.properties 这个配置文件。

匹配模式

配置模式就是通过匹配要访问的配置文件名称，来访问不同的git仓库。如果没有符合的，就会访问 spring.cloud.config.server.git.uri 所定义的仓库

配置模式是{application}/{profile}。多个匹配规则用逗号 , 分隔

例如：

spring.cloud.config.server.git.uri=https://github.com/wkkdhr/Dome1.git

spring.cloud.config.server.git.repos.test.pattern=test*/dev*
spring.cloud.config.server.git.repos.test.uri=https://github.com/wkkdhr/configTest.git

就以上面配置为例子，其中 repos.test.pattern 中的test可以是名称可以自己起。 test*/dev* 是匹配规则，意思是配置{application}以test开头并且{profile}以dev开头的。如果符合匹配规则就回去访问 https://github.com/wkkdhr/configTest.git 这个仓库。

http://localhost :8080/test-dev.properties 这里路径，{application}是test，{profile}是dev，符合上面所定义的规则，所以就会去访问 spring.cloud.config.server.git.repos.test.uri 所定义的仓库。

如果是 http://localhost :8080/test-d1.properties 这个。它就是不符合规则的，就会去访问 https://github.com/wkkdhr/Dome1.git 这个仓库。

spring.cloud.config.server.git.repos.simple=https://github.com/wkkdhr/simple.git

如果像上面那样配置，就只会匹配以test开头的配置文件。

同时这个目标地址还可以配置成本地的路径：

spring.cloud.config.server.git.repos.local.pattern=test*
spring.cloud.config.server.git.repos.local.uri=file:/D://project//demo//github//configTest

搜索目录

这个就比较见到了，就是可以去搜索目标Git仓库的子目录。如果是子目录的子目录，需要填写路径

spring.cloud.config.server.git.uri=https://github.com/wkkdhr/Dome1.git
spring.cloud.config.server.git.search-paths=test1,test1*,file/test1,file/test*

启动时加载配置文件

spring.cloud.config.server.git.clone-on-start=true

通过配置 clone-on-start 来让Config Service启动时就clone指定的Git仓库

或者是给指定Git仓库单独配置：

spring.cloud.config.server.git.repos.test.uri=https://github.com/wkkdhr/configTest.git
spring.cloud.config.server.git.repos.test.clone-on-start=true

以下配置可以打印相关日志，但是也会同时打印许多不相关的配置信息，自行斟酌。

logging.level.org.springframework.cloud=debug
logging.level.org.springframework.boot=debug

Config Service 健康监控

Config Service 集成了 Actuator。可以通过访问 health 的端口来查询当前的健康状态。

# 配置来让health显示详细信息
management.endpoint.health.show-details=always

书中说，默认情况下，健康指示器向EnvironmentRepository请求的{application}是app,{profile}和{lable}是对应的EnvironmentRepository 实现的默认值。对于Git，{profile} 是 default，{ablel}是master.

但是我在配置仓库并没有相应的配置文件，结果仍旧显示UP。没有深究。

可以通过配置去检查指定的配置文件：

spring.cloud.config.server.health.repositories.test.name=test
spring.cloud.config.server.health.repositories.test.label=master
spring.cloud.config.server.health.repositories.test.profiles=dev

访问 http://localhost :8080/actuator/health 结果如下：

{
    "status": "UP",
    "details": {
        "diskSpace": {
            "status": "UP",
            "details": {
                "total": 214752784384,
                "free": 135328772096,
                "threshold": 10485760
            }
        },
        "refreshScope": {
            "status": "UP"
        },
        "configServer": {
            "status": "UP",
            "details": {
                "repositories": [
                    {
                        "name": "test",
                        "profiles": [
                            "dev"
                        ],
                        "label": "master"
                    }
                ]
            }
        }
    }
}

可以通过设置 spring.cloud.config.server.health.enabled=false 来禁用健康检查。

spring.cloud.config.server.health.enabled=false

发现一个事情，就是在spring配置文件中，有很多配置都是没有提示的，就像上面这个属性。显示的是类似于用户自己定义的属性的那种黄色背景。意思就是这个不是系统的属性，但是确认是生效的。我一开始还以为是过时的配置之类，大概是 spring 全家桶配置太多了，idea 也没有办法给出全部的提示吧。