spring cloud幫助文檔 Hoxton.SR3

第一章 特性:

Spring Cloud側重於爲典型的用例和可擴展性提供良好的開箱即用體驗
  • 分佈式/版本化配置
  • 服務註冊與發現
  • 路由選擇
  • 服務間調用
  • 負載均衡
  • 熔斷機制
  • 分佈式消息

第二章 發佈版本

Project Name Project Version
spring-cloud-build 2.2.1.RELEASE
spring-cloud-commons 2.2.1.RELEASE
spring-cloud-function 3.0.1.RELEASE
spring-cloud-stream Horsham.SR1
spring-cloud-aws 2.2.1.RELEASE
spring-cloud-bus 2.2.0.RELEASE
spring-cloud-task 2.2.2.RELEASE
spring-cloud-config 2.2.1.RELEASE
spring-cloud-netflix 2.2.1.RELEASE
spring-cloud-cloudfoundry 2.2.0.RELEASE
spring-cloud-kubernetes 1.1.1.RELEASE
spring-cloud-openfeign 2.2.1.RELEASE
spring-cloud-consul 2.2.1.RELEASE
spring-cloud-gateway 2.2.1.RELEASE
spring-cloud-security 2.2.0.RELEASE
spring-cloud-sleuth 2.2.1.RELEASE
spring-cloud-zookeeper 2.2.0.RELEASE
spring-cloud-contract 2.2.1.RELEASE
spring-cloud-gcp 1.2.1.RELEASE
spring-cloud-vault 2.2.1.RELEASE
spring-cloud-circuitbreaker 1.0.0.RELEASE
spring-cloud-cli 2.2.1.RELEASE

第三章 雲原生應用(Cloud Native Applications)

Cloud Native 是一種應用程序開發風格,它鼓勵在持續交付和價值驅動開發領域輕鬆採用最佳實踐。一個相關的規程是構建包含12個因素的應用程序,在這些應用程序中,開發實踐與交付和操作目標保持一致——例如,通過使用聲明式編程、管理和監視。Spring Cloud以許多特定的方式促進了這些風格的開發。起點是一組特性,分佈式系統中的所有組件都需要容易地訪問這些特性。
這些特性中的許多都包含在Spring Boot中,Spring Cloud是在Spring Boot上構建的。Spring Cloud還提供了其他一些特性,作爲兩個庫:Spring Cloud Context和Spring Cloud Commons。Spring Cloud Context爲Spring雲應用程序的ApplicationContext(bootstrap context、encryption、refresh scope和environment endpoints)提供實用程序和特殊服務。Spring Cloud Commons是一組抽象和通用類,用於不同的Spring雲實現(如Spring Cloud Netflix和Spring Cloud Consul)。
如果您由於“Illegal key size”而出現異常,並且您使用的是Sun的JDK,那麼您需要安裝Java Cryptography Extension (JCE) Unlimited Strength Policy文件。詳情請參閱以下連結:

3.1 Spring Cloud Context: Application Context Services

Spring Boot對如何使用Spring構建應用程序有自己的看法。例如,它具有用於公共配置文件的常規位置,以及用於公共管理和監視任務的端點。Spring Cloud構建在此基礎之上,並添加了一些系統中的許多組件可能會使用或偶爾需要的功能。

3.1.1 The Bootstrap Application Context

Spring cloud應用程序通過創建“bootstrap”上下文來運行,該上下文是主應用程序的父上下文。此上下文負責從外部源加載配置屬性,並負責解密本地外部配置文件中的屬性。這兩個上下文共享一個環境,該環境是任何Spring應用程序外部屬性的來源。默認情況下,bootstrap屬性(不是bootstrap.properties而是引導階段加載)具有較高的優先級,因此不能被本地配置覆蓋。
Bootstrap 上下文使用與主應用程序上下文不同的約定來定位外部配置。替代application.ym(或.properties),你可以用bootstrap.yml,保持bootstrap和主上下文的外部配置的良好分離。如下:
Example 1. bootstrap.yml

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

如果您的應用程序需要來自服務器的任何特定於應用程序的配置,則最好設置spring.application.name(在bootstrap.yml 或 application.yml中)。如果spring.application.name屬性被用來作爲應用上下文的id,那麼你必須把它配置在bootstrap.yml(.properties )中

如果你想重新制定特定的配置文件,你需要在bootstrap.[properties | yml]文件中配置spring.profiles.active。

您可以通過設置spring.cloud.bootstrap.enabled=false來完全禁用引導進程。 (for example, in system properties).

3.1.2 Application Context Hierarchies(應用上下文等級)

如果你從SpringApplication或SpringApplicationBuilder構建應用程序上下文,則Bootstrap上下文將作爲父上下文添加到該上下文。Spring的一個特性是,子上下文從它們的父上下文繼承屬性源和配置文件,因此,因此,與不使用Spring Cloud配置構建相同的上下文相比,“main”應用程序上下文包含額外的屬性源。額外的參數配置來源是:

  • “bootstrap”:如果再bootstrap上下文中找到任何PropertySourceLocators 屬性,並且其不爲空,則一個可選的CompositePropertySource將以高優先級出現。一個例子是來自Spring Cloud配置服務器的屬性。查看“自定義引導程序屬性源”瞭解如何自定義此屬性源的內容。
  • “applicationConfig: [classpath:bootstrap.yml]”(以及相關啓用的配置文件):如果你有一個bootstrap.yml(或properties),則使用這些屬性來配置Bootstrap上下文,然後當子context設置了此父context的時候就會將這些屬性添加到子上下文中。這些父context中的屬性的優先級低於application.yml(或properties)和任何其他作爲創建Spring Boot應用程序過程的正常部分添加到子 context的屬性源。請參閱自定義引導程序屬性源 的說明,瞭解如何自定義這些屬性來源的內容。
    由於properties sourcer的排序規則,“bootstrap”entries 優先,但請注意,這些條目不包含bootstrap.yml中的任何數據,它們的優先級非常低,但可用於設置默認值。
    你可以通過設置你創建的任何ApplicationContext的父上下文來擴展上下文層次結構——例如,通過使用它自己的接口或使用SpringApplicationBuilder便利方法(parent()、child()和sibling())。引導上下文是你自己創建的最高級祖先的父類。層次結構中的每個上下文都有自己的“引導”(可能是空的)屬性源,以避免無意中將值從父級提升到其後代級。如果有一個配置服務器,那麼層次結構中的每個上下文(原則上)也可以有一個不同的spring.application.name,從而有一個不同的遠程屬性源。常規的Spring應用程序上下文行爲規則應用於屬性解析:來自子上下文的屬性通過名稱和屬性源名稱覆蓋父上下文中的屬性。(如果子元素具有與父元素同名的屬性源,則子元素中不包含父元素的值)。
    注意,SpringApplicationBuilder允許您在整個層次結構中共享一個環境,但這不是默認情況。因此,兄弟上下文(特別是)不需要具有相同的配置文件或屬性源,即使它們可能與父上下文共享相同的值。

3.1.3. Changing the Location of Bootstrap Properties

bootstrap.yml的位置可以通過設置spring.cloud.bootstrap.name(默認是:bootstrap),spring.cloud.bootstrap.location(默認是:空)或者spring.cloud.bootstrap.additional-location(默認是:空)來指定–例如在系統參數中。
這些屬性的行爲與具有相同名稱的spring.config.*變體相同,實際上它們通過在bootstrap ApplicationContext 的Environment中設置這些屬性來設置bootstrap ApplicationContext。如果存在active profile(來自spring.profiles.active或通過您正在構建的context中的Environment API配置),那麼該配置文件中的屬性也將被加載,就像在常規的Spring Boot應用程序中一樣,例如。“development” profile的bootstrap-development.properties。

3.1.4. Overriding the Values of Remote Properties

通過引導上下文添加到應用程序中的屬性源通常是“Remote ”,(例如來自Spring Cloud Config 服務).默認情況下,不能在本地覆蓋它們。如果您想讓您的應用程序使用它們自己的系統屬性或配置文件來覆蓋遠程屬性,遠程屬性源必須通過設置spring.cloud.config.allowOverride=true來進行授權(本地設置無效)。一旦設置了該標誌,兩個更細粒度的設置將控制遠程屬性相對於系統屬性和應用程序的本地配置的位置:

  • spring.cloud.config.overrideNone=true:從任何本地屬性源重寫。
  • spring.cloud.config.overrideSystemProperties=false: 只有系統屬性、命令行參數和環境變量(而不是本地配置文件)應該覆蓋遠程設置。

3.1.5. Customizing the Bootstrap Configuration

通過向/META-INF/spring.factories中添加以org.springframework.cloud.bootstrap.BootstrapConfiguration 爲key的條目可以訓練bootstrap context執行任何您想要的操作。這個key對應的值是逗號分隔的@Configuration類列表,這些類用於創建bootstrap context。這個key對應的值是逗號分隔的@Configuration類列表,這些類用於創建bootstrap context。您想要在 “main” application context中可以自動裝配的任何bean都可以在此處創建,並且該上下文中還有一個ApplicationContextInitializer類型的@Beans特殊規範。如果要控制啓動順序(默認順序爲“last”),可以使用@Order標記類。
添加自定義BootstrapConfiguration時要小心,您添加的這些類不能錯誤地@ComponentScanned到您的 “main” application context中,因爲 “main” application context中可能不需要它們。對於尚未由@ComponentScan或@SpringBootApplication註釋的配置類所包含的boot 配置類,使用單獨的package name。

bootstrap process結束於將initializers注入主SpringApplication實例(即普通的Spring Boot啓動sequence,無論它是作爲獨立應用程序運行還是部署在 application server中)。首先,通過spring.factories中的類創建bootstrap context,然後在啓動之前,將所有類型爲ApplicationContextInitializer的@Beans添加到主SpringApplication中。

3.1.6. Customizing the Bootstrap Property Sources

bootstrap process添加的外部配置的默認屬性源是Config Server,但可以通過將類型PropertySourceLocator的Bean添加到bootstrap context(通過spring.factories)來添加其他屬性源。例如,您可以使用指定的數據源從不同的server或數據庫插入其他屬性。

作爲例子,請考慮以下簡單的 custom locator:

@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的Environment,這個Environment也就是我們爲其提供附加屬性源的Environment。這個Environment將擁有普通的Spring Boot-provided property sources,因此您可以使用這些property source來定位特定於此Environment的property source(例如,通過在spring.application.name上鍵入它,如在缺省Config Server property source locator)。

如果你創建了一個jar包含這個類,然後添加一個META-INF / spring.factories包含如下內容:

org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator
那麼任何包含該jar的application中,“customProperty” PropertySource都可用。

3.1.7. Logging Configuration

:如果您使用Spring Boot來配置日誌設置,則應該將此配置放在bootstrap.[yml | properties]如果你希望它適用於所有事件。

3.1.8. Environment Changes

應用程序將監聽EnvironmentChangeEvent並以一些標準方式對更改做出反應(額外的ApplicationListener可以通過正常方式添加爲@Beans)。當觀察到EnvironmentChangeEvent時,這個event將有一個已更改的key-value列表,並且應用程序將使用這些key-value來:

  • 在上下問中重新綁定任何的@ConfigurationProperties實體
  • 爲logger .level.*中的任何屬性設置logger級別

請注意,Config Client不會默認輪詢 Environment中的更改,通常我們不會建議用於檢測更改的方法(儘管您可以使用@Scheduled註釋進行設置)。如果您有多個客戶端應用程序,則最好將EnvironmentChangeEvent廣播到所有實例,而不是讓他們輪詢更改(例如,使用Spring Cloud Bus)。
EnvironmentChangeEvent涵蓋了一大類刷新使用場景,只要您可以對Environment進行實際更改併發布該事件(這些API是公開的並且是Spring核心的一部分)。您可以通過訪問/ configprops端點(普通的Spring Boot Actuator功能)來驗證更改是否綁定到@ConfigurationProperties bean。例如,DataSource可以在運行時更改其maxPoolSize(由Spring Boot創建的默認DataSource是一個@ConfigurationProperties bean)並動態增加容量。重新綁定@ConfigurationProperties不包含另一大類場景,這些場景中需要您需要更多地控制刷新,並且這裏需要對整個ApplicationContext進行原子級更改。爲了解決這些問題,我們使用了@RefreshScope。

3.1.9. Refresh Scope

標記爲@RefreshScope的Spring @Bean將在配置更改時得到特殊處理。這解決了有狀態bean被初始化時僅注入它們自己的配置的問題。例如,如果通過Environment更改數據庫URL時,如果DataSource已打開了連接,我們可能希望這些連接的持有者能夠完成他們正在執行的操作。然後當有人從連接池借用一個連接時,他會得到一個新的URL。
有時候,在一些只能初始化一次的bean上應用@RefreshScope註釋可能是強制性的。如果一個bean是“不可變的”,那麼您必須使用@RefreshScope來註釋這個bean,或者在屬性鍵下指定classname: spring.cloud.refresh.extra-refreshable。

Refresh scope beans是在它們被使用時(即,當調用方法時)進行初始化的惰性代理,並且scop充當初始化值的緩存。要強制一個bean在下一次方法調用時重新初始化,只需要使其緩存項無效。

RefreshScope是上下文中的一個bean,它有一個公共refreshAll()方法,通過清除目標緩存來刷新範圍內的所有bean。刷新端點公開此功能(通過HTTP或JMX)。要按名稱刷新單個bean,還有一個refresh(String)方法。
要公開/refresh端點,您需要向您的應用程序添加以下配置:

management:
  endpoints:
    web:
      exposure:
        include: refresh

@RefreshScope在技術上適用於@Configuration類,但它可能會導致令人驚訝的行爲:例如這並不意味着該類中定義的所有@Beans本身都是@RefreshScope。具體來說,anything依賴這些RefreshScope beans不能相信這些RefreshScope beans會在refresh初始化的時候更新,除非它本身也位於@RefreshScope中(上面所說的anything將在刷新時重建並重新注入它的依賴項,這些依賴項會從刷新的@Configuration重新初始化)

3.1.10. Encryption and Decryption

Spring Cloud有一個Environment pre-processor用於本地解密屬性值。它遵循與配置服務器相同的規則,並且使用encrypt.* 作爲key。因此,您可以使用{cipher}*格式的加密值,只要有一個有效的密鑰,那麼它們將在主應用程序上下文獲取Environment之前被解密。要在應用程序中使用加密功能,您需要在您的類路徑中包含Spring Security RSA(Maven協調“org.springframework.security:spring-security-rsa”),並且您還需要JVM中的全功能JCE擴展。

如果由於“Illegal key size”而導致異常,並且您正在使用Sun的JDK,則需要安裝Java加密擴展(JCE)
文件。詳情請參閱以下連結:

3.1.11. Endpoints

對於Spring boot Actuator 應用程序,可以使用一些附加的管理端點。您可以使用:

  • POST to /actuator/env to update the Environment and rebind @ConfigurationProperties and log levels.
  • /actuator/refresh to re-load the boot strap context and refresh the @RefreshScope beans.
  • /actuator/restart to close the ApplicationContext and restart it (disabled by default).
  • /actuator/pause and /actuator/resume for calling the Lifecycle methods (stop() and start() on the ApplicationContext).

3.2. Spring Cloud Commons: Common Abstractions

服務發現、負載平衡和斷路器等模式提供了一個公共抽象層,所有Spring cloud客戶端都可以使用這個抽象層,與實現無關(例如,使用Eureka或領事進行發現)。

3.2.1. The @EnableDiscoveryClient Annotation

Spring Cloud Commons 提供了 @EnableDiscoveryClient註解,這通過META-INF/spring.factories查找DiscoveryClient接口的實現。Discovery Client的實現類將在spring.factories中添加一個配置類,這個配置類的key是org.springframework.cloud.client.discovery.EnableDiscoveryClient。DiscoveryClient 實現的例子有Spring Cloud Netflix Eureka, Spring Cloud Consul Discovery, 和Spring Cloud Zookeeper Discovery.
默認情況下,DiscoveryClient的實現將自動註冊本地Spring Boot服務器爲remote discovery server。這可以通過在@EnableDiscoveryClient中設置autoRegister = false來禁用。

不再需要使用@EnableDiscoveryClient。只需在類路徑上有一個DiscoveryClient實現就足以讓Spring Boot應用程序註冊service discovery server。

Health Indicator

DiscoveryClient實現可以通過實現DiscoveryHealthIndicator接口加入Commons創建的Spring Boot HealthIndicator。要禁用composite HealthIndicator,請設置spring.cloud.discovery.client.composite-indicator.enabled = false。一個基於DiscoveryClient的通用HealthIndicator是自動配置的(DiscoveryClientHealthIndicator)。要禁用它,請設置`spring.cloud.discovery.client.health-indicator.enabled = false。要禁用DiscoveryClientHealthIndicator的描述字段,請設置spring.cloud.discovery.client.health-indicator.include-description = false,otherwise it can bubble up as the description of the rolled up HealthIndicator.

哎呀,先穩穩,存個檔
斷點傳送門

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章