佔位符配置URL

{application}，{profile}，{label}這些佔位符除了用於標識配置檔案的規則外，還可以用於Config Server中對Git倉庫地址的URI配置。

{application}代表了應用名，Config Server會根據客戶端的spring.application.name資訊來填充{application}佔位符以定位配置資源的儲存位置，從而實現根據微服務應用的屬性動態獲取不同位置的配置。如果Git的分支和標籤名包含“/”，那麼{label}引數在HTTP的URL中應該使用“（_）”來替代，以避免改變了URI含義，指向到其他的URI資源。

不過並不推薦使用{application}/{profile}來進行配置。

本地倉庫

在使用Git或SVN倉庫後，檔案都會在Config Server的本地檔案系統中儲存一份。這些檔案預設會被儲存在config-repo為字首的臨時目錄中，比如：/tmp/config-repo-<隨機數>的目錄。因為其隨機性可能會帶來不可預知的後果，所以最好就是指定一個固定的位置來儲存這些資訊。只需要使用：spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir來配置一個目錄即可。

本地檔案系統

Spring Cloud Config也提供了一種不使用Git倉庫或SVN倉庫的儲存方式，而是使用本地檔案系統的儲存方式來儲存配置資訊。只需要設定屬性spring.profiles.active=native，Config Server會預設從應用的src/main/resource目錄下搜尋配置檔案。如果需要指定搜尋配置檔案的路徑，可以通過spring.cloud.server.native.serchLocations屬性來指定具體的配置檔案位置。

健康監測

根據預設配置規則，可以在Git倉庫中建立一個名為app-config的配置庫，讓健康檢測器能夠訪問它。也可以配置一個實際存在的倉庫來進行連通監測，如：

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

健康監測的repositories是個Map物件，所以實際使用可惡意配置多個。每個配置中包含了與定位倉庫地址類似的三個元素。

name：應用名

label：分支名

profiles：環境名

健康檢測器可以通過spring.cloud.config.server.health.enabled=false引數來關閉。

屬性覆蓋

通過spring.cloud.config.server.overrides屬性來設定鍵值對的引數，這些引數會以Map的方式載入到客戶端的配置中。如：

spring.cloud.config.server.overrides.name=zzzzzz
spring.cloud.config.server.overrides.from=zhejiang

通過該屬性配置的引數不會被Spring Cloud的客戶端修改，並且Spring Cloud客戶端從Config Server中獲取配置資訊時，都會取得這些配置資訊。利用該特性可以方便地為Spring Cloud應用配置一些共同屬性或是預設屬性。

安全保護

首先在pom.xml檔案中加入spring-boot-starter-security依賴。

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

也可以在配置檔案中指定使用者名稱和密碼，如：

spring.security.user.name=zzf
spring.security.user.password=123456

spring.cloud.config.username=zzf
spring.cloud.config.password=123456

高可用配置

Spring Cloud Config實現服務端高可用有兩種方式。

傳統模式

不需要給這些服務端做額外配置，只需要遵守一個配置規則，將所有的Config Server都指向同一個Git倉庫，這樣所有的配置內容就通過統一的共享檔案系統來維護。而客戶端在指定Config Server位置時，只需要配置Config Server上層的負載均衡裝置地址即可。

服務模式

除了傳統模式，也可以將Config Server作為普通的微服務納入Eureka的服務治理體系中。這樣就能通過配置中心的服務名來獲取配置資訊，這種方式比傳統的實現模式來說更容易維護，因為服務端的負載均衡配置和客戶端的配置中心指定都通過服務治理解決了，既實現了高可用，也實現了自維護。

客戶端詳解

URI指定配置中心

Spring Cloud Config的客戶端在啟動時，預設會從工程的classpath中載入配置資訊並啟動應用。只有當我們配置spring.cloud.donfig.uri的時候客戶端應用才會嘗試連線Spring Cloud Config的服務端來獲取遠端配置資訊並初始化Spring環境配置。同時必須把引數配置在bootstrap.properties中，環境變數或是其他優先順序高於應用Jar包內的配置資訊中，才能正確載入到遠端配置。否則Spring Cloud Config的客戶端會預設嘗試連線http://localhost:8888。

如：

spring.application.name=didispace
spring.cloud.config.profile=dev 
spring.cloud.config.uri=http://localhost:7001/

服務化配置中心

1.首先在服務端與客戶端的pom.xml檔案中新增依賴jar：

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

2.在application.properties中配置eureka.client.serviceUrl.defaultZone指定服務註冊中心的位置。

spring.application.name=config-server
server.port=7001

spring.cloud.config.server.git.uri=###############
spring.cloud.config.server.git.search-paths=config-repo
spring.cloud.config.server.git.username=###############
spring.cloud.config.server.git.password=###############

eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

3.在應用主類中新增@EnableDiscoveryClient註解，用來將config-server註冊到上面配置的服務註冊中心。

@EnableDiscoveryClient
@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {

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

客戶端配置

1.在bootstrap.properties中按如下配置：

server.port=7002

spring.application.name=didispace

eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.service-id=config-server
spring.cloud.config.profile=dev

首先通過eureka.client.serviceUrl.defaultZone引數指定服務註冊中心，用於服務的註冊與發現，將spring.cloud.config.discovery.enable引數設為true,開啟通過服務來訪問Config Server的功能。最後利用spring.cloud.config.discovery.serviceId引數來指定Config Server註冊的服務名。這裡的spring.application.name和spring.cloud.config.profile如之前通過URI的方式訪問的時候一樣，用來定位Git中的資源。

2.在應用主類增加@EnableDiscoveryClient註解用來發現config-server服務。

@EnableDiscoveryClient
@SpringBootApplication
public class ConfigClientApplication {

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

3.控制器使用之前的來訪問：

@RefreshScope
@RestController
public class TestController {

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

    @Autowired
    private Environment environment;

    @RequestMapping("/from2")
    public String from2(){
        return environment.getProperty("from","undefined");
    }

    @RequestMapping("/from")
    public String from(){
        return this.from;
    }

}

然後啟動這些服務。

失敗快速響應與重試

如果需要實現客戶端優先判斷Config Server獲取是否正常，並快速獲得響應失敗內容，只需要在bootstrap.properties中配置引數spring.cloud.config.failFast=true即可。

如果想要開啟重試機制則需要引入以下jar包：

         <dependency>
            <groupId>org.springframework.retry</groupId>
            <artifactId>spring-retry</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>

如果不做其他配置，它會嘗試6次然後停止返回錯誤資訊。

可以通過下面的引數設定最大重試機制和間隔：

spring.cloud.config.retry.multiplier:初始重試家那個時間，預設為1000ms。

spring.cloud.config.retry.initial-intervel:下一間隔的乘數，預設為為1.1所以當最初間隔是1000ms時，下一次就是1100ms。

spring.cloud.config.retry.max-interval:最大間隔時間，預設為2000ms。

spring.cloud.config.retry.max-attempts:最大重試次數，預設為6次。

動態重新整理配置

1.首先在config-client的pom.xml中新增spring-boot-starter-actuator監控模組。

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

然後在配置檔案中加入：

management.endpoints.web.exposure.include=bus-refresh

然後訪問http://localhost:7002/actuator/bus-refresh

參考《Spring Cloud 微服務實戰》