spring cloud config 詳解

時間 2019-11-11

原文原文鏈接

Spring Cloud 爲開發人員提供了一系列的工具來快速構建分佈式系統的通用模型。例如：配置管理、服務發現、斷路由、智能路由、微代理、控制總線、一次性Token、全局鎖、決策競選、分佈式session、集羣狀態等等。分佈式系統的協助須要一大堆的模型，使用Spring Cloud開發者能快速的創建支持實現這些模式的服務和應用程序。他們將適用於任何分佈式環境，不管是開發者的我的電腦仍是生產環境，仍是雲平臺。html

版本：Brixton.SR3
做者：鏈上研發-歐陽
（注：閱讀前置技能樹 Spring 以及Spring的 Property Source、Environment、Profile 和 Spring Boot ,原始文檔有些沒頭沒尾的，適當添加了些內容。）java

Spring Cloud中文文檔（持續更新中。。。）mysql

特性

Spring Cloud 專一於提供良好開箱即用的典型方案和可擴展方式。linux

分佈式/版本化配置
服務註冊/服務發現
路由
服務間調用
負載均衡
斷路器
全局鎖
領導選取和集羣狀態監控
分佈式消息

Cloud Native 應用

Cloud Native是一種持續交付和價值驅動開發推薦的最佳實踐方式。它的理念包含了DevOps、持續交付、微服務、敏捷基礎設施、康威定律，以及根據商業能力對公司進行重組。一個很好的契約例子是12-factor Apps。Spirng Cloud 提供了一系列的工具和特性來促進這些開發，全部的組件都是基於分佈式，而且很是容易開始使用。git

構建Spring Cloud的大部分特性都是基於Spring Boot的。Spring Cloud的一些特性來源於兩個庫：Spring Cloud Context 和 Spring Cloud Commons。Spring Cloud Context爲Spring Cloud應用程序的ApplicationContext提供了基礎的服務（啓動上下文，加密，刷新做用域和環境端點）。Spring Cloud Commons是爲實現不一樣的Spring Cloud實現的抽象。（例如：Spring Cloud Netflix 和 Spring Cloud Consul）github

若是使用Sun的JDK遇到Illegal key size異常，須要安裝JCE
更多信息請查看：web

提取文件到JDK/jre/lib/security文件夾（不管你使用的那個版本的JRE/JDK x64/x86）spring

注意：

Spring Cloud是基於非限制性的Apache 2.0 license發佈的。若是你發現文檔有問題，或只是想提升它們的質量，請到 github上參與進來。

Spring Cloud 上下文

Spring Boot使用約定的方式來構建Spring應用，例如：它約定了配置文件的位置、通用的端點管理和監控任務。Spring Cloud創建在它的上面，而且增長了一些分佈式系統可能須要的組件。sql

啓動上下文

Spring Cloud會建立一個`Bootstrap Context`，做爲Spring應用的`Application Context`的父上下文。初始化的時候，`Bootstrap Context`負責從外部源加載配置屬性並解析配置。這兩個上下文共享一個從外部獲取的`Environment`。`Bootstrap`屬性有高優先級，默認狀況下，它們不會被本地配置覆蓋。 `Bootstrap context`和`Application Context`有着不一樣的約定，因此新增了一個`bootstrap.yml`文件，而不是使用`application.yml` (或者`application.properties`)。保證`Bootstrap Context`和`Application Context`配置的分離。下面是一個例子： **bootstrap.yml**docker

spring:
  application:
    name: foo
  cloud:
    config:
      uri: ${SPRING_CONFIG_URI:http://localhost:8888}

推薦在`bootstrap.yml` or `application.yml`裏面配置`spring.application.name`. 你能夠經過設置`spring.cloud.bootstrap.enabled=false`來禁用`bootstrap`。

應用上下文層次結構

若是你經過`SpringApplication`或者`SpringApplicationBuilder`建立一個`Application Context`,那麼會爲spring應用的`Application Context`建立父上下文`Bootstrap Context`。在Spring裏有個特性，子上下文會繼承父類的`property sources` and `profiles` ，因此`main application context` 相對於沒有使用Spring Cloud Config，會新增額外的`property sources`。額外的`property sources`有：

「bootstrap」 : 若是在Bootstrap Context掃描到PropertySourceLocator而且有屬性，則會添加到CompositePropertySource。Spirng Cloud Config就是經過這種方式來添加的屬性的，詳細看源碼ConfigServicePropertySourceLocator`。下面也也有一個例子自定義的例子。
「applicationConfig: [classpath:bootstrap.yml]」，（若是有spring.profiles.active=production則例如 applicationConfig: [classpath:/bootstrap.yml]#production）: 若是你使用bootstrap.yml來配置Bootstrap Context，他比application.yml優先級要低。它將添加到子上下文，做爲Spring Boot應用程序的一部分。下文有介紹。

因爲優先級規則，Bootstrap Context不包含從bootstrap.yml來的數據，可是能夠用它做爲默認設置。(其實就是最低的優先級，測試過)

你能夠很容易的擴展任何你創建的上下文層次，可使用它提供的接口，或者使用SpringApplicationBuilder包含的方法（parent()，child()，sibling()）。Bootstrap Context將是最高級別的父類。擴展的每個Context都有有本身的bootstrap property source（有多是空的）。擴展的每個Context都有不一樣spring.application.name。同一層層次的父子上下文原則上也有一有不一樣的名稱，所以，也會有不一樣的Config Server配置。子上下文的屬性在相同名字的狀況下將覆蓋父上下文的屬性。

注意SpringApplicationBuilder容許共享Environment到全部層次，可是不是默認的。所以，同級的兄弟上下文不在和父類共享一些東西的時候不必定有相同的profiles或者property sources。

修改Bootstrap屬性配置

源碼位置BootstrapApplicationListener。

   String configName = environment.resolvePlaceholders("${spring.cloud.bootstrap.name:bootstrap}");

    String configLocation = environment.resolvePlaceholders("${spring.cloud.bootstrap.location:}");

    Map<String, Object> bootstrapMap = new HashMap<>();bootstrapMap.put("spring.config.name",configName);
    if(StringUtils.hasText(configLocation)){
        bootstrapMap.put("spring.config.location", configLocation);
    }

bootstrap.yml是由spring.cloud.bootstrap.name（默認:」bootstrap」）或者spring.cloud.bootstrap.location（默認空）。這些屬性行爲與spring.config.*相似，經過它的Environment來配置引導ApplicationContext。若是有一個激活的profile（來源於spring.profiles.active或者Environment的Api構建），例如bootstrap-development.properties 就是配置了profile爲development的配置文件.

覆蓋遠程屬性

property sources被bootstrap context 添加到應用一般經過遠程的方式，好比」Config Server」。默認狀況下，本地的配置文件不能覆蓋遠程配置，可是能夠經過啓動命令行參數來覆蓋遠程配置。若是須要本地文件覆蓋遠程文件，須要在遠程配置文件裏設置受權
spring.cloud.config.allowOverride=true（這個配置不能在本地被設置）。一旦設置了這個權限，你能夠配置更加細粒度的配置來配置覆蓋的方式，

好比：
- spring.cloud.config.overrideNone=true 覆蓋任何本地屬性
- spring.cloud.config.overrideSystemProperties=false 僅僅系統屬性和環境變量
源文件見PropertySourceBootstrapProperties

自定義啓動配置

bootstrap context是依賴/META-INF/spring.factories文件裏面的org.springframework.cloud.bootstrap.BootstrapConfiguration條目下面，經過逗號分隔的Spring @Configuration類來創建的配置。任何main application context須要的自動注入的Bean能夠在這裏經過這種方式來獲取。這也是ApplicationContextInitializer創建@Bean的方式。能夠經過@Order來更改初始化序列，默認是」last」。

# spring-cloud-context-1.1.1.RELEASE.jar # spring.factories # AutoConfiguration org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ org.springframework.cloud.autoconfigure.ConfigurationPropertiesRebinderAutoConfiguration,\ org.springframework.cloud.autoconfigure.RefreshAutoConfiguration,\ org.springframework.cloud.autoconfigure.RefreshEndpointAutoConfiguration,\ org.springframework.cloud.autoconfigure.LifecycleMvcEndpointAutoConfiguration # Application Listeners org.springframework.context.ApplicationListener=\ org.springframework.cloud.bootstrap.BootstrapApplicationListener,\ org.springframework.cloud.context.restart.RestartListener # Bootstrap components org.springframework.cloud.bootstrap.BootstrapConfiguration=\ org.springframework.cloud.bootstrap.config.PropertySourceBootstrapConfiguration,\ org.springframework.cloud.bootstrap.encrypt.EncryptionBootstrapConfiguration,\ org.springframework.cloud.autoconfigure.ConfigurationPropertiesRebinderAutoConfiguration,\ org.springframework.boot.autoconfigure.PropertyPlaceholderAutoConfiguration

警告

當心，你添加的自定義BootstrapConfiguration類沒有錯誤的@ComponentScanned到你的主應用上下文，他們多是不須要的。使用一個另外的包不被@ComponentScan或者@SpringBootApplication註解覆蓋到。

bootstrap context經過spring.factories配置的類初始化的全部的Bean都會在SpingApplicatin啓動前加入到它的上下文裏去。

自定義引導配置來源：Bootstrap Property Sources

默認的`property source`添加額外的配置是經過配置服務（Config Server），你也能夠自定義添加`property source`經過實現`PropertySourceLocator`接口來添加。你可使用它加配置屬性從不一樣的服務、數據庫、或者其餘。

下面是一個自定義的例子:

@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {

    @Override
    public PropertySource<?> locate(Environment environment) {
        return new MapPropertySource("customProperty",
                Collections.<String, Object>singletonMap("property.from.sample.custom.source", "worked as intended"));
    }
}

Environment被ApplicationContext創建，並傳入property sources（可能不一樣個profile有不一樣的屬性），因此，你能夠從Environment尋找找一些特別的屬性。好比spring.application.name，它是默認的Config Server property source。

若是你創建了一個jar包，裏面添加了一個META-INF/spring.factories文件：

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator

那麼，」customProperty「的PropertySource將會被包含到應用。

Environment改變

應用程序將監聽EnvironmentChangeEvent，而且響應這一些改變（添加的ApplicationListeners能夠被用戶用標準的方式增長到@Beans）。當EnvironmentChangedEvent觀察到這些值被改變，會觸發這些事情：

從新綁定@ConfigurationProperties bean到上下文
根據logging.level.*來捨得屬性的日誌級別

默認狀況下，Config Client不輪詢Environment的改變。通常狀況，不建議使用這種方式來監測變化（雖然你能夠經過@Scheduled註解來設置）。對於可擴展的應用程序，使用廣播EnvironmentChangeEvent到全部實例的方式，好過輪詢的方式。（好比使用Spring Cloud Bus項目）。

修改Environment能夠經過發佈EnvironmentChangeEvent來作，這是Spring核心Api的方式。你能夠經過觀察/configprops端點（Spring Boot Actuator的特性）來檢查這些改變綁定到@ConfigurationProperties的bean的狀況。對於DataSource這樣一個實例，在運行的時候修改maxPoolSize增長大小，修改的變化不會通知實例裏面，可使用@RefreshScope來初始化Bean。

@RefreshScope

一個Spring的@Bean在添加了@RefreshScope註解，能夠解決Bean初始化的時候只能得到初始配置的問題。好比，在使用DataSource得到一個數據庫鏈接的是時候，當經過Environment修改數據庫鏈接字符串的時候，咱們能夠經過執行@RefreshScope倆根據修改的配置獲取一個新的URL的鏈接。

@RefreshScope的beans，在使用它初始化的時候是延遲代理的。經過RefreshEndpoint Bean來控制。或者/refresh請求來從新初始化。

注意

@RefreshScope註解在一個 @Configuration類上面，在從新初始化的時候須要注意到能夠相互依賴形成的衝突。

加密和解密

Spring Cloud能夠在本地進行預處理的解密，與Config Server有相同的規則，經過設置相同的`encrypt.*`來實現。所以，可使用加密的值在`{cipher}*`上，在應用經過`Environment`得到屬值以前進行解密。使用加密特性須要包含Spring Security RSA的包到classpath。Maven依賴」org.springframework.security:spring-security-rsa」。而且，須要在JVM添加JCE擴展。若是使用Sun的JDK遇到`Illegal key size`異常，須要安裝JCE 更多信息請查看：

提取文件到JDK/jre/lib/security文件夾（不管你使用的那個版本的JRE/JDK x64/x86）。

端點

相對於Spring Boot Actuator的應用，添加了一些管理端點：

POST to /env 更新Environment從新加載@ConfigurationProperties和日誌級別
/refresh 從新初始化添加了@RefreshScope 的bean
/restart 重啓初始化ApplicationContext，重啓 (默認是禁用的)
/pause and /resume 調用ApplicationContext生命週期的方法stop()和start()

通用的抽象Spring Cloud Commons

好比服務發現、負載平衡和斷路器等通用的模型，自己是一個抽象層，能夠被全部Spring Cloud組件獨立的實現，例如服務發現有具體的實現Eureka、Consul。

Spring RestTemplate做爲負載均衡客戶端

RestTemplate 可使用ribbon自動配置，簡歷一個負載均衡的RestTemplate使用@Bean和@LoadBalanced來預設。

警告

RestTemplate不會經過自動配置創建，必須單獨配置。

@Configuration
public class MyConfiguration {

    @LoadBalanced
    @Bean
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

public class MyClass {
    @Autowired
    private RestTemplate restTemplate;

    public String doOtherStuff() {
        String results = restTemplate.getForObject("http://stores/stores", String.class);
        return results;
    }
}

這裏的URI須要使用虛擬主機名，好比服務名稱，而不是Host名稱。Ribbon客戶端用它來創建一個完整的物理地址。能夠查看`RibbonAutoConfiguration`的詳細去設置`RestTemplate`。

多個RestTemplate對象

若是你但願建立一個未負載均衡的`RestTemplate`，能夠用正常的方式來注意。訪問負載均衡方式的`RestTemplate`使用`@LoadBalanced`來註解你創建的`@Bean`

@Configuration
public class MyConfiguration {

    @LoadBalanced
    @Bean
    RestTemplate loadBalanced() {
        return new RestTemplate();
    }

    @Primary
    @Bean
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

public class MyClass {
    @Autowired
    private RestTemplate restTemplate;

    @Autowired
    @LoadBalanced
    private RestTemplate loadBalanced;

    public String doOtherStuff() {
        return loadBalanced.getForObject("http://stores/stores", String.class);
    }

    public String doStuff() {
        return restTemplate.getForObject("http://example.com", String.class);
    }
}

提示

若是你遇到了
java.lang.IllegalArgumentException: Can not set org.springframework.web.client.RestTemplate field com.my.app.Foo.restTemplate to com.sun.proxy.$Proxy89的錯誤提示，嘗試使用 spring.aop.proxyTargetClass=true的代理方式注入。

忽略網絡接口

有的時候，對於服務發現註冊，忽略某些命名的網絡接口是很是有用的，好比使用Docker容器的時候。能夠經過一些規則設置來忽略這些網絡接口，下面這個配置顯示了忽略「docker0」的入口，全部的入口以「veth.*」來匹配。詳細的配置類見`InetUtilsProperties`。

application.yml

spring:
  cloud:
    inetutils:
      ignoredInterfaces:
        - docker0 - veth.*

Spring Cloud Config

Spring Cloud Config提供了在分佈式系統的外部配置的客戶端支持。經過配置服務（Config Server）來爲全部的環境和應用提供外部配置的集中管理。這些概念都經過Spring的Environment和PropertySource來抽象，因此它能夠適用於各種Spring應用，同事支持任何語言的任何應用。它也能爲你支持對應用開發環境、測試環境、生產環境的配置、切換、遷移。默認的配置實現經過git實現，同事很是容易的支持其餘的擴展（好比svn等）。

快速開始

開始配置服務：

$ git clone https://github.com/spring-cloud/spring-cloud-config.git $ cd spring-cloud-config $ cd spring-cloud-config-server $ ../mvnw spring-boot:run

這是一個 Spring Boot應用，你能夠在IDE裏面經過ConfigServerApplication來啓動。

能夠看看效果：

$ curl localhost:8888/foo/development {"name":"development","label":"master","propertySources":[ {"name":"https://github.com/scratches/config-repo/foo-development.properties","source":{"bar":"spam"}}, {"name":"https://github.com/scratches/config-repo/foo.properties","source":{"foo":"bar"}} ]}

默認經過git資源加載配置屬性（使用spring.cloud.config.server.git.uri來配置git地址）。使用這些配置來初始化一個很是輕量的SpringApplication。這個應用的Environment加載屬性經過返回JSON對象的請求。

這些請求的Http資源下面這些

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

application 根據spring.config.name來得到
profile 激活的剖面，好比spring.profiles.active = test
label git資源的label 默認是master

必須提供一個git資源，Spring Cloud Config Server才能從遠程git服務pull資源來配置，例如：

spring:
  cloud:
    config:
      server: git: uri: https://github.com/spring-cloud-samples/config-repo

客戶端用法

配置服務通常做爲單獨的服務部署，各個須要的應用會添加一個客戶來從配置服務獲取配置。而配置服務的配置，依賴git提交的配置文件。

在Spring Boot應用裏面，使用這個特性須要添加spring-cloud-config-client的依賴。比較方即是方式是添加一個Spring Boot的starter依賴org.springframework.cloud:spring-cloud-starter-config。對於Maven用戶，有一個spring-cloud-starter-parent的父pom文件。對於Gradle和Spring CLI用戶，能夠用Spring IO版本管理文件。下面是Maven配置：

pom.xml

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.3.5.RELEASE</version> <relativePath /> <!-- lookup parent from repository --> </parent> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Brixton.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> <!-- 上面版本可能依賴一些snapshots版本，添加spring的資源 --> <repositories> <repository> <id>spring-milestones</id> <name>Spring Milestones</name> <url>http://repo.spring.io/milestone</url> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories>

建立一個簡單是Spring Boot的web應用：

@SpringBootApplication @RestController public class Application { @RequestMapping("/") public String home() { return "Hello World!"; } public static void main(String[] args) { SpringApplication.run(Application.class, args); } }

當你運行的時候，這個應用默認啓動8080端口，默認它會尋找本地的8888端口的配置服務。你能夠修改bootstrap.properties文件配置服務的uri：

spring.cloud.config.uri: http://myconfigserver.com

啓動加載的屬性能夠經過/env來查看，它有很高的優先級：

$ curl localhost:8080/env { "profiles":[], "configService:https://github.com/spring-cloud-samples/config-repo/bar.properties":{"foo":"bar"}, "servletContextInitParams":{}, "systemProperties":{...}, ... }

一條屬性是"configService:https://github.com/spring-cloud-samples/config-repo/bar.properties":{"foo":"bar"}裏面的配置，它有最高優先級的。屬性源中的 URL是git倉庫的地址而不是配置服務器的URL。

配置服務服務端 Spring Cloud Config Server

Spring Cloud Config Server提供了一個基本Http的，資源API的，可擴展的配置（使用key-value的properties或者類似的yaml的方式）。經過添加@EnableConfigServer很是容易的嵌入到了Spring Boot應用裏面。下面是一個配置服務的app：

ConfigServer.java

@SpringBootApplication @EnableConfigServer public class ConfigServer { public static void main(String[] args) { SpringApplication.run(ConfigServer.class, args); } }

Spring Boot應用一般默認啓動8080端口，Config Server一般切換到8888端口。在Config Server 的jar文件裏面configserver.yml默認配置了spring.config.name=configserver，你能夠在本身的配置文件裏面修改。

application.properties

server.port: 8888 spring.cloud.config.server.git.uri: file://${user.home}/config-repo

${user.home}/config-repo 是一個git資源包含YAML文件和屬性文件。

在Windows系統裏面，若是文件URL是絕對路徑，前面有驅動符號,你須要多增長個’/’符號, file:///${user.home}/config-repo.

下面是在建立例如上面的Git倉庫配方

$ cd $HOME $ mkdir config-repo $ cd config-repo $ git init . $ echo info.foo: bar > application.properties $ git add -A . $ git commit -m "Add application.properties"

使用本地的git資源最好只用做測試使用，生產環境建議使用git服務器。

初始化配置的是很是高效快速的，當你使用特別大的二進制文件，可能會遇到第一個請求延遲的狀況或者服務內存溢出的狀況。

補充

配置默認存儲在tmp文件目錄， linux系統默認會清理必定時間沒有更新的tmp目錄下的文件。生產環境上演出這一出悲劇。

資源庫環境Environment Repository

Config Server的配置數據存儲在哪裏?

解決這個問題的是`EnvironmentRepository`,服務`Environment`對象。`Environment`對象是對Spring的Environment(其中包括 propertySources作爲主要屬性)的淺拷貝。Environment資源被參數化成了3個變量:

{application} 對應客戶端的」spring.application.name」
{profile} 對應客戶端的」spring.profiles.active」（逗號分隔）
{label} 服務端依賴的資源文件標記（好比git 的master）

配置庫資源實現的表形式與Spring Boot的配置相關，好比{application}參數來自」spring.config.name」，{profiles}來自」spring.profiles.active」，profiles的優先級規則也和Spring Boot應用同樣。激活的profiles的優先級高於默認的，有多個profiles，最後一個起做用。與Map的set操做相似。

例如:

bootstrap.yml

spring:
  application: name: foo profiles: active: dev,mysql

與Spring Boot應用程序同樣，這些參數也能夠經過環境變量或命令行參數進行設置。

若是配置庫是基於文件的，服務器將優先根據foo.yml，在根據application.yml建立一個Environment對象。若是這些 YAML文件中有指定了Spring profiles，那麼這些profiles將有較高優先級，同時若是存在指定profile後綴YAML(或properties)文件，這些文件就比默認的文件具備更高的優先級。高優先級的配置優先轉成Environment對象中的PropertySource。(這和單獨的Spring Boot系統使用的規則是同樣的）

後端的git

EnvironmentRepository默認狀況下，經過依賴git服務來實現。git能夠很是方便的修改升級配置，並且能夠審查變動記錄。能夠在你的配置服務（好比application.yml文件）裏面添加spring.cloud.config.server.git.uri配置指定git資源。你也能夠直接使用file:前綴來配置一個本地資源，來快速開始你的服務。爲了提升配置服務的高可用性和擴展性，你須要有指向同一個版本庫服務器的全部實例，因此只有一個共享文件系統是可行的。即便在這種狀況下，最好是使用ssh：協議共享文件系統存儲庫，以便服務器能夠克隆它，並使用本地工做副本做爲高速緩存。

這個資源的實現經過映射HTTP資源的{label}參數爲git label(提交id,分支名稱或tag)。若是git分支或tag的名稱包含一個斜槓 (「/」)，HTTP URL中的label須要使用特殊字符串」(_)」來替代(爲了不與URL的其餘的參數路徑混淆)。若是使用了命令行客戶端如 curl,請謹慎處理URL中的括號(例如：在shell下請使用引號」來轉義他們)。

Git URI佔位符

Spring Cloud配置服務支持git資源的url使用 {application} 、 {profile}和 {label} 佔位符。這的label指的是git的label。因此，你能夠很容易的爲每個應用配置資源：

spring:
  cloud:
    config:
      server: git: uri: https://github.com/myorg/{application}

或者，每個資源一個{profile}的策略。

模式匹配和多個資源庫

它還支持更復雜的規則使用application，profile來作模式匹配。這個模式的格式，試音逗號分隔的 {application}/{profile}列表做爲通配符。

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

若是{application}/{profile}沒有匹配到任何參數，它將默認使用的spring.cloud.config.server.git.uri定義的uri。在上面的例子中，simple資源匹配simple/*（匹配應用名字爲simple的全部profile）。local資源匹配應用名稱爲local/*的全部的profile。

注意，在上述」simple」的例子中，只使用一行來設置屬性的便捷方式，若是你須要設置其餘屬性(如credentials, pattern, etc.)，你須要使用完整的格式才能表示清楚。

在配置裏面的pattern屬性其實是一個數組，你可使用YAML數組(屬性文件裏面使用[0]、[1])來綁定多個參數。你可能須要使用它，若是你用多個profiles來運行應用。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/spring-cloud-samples/config-repo
          repos:
            development:
              pattern:
                - */development - */staging uri: https://github.com/development/config-repo staging: pattern: - */qa - */production uri: https://github.com/staging/config-repo

若是你的模式匹配參數不是以*結尾，又沒有包含profile，Spring Cloud會推測匹配全部的profiles，好比*/staging是["*/staging", "*/staging,*"]的簡化寫法。一般，在本地開發環境運行development的profile，在遠程環境運行cloud的profile。

每一個資源也能夠選擇在子目錄存儲配置文件，經過關鍵字searchPaths來查詢定義的目錄。例如：

spring:
  cloud:
    config:
      server: git: uri: https://github.com/spring-cloud-samples/config-repo searchPaths: foo,bar*

在這個例子裏面，服務會從foo/目錄和以bar開頭的目錄查詢配置文件。

默認狀況下，當第一次請求的時候，服務clone遠程資源。你也能夠配置在啓動的時候clone。

spring:
  cloud:
    config:
      server:
        git:
          uri: https://git/common/config-repo.git repos: team-a: pattern: team-a-*  cloneOnStart: true uri: http://git/team-a/config-repo.git team-b: pattern: team-b-* cloneOnStart: false uri: http://git/team-b/config-repo.git team-c: pattern: team-c-* uri: http://git/team-a/config-repo.git

在這個例子裏面，服務啓動的時候會clone team-a的配置，它是在接受到請求以前就進行的。其它資源則在資源第一次請求的時候clone。

遠程配置的基礎身份認證經過添加username和password屬性，例如：

spring:
  cloud:
    config:
      server: git: uri: https://github.com/spring-cloud-samples/config-repo username: trolley password: strongpassword

若是你沒有使用https和用戶認證，也能夠便捷的使用SSH，只須要將keys存儲在默認的目錄（~/.ssh），uri指向SSH地址（git@github.com:configuration/cloud-configuration）。服務使用JGit來訪問你須要的任何配置文件。能夠在~/.git/config下配置https代理，也可使用JVM系統屬性-Dhttps.proxyHost和-Dhttps.proxyPort來配置。

若是你清楚你的~/.git目錄，你可使用git config --global來配置。好比：git config --global http.sslVerify false。

查詢佔位符

Spring Cloud配置服務也支持查詢路徑使用 {application}和{profile} (若是須要{label})佔位符。好比：

spring:
  cloud:
    config:
      server: git: uri: https://github.com/spring-cloud-samples/config-repo searchPaths: '{application}'

在與application相同名字的路徑中查找配置庫中的文件。在這裏，通配符一樣有效。

版本控制系統後端文件的使用

後面發現已經有翻譯版本了：附上

Spring Cloud Config
http://www.xyuu.cn/spring-cloud-config-zhcn.html
Spring Cloud Netflix
http://www.xyuu.cn/spring-cloud-netflix-zhcn.html

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。