跟我学Spring Cloud(Finchley版)-20-Spring Cloud Config-

跟我学Spring Cloud(Finchley版)-19-配置中心-Spring Cloud Config 一节中,已实现使用Git仓库作为Config Server的后端存储,本节详细探讨如何配置Git仓库。

一、占位符支持

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

示例:

server:
  port: 8080
spring:
  application:
    name: microservice-config-server
  cloud:
    config:
      server:
        git:
          uri: https://git.oschina.net/itmuch/{application}
          username:
          password:

使用这种方式,即可轻松支持一个应用对应一个Git仓库。同理,也可支持一个profile对应一个Git仓库。

二、模式匹配

模式匹配指的是带有通配符的{application}/{profile}名称的列表。如果{application}/{profile}不匹配任何模式,它将会使用spring.cloud.config.server.git.uri 定义的URI。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          repos:
            simple: https://github.com/simple/config-repo
            special:
              pattern: special*/dev*,*special*/dev*
              uri: https://github.com/special/config-repo
            local:
              pattern: local*
              uri: file:/home/configsvc/config-repo

该例中,对于simple仓库,它只匹配所有配置文件中名为simple的应用程序,它的模式等同于simple/* 。local仓库则匹配所有配置文件中以local开头的所有应用程序的名称。

三、搜索目录

很多场景下,我们可能把配置文件放在了Git仓库子目录中,此时可以使用search-paths指定,search-path同样支持占位符。

spring:
  cloud:
    config:
      server:
        git:
          uri: http://git.oschina.net/itmuch/spring-cloud-config-repo
          search-paths: foo,bar*

这样,Config Server就会在Git仓库根目录、foo子目录、以及所有以bar开始的子目录中查找配置文件。

四、启动时加载配置文件

默认情况下,在配置被首次请求时,Config Server才会clone Git仓库。我们也可让Config Server在启动时就clone Git仓库,例如。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          repos:
            team-a:
                pattern:  microservice-*
                clone-on-start: true
                uri: http://git.oschina.net/itmuch/spring-cloud-config-repo

将属性spring.cloud.config.server.git.repos.*.clone-on-start 设为true,即可让Config Server启动时clone指定Git仓库。

当然,也可使用spring.cloud.config.server.git.clone-on-start = true 进行全局配置。

配置clone-on-start = true,可帮助Config Server启动时快速识别错误的配置源(例如无效的Git仓库)。

小技巧

将以下包的日志级别设为DEBUG,即可打印Config Server请求Git仓库的细节。我们可借助日志,更好地理解Config Server的Git仓库配置,同时,也便于我们快速定位问题。

logging:
  level:
    org.springframework.cloud: DEBUG
    org.springframework.boot: DEBUG

本文首发

http://www.itmuch.com/spring-cloud/finchley-20/

干货分享

原文地址:http://blog.51cto.com/10180481/2348968

时间: 2024-10-08 09:06:55

跟我学Spring Cloud(Finchley版)-20-Spring Cloud Config-的相关文章

跟我学Spring Cloud(Finchley版)-20-Spring Cloud Config-Git仓库配置详解 原

在跟我学Spring Cloud(Finchley版)-19-配置中心-Spring Cloud Config 一节中,已实现使用Git仓库作为Config Server的后端存储,本节详细探讨如何配置Git仓库. 一.占位符支持 Config Server的占位符支持{application}.{profile}和{label}. 示例: server: port: 8080 spring: application: name: microservice-config-server cloud

跟我学Spring Cloud(Finchley版)-13-通用方式使用Hystrix

本节详细讲解使用Hystrix的通用方式. 简介 Hystrix是由Netflix开源的一个延迟和容错库,用于隔离访问远程系统.服务或者第三方库,防止级联失败,从而提升系统的可用性与容错性.Hystrix主要通过以下几点实现延迟和容错. 包裹请求 使用HystrixCommand(或HystrixObservableCommand)包裹对依赖的调用逻辑,每个命令在独立线程中执行.这使用到了设计模式中的"命令模式". 跳闸机制 当某服务的错误率超过一定阈值时,Hystrix可以自动或者手

跟我学Spring Cloud(Finchley版)-07-Ribbon入门

经过前文讲述,我们已经实现了服务发现.本节来解决 跟我学Spring Cloud(Finchley版)-02-构建分布式应用 提到的如下问题: 负载均衡如何考虑?难道得在电影微服务和用户微服务之间加个NGINX做负载均衡吗?听起来是可行的,但如果有10000+服务(这并不夸张,我司的微服务数目是这个数字乘以N,N >= m,哈哈哈)那这个NGINX的配置得有多复杂-- 一般来说,提到负载均衡,大家一般很容易想到浏览器 -> NGINX -> 反向代理多个Tomcat这样的架构图--业界管

跟我学Spring Cloud(Finchley版)-17-Zuul路由配置详解

上一节( 跟我学Spring Cloud(Finchley版)-16-Zuul )中,已经实现用Zuul转发到Eureka上的微服务.默认的路由规则是:访问$ZUUL_URL/指定为服务/** 会被转发到指定微服务 的/** . 但在实际项目中,往往需要自己定义路由规则,Zuul的路由配置非常灵活.简单,本节详细讲解Zuul的路由配置. 一.自定义指定微服务的访问路径 配置zuul.routes.指定微服务的serviceId = 指定路径 即可.例如: zuul: routes: micros

Spring Cloud(四):服务容错保护 Hystrix【Finchley 版】

Spring Cloud(四):服务容错保护 Hystrix[Finchley 版] 发表于 2018-04-15 |  更新于 2018-05-07 | 分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况,这种现象被称为服务雪崩效应.为了应对服务雪崩,一种常见的做法是手动服务降级.而 Hystrix 的出现,给我们提供了另一种选择. Hystrix [h?st'r?ks] 的中文含义是 "豪猪",豪猪周身长满了刺,能保护自己不受天敌的伤害,代表了一种防御机制,这与 Hy

Spring Cloud(十二):分布式链路跟踪 Sleuth 与 Zipkin【Finchley 版】

Spring Cloud(十二):分布式链路跟踪 Sleuth 与 Zipkin[Finchley 版] 发表于 2018-04-24 | 随着业务发展,系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成,当整个请求变慢或不可用时,我们是无法得知该请求是由某个或某些后端服务引起的,这时就需要解决如何快读定位服务故障点,以对症下药.于是就有了分布式系统调用跟踪的诞生. 现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文<Dapper, a Larg

Spring Cloud(九):配置中心(消息总线)【Finchley 版】

Spring Cloud(九):配置中心(消息总线)[Finchley 版] 发表于 2018-04-19 |  更新于 2018-05-07 | 我们在 Spring Cloud(七):配置中心(Git.Refresh) 中讲到,如果需要客户端获取到最新的配置信息需要执行refresh,我们可以利用 Webhook 的机制每次提交代码发送请求来刷新客户端,当客户端越来越多的时候,需要每个客户端都执行一遍,这种方案就不太适合了.使用 Spring Cloud Bus 可以完美解决这一问题. Sp

Spring Cloud(十一):服务网关 Zuul(过滤器)【Finchley 版】

Spring Cloud(十一):服务网关 Zuul(过滤器)[Finchley 版] 发表于 2018-04-23 |  更新于 2018-05-07 | 在上篇文章中我们了解了 Spring Cloud Zuul 作为网关所具备的最基本功能:路由(Router).本文我们将关注 Spring Cloud Zuul 的另一核心功能:过滤器(Filter). Filter 的作用 我们已经能够实现请求的路由功能,所以我们的微服务应用提供的接口就可以通过统一的 API 网关入口被客户端访问到了.但

Spring Cloud Finchley 正式发布,包含 4 个重大更新!

在 Spring 的官方博客上已经看到 Spring Cloud Finchley 在 06 月 19 日这一天正式发布了,我们在 Maven 中央仓库也看到了最新版的更新. Finchley 正式版的发布貌似经历了相当长的时间,果然是闷声发大财,这次的重大发布主要带来了以下 4 项重大更新. 重大更新 1.新增 Spring Cloud Gateway 组件 Spring Cloud Gateway 是一个基于 Spring Webflux 和响应式 Netty 的下一代 API 网关,用来替