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 也没有办法给出所有的提示吧。