版本:Dalston.SR2。官方文檔地址:http://cloud.spring.io/spring-cloud-static/Dalston.SR2/#_serving_alternative_formats ...
官方文檔地址為:http://cloud.spring.io/spring-cloud-static/Dalston.SR2/#_serving_alternative_formats
文中例子我做了一些測試在:http://git.oschina.net/dreamingodd/spring-cloud-preparation
官方項目:https://github.com/spring-cloud-samples/config-repo
6.提供替代格式
由於Spring應用直接映射到環境抽象,來自環境鏈接的預設JSON格式完全適用於Spring應用的消費。如果願意,開發人員可以通過給資源路徑加上尾碼的方式來使用YAML或Java屬性來消費同樣的數據。這對於不關心JSON鏈接返回結構的應用消費或其提供的額外元數據可能很有幫助,例如一個不使用Spring的應用就可以直接用這種方式。
YAML和屬性表示有一個額外的標識(作為布爾查詢參數resolvePlaceholders提供)用於標記標準Spring ${}格式的源文件中的占位符,在渲染之前儘可能在輸出中解析。對於不瞭解Spring占位符約定的消費者來說,這是一個有用的功能。
註意 使用YAML或屬性格式有一些限制,主要是與元數據的丟失有關。JSON格式是一個屬性源的有序列表結構,例如,名稱與源相關聯。即使屬性值有多個源,而且源屬性文件的名稱已丟失,YAML和屬性表會合併成一個映射。YAML表示不必是後端倉庫中YAML源的忠實表示:它由明文屬性源的列表構成,而且必須對密鑰的形式作出假設。
7.Serving Plain Text 提供明文
應用程式根據環境可能需要通用的純文本配置文件,而不是環境抽象(或YAML中的其他替代表示或屬性格式)。配置中心提供這些附屬鏈接,/{name}/{profile}/{label}/{path},其中的"name","profile"等的含義與常規環境鏈接相同,只有"path"是一個文件名(如log.xml)。此鏈接的源文件通過和環境鏈接同樣的方式定位:與屬性或YAML文件具有相同的搜索路徑,但它只匹配符合的第一個,而不是聚合所有匹配的資源。
當定位了一個源之後,有效環境中的普通格式(${...})的占位符解析為應用名稱,profile和提供的label。資源鏈接和環境鏈接以這種方式緊密結合。例如,當存在這樣的Git(或SVN)倉庫:
application.yml nginx.conf
nginx.conf像這樣:
server {
listen 80;
server_name ${nginx.server.name};
}
而application.yml像這樣:
nginx:
server:
name: example.com
---
spring:
profiles: development
nginx:
server:
name: develop.com
然後/foo/default/master/nginx.conf resource像這樣:
server {
listen 80;
server_name example.com;
}
而/foo/development/master/nginx.conf像這樣:
server {
listen 80;
server_name develop.com;
}
註意 就像環境配置的源文件一樣,"profile"是用來解析文件名的,因為如果開發人員需要一個靠profile指定的文件,那麼/sth/development/sth/logback.xml將被解析為logback-development.xml(而不是logback.xml)。
8. 嵌入配置中心
配置中心最好獨立運行。但若需要嵌入其他應用,也只需要@EnableConfigServer註解。這種情況下,有一個可選屬性-spring.cloud.config.server.bootstrap很有用,它是一個伺服器是否從自己的遠程倉庫配置自己的標誌。由於它拖慢啟動,預設是關閉的,但當嵌入其他應用時,與其他應用一樣初始化就說得通了。
註意 很明顯,記住如果使用bootstrap標誌,配置中心將需要在bootstrap.yml配置其名稱和倉庫URI。
可以設置spring.cloud.config.server.prefix-如"/config",來修改伺服器的鏈接地址,以為首碼下的資源提供服務。首碼應以"/"開始並不以"/"結束。適用於配置中心的@RequestMappings(即,在Spring Boot前面的server.servletPath和server.contextPath下)。
如果需要直接從後端倉庫(不是配置中心)給應用讀取配置,這基本上就是一個沒有對外鏈接的內嵌配置中心。不使用@EnableConfigServer註解就可以徹底關閉對外鏈接(設置spring.cloud.config.server.bootstrap=true)。
9.推送通知和Spring Cloud Bus
很多源代碼倉庫提供方(例如像Github,Gitlab或Bitbucket)都會通過webhook通知用戶倉庫的修改。開發人員可以通過提供方的用戶介面來配置webhook,URL或一些感興趣的事件。例如Github會使用包含一串commits的JSON格式POST到webhook,header中的"X-Github-Event"表示"push"。如果在spring-cloud-config-monitor庫中加入依賴併在配置中心激活Spring Cloud Bus,那麼"/monitor"鏈接就啟用了。
當webhook被激活時,配置中心會發送一個RefreshRemoteApplicationEvent事件,針對於它認為已經發生改變的應用。變更檢測可以進行策略化,但預設它只查找與應用程式名稱匹配的文件的更改(例如,"foo.properties"針對於"foo"應用,"application.properties"針對於所以應用)。如覆蓋該行為的策略為PropertyPathNotificationExtractor,它接受請求頭和主題作為參數並返回一個變更的文件路徑列表。
預設配置與Github,Gitlab以及Bitbucket都是開箱即用。除Github,Gitlab或Bitbucket的JSON通知之外,開發人員可以觸發一個變更通知,通過使用form-encoded參數體path={name}POSTing到"/monitor"。這樣做會向匹配"{name}"的應用發送廣播(可以包含通配符)。
註意 需要配置中心和客戶端應用激活spring-cloud-bus才能傳輸RefreshRemoteApplicationEvent。
註意 本地Git倉庫預設檢測文件系統變更(這種情況下不使用webhook,但一旦修改了配置文件,會廣播刷新事件)。
10.Spring Cloud Config客戶端
Spring Boot應用可以立即利用Spring Config服務端(或應用程式開發人員提供的其他外部屬性源),並且還將獲取與環境更改事件相關的一些其他有用功能。
配置第一個Bootstrap
這是任何在classpath中存在Spring Cloud Config客戶端的應用的預設行為。當配置客戶端啟動時,它將綁定配置中心(通過bootstrap配置屬性spring.cloud.config.uri)並使用遠程屬性源初始化Spring環境。
最終結果是所有希望消費配置中心的客戶端應用都需要在bootstrap.yml(或環境變數)中存在一個伺服器地址spring.cloud.config.uri(預設為"http://localhost:8888")。
發現第一個Bootstrap
如果使用DiscoveryClient實現,比如Spring Cloud Netflix和Eureka Service Discovery或者Spring Cloud Consul(Spring Cloud Zookeeper暫時不支持),那麼可以按需將配置中心註冊為Discovery Servcie,但是在預設的"Config First"模式中,客戶端將不能利用這種註冊。
如果希望使用DiscoveryClient來定位配置中心,開發人員可以通過設置spring.cloud.config.discovery.enabled=true(預設false)來實現。最終結果是客戶端應用需要相應的服務發現配置的bootstrap.yml(或環境變數)。例如,使用Spring Cloud Netflix,需要定義Eureka伺服器地址,例如在eureka.client.serviceUrl.defaultZone。這樣做的代價是啟動時一個額外的網路往返開銷去定位服務註冊,好處是只要發現服務是一個固定點,配置中心可以改變坐標。預設的服務ID為"configserver",開發人員可以通過spring.cloud.config.discovery.serviceId修改(在伺服器上通常用spring.application.name修改)。
服務發現客戶端實現全都支持某種元數據映射(例如Eureka的eureka.instance.metadataMap)。配置中心可能需要在註冊元數據中配置一些額外的屬性以便客戶端能正確連接。如果配置中心使用HTTP Basic安全配置伺服器,則可以將憑據配置為"username"和"password"。而且配置中心修改"confgPath"來設置context path。例子,對於一個身為Eureka客戶端的配置中心:
bootstrap.yml
eureka:
instance:
...
metadataMap:
user: osufhalskjrtl
password: lviuhlszvaorhvlo5847
configPath: /config
配置客戶端快速失敗
某些情況下,如果客戶端無法連接伺服器,可能需要讓啟動失敗。若需要這種行為,設置bootstrap配置屬性spring.cloud.config.failFast=true,客戶端就會停止並拋出異常。
配置客戶端重試
如果配置中心在應用啟動時偶爾不可用,那麼可以讓應用在失敗後進行重試。首先需要設置spring.cloud.config.failFast=true,然後需要將spring-retry和spring-boot-starter-aop加入classpath。預設會重試6次,初始間隔為1000ms,後續間隔指數為1.1。這些屬性在spring.cloud.config.retry.*中設置。
提示 完全控制重試功能,要添加一個類型為RetryOperationsInterceptor,id為"configServerRetryInterceptor"的Bean。Spring Retry提供了一個RetryInterceptorBuilder,可以輕鬆創建這個Bean。
Locating Remote Configuration Resources 定位遠程配置資源
配置中心提供來自/{name}/{profile}/{label}的屬性源,在客戶端APP中預設綁定的是
- "name" = ${spring.application.name}
- "profile" = ${spring.profiles.active} (actually Environment.getActiveProfiles())
- "label" = "master"
以上都可以設置spring.cloud.config.*(星號就是"name","profile"和"label")來覆蓋。"label"可以用來回滾到歷史版本;使用預設的配置中心實現它可以是一個git label,branch名稱或commit id。Label亦可用逗號分隔的列表形式提供,這種情況下列表值會一個一個試過來,直到成功為止。當在feature分支上工作時會比較有用,比方說,當開發人員需要將配置label和branch對齊時,同時又可選(例:spring.cloud.config.label=myfeature,develop)。
安全性
如果開發人員在服務端使用HTTP Basic安全,那麼客戶端只需要知道密碼(用戶名不是預設的話也需要)。開發人員可以通過config server URI或分離用戶名和密碼屬性來實現,例:
bootstrap.yml
spring:
cloud:
config:
uri: https://user:[email protected]
or
bootstrap.yml
spring:
cloud:
config:
uri: https://myconfig.mycompany.com
username: user
password: secret
spring.cloud.config.password和spring.cloud.config.username這兩個屬性值會覆蓋任何URI提供的屬性。
如果在Cloud Foundry開發APP的話,最好的方式是通過服務憑據來提供密碼,比如在URI中,這樣它甚至不需要在配置文件中存在。下麵是一個在Cloud Foundry上用戶提供的服務,本地運行,名為"configserver":
bootstrap.yml
spring:
cloud:
config:
uri: ${vcap.services.configserver.credentials.uri:http://user:password@localhost:8888}
如果開發人員使用其他安全方式,可能就需要提供一個到ConfigServicePropertySourceLocator的RestTemplate(例:在bootstrap上下文中獲取並註入一個)。
Health Indicator 健康指標
客戶端支持Spring Boot的健康指標。不過也可以通過health.config.enabled=false來禁用。因為性能原因響應會被存到緩存。預設緩存生存5分鐘。health.config.time-to-live屬性可以修改。
提供一個自定義的RestTemplate
某些情況下,可以會需要自定義請求從客戶端發送到配置中心。通常這涉及傳遞特殊的授權頭來驗證發送到服務端的請求。提供自定義的RestTemplate請按照以下步驟。
1.創建一個PropertySourceLocator實現的Bean。
CustomConfigServiceBootstrapConfiguration.java
@Configuration public class CustomConfigServiceBootstrapConfiguration { @Bean public ConfigServicePropertySourceLocator configServicePropertySourceLocator() { ConfigClientProperties clientProperties = configClientProperties(); ConfigServicePropertySourceLocator configServicePropertySourceLocator = new ConfigServicePropertySourceLocator(clientProperties); configServicePropertySourceLocator.setRestTemplate(customRestTemplate(clientProperties)); return configServicePropertySourceLocator; } }
2.在resources/META-INF中創建一個spring.factories指定自定義配置類。
spring.factories
org.springframework.cloud.bootstrap.BootstrapConfiguration = com.my.config.client.CustomConfigServiceBootstrapConfiguration
Vault
當使用Vault作為配置中心的後端時,客戶端需要提供令牌來向Vault獲取數據。這個令牌是通過設置bootstrap.yml中的spring.cloud.config.token來提供的。
bootstrap.yml
spring:
cloud:
config:
token: YourVaultToken
Vault
在Vault中嵌入密鑰
Vault提供了將密鑰嵌入存儲值的功能。例如
echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -
此命令會將一個JSON對象寫入Vault中。Spring訪問這些值需要使用傳統的點(.)註解。例如
@Value("${appA.secret}")
String name = "World";
上述代碼將name變數設置為appAsecret。
dreamingodd原創文章,如轉載請註明出處。