摘要：它們的優先級低于或以及作為創建應用程序過程的正常部分添加到子級的任何其他屬性源。為引導配置類使用多帶帶的包名稱，并確保或注解的配置類尚未涵蓋該名稱。在這種情況下，它會在刷新時重建，并重新注入其依賴項，此時，它們將從刷新的重新初始化。

Spring Boot有一個關于如何使用Spring構建應用程序的主見，例如，它具有通用配置文件的常規位置，并具有用于通用管理和監控任務的端點，Spring Cloud在此基礎上構建并添加了一些功能，這些功能可能是系統中的所有組件都會使用或偶爾需要的。

Spring Cloud應用程序通過創建“bootstrap”上下文來運轉，該上下文是主應用程序的父上下文，它負責從外部源加載配置屬性以及用于解密本地外部配置文件中的屬性，這兩個上下文共享一個Environment，它是任何Spring應用程序的外部屬性來源。默認情況下，bootstrap屬性（不是bootstrap.properties，而是在引導階段加載的屬性）以高優先級添加，因此本地配置無法覆蓋它們。

bootstrap上下文使用與主應用程序上下文不同的約定來定位外部配置，你可以使用bootstrap.yml而不是application.yml（或.properties），保持bootstrap和主上下文的外部配置很好地分開，以下清單顯示了一個示例：

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

如果你的應用程序需要來自服務器的任何特定于應用程序的配置，則最好設置spring.application.name（在bootstrap.yml或application.yml中）。

你可以通過設置spring.cloud.bootstrap.enabled=false來完全禁用引導過程（例如，在系統屬性中）。

如果你從SpringApplication或SpringApplicationBuilder構建應用程序上下文，那么Bootstrap上下文將添加為該上下文的父級。Spring的一個特性是子上下文從其父級繼承屬性源和配置文件，因此與不使用Spring Cloud Config構建相同的上下文相比，“主”應用程序上下文包含額外的屬性源，額外的屬性源是：

“bootstrap”：如果在Bootstrap上下文中找到任何PropertySourceLocators，并且它們具有非空屬性，則會出現具有高優先級的可選CompositePropertySource，一個例子是Spring Cloud Config Server的屬性。

“applicationConfig: [classpath:bootstrap.yml]”（以及相關文件，如果Spring配置文件處于活動狀態）：如果你有bootstrap.yml（或.properties），則這些屬性用于配置Bootstrap上下文，然后，當設置了其父級時，它們將添加到子上下文中。它們的優先級低于application.yml（或.properties）以及作為創建Spring Boot應用程序過程的正常部分添加到子級的任何其他屬性源。

由于屬性源的排序規則，“bootstrap”條目優先，但請注意，這些不包含來自bootstrap.yml的任何數據，它具有非常低的優先級，但可用于設置默認值。

你可以通過設置你創建的任何ApplicationContext的父上下文來擴展上下文層次結構 — 例如，通過使用它自己的接口或SpringApplicationBuilder便捷方法（parent()、child()和sibling()），bootstrap上下文是你自己創建的最高級祖先的父級。層次結構中的每個上下文都有自己的“bootstrap”（可能是空的）屬性源，以避免無意中把父級的值傳給后代。如果存在Config Server，則層次結構中的每個上下文（原則上）也可以具有不同的spring.application.name，因此具有不同的遠程屬性源。普通的Spring應用程序上下文行為規則適用于屬性解析：來自子上下文的屬性按名稱和屬性源名稱覆蓋父級中的屬性（如果子項具有與父項具有相同名稱的屬性源，則父項中的值不包括在子項中）。

請注意，SpringApplicationBuilder允許你在整個層次結構中共享Environment，但這不是默認設置，因此，兄弟上下文尤其不需要具有相同的配置文件或屬性源，即使他們可能與父上下文共享共同的值。

可以通過設置spring.cloud.bootstrap.name（默認值：bootstrap）或spring.cloud.bootstrap.location（默認值為空）來指定bootstrap.yml（或.properties）位置 — 例如，在系統屬性中。這些屬性的行為類似于具有相同名稱的spring.config.*變體，實際上，它們用于通過在其Environment中設置這些屬性來設置bootstrap ApplicationContext。如果存在活動配置文件（來自spring.profiles.active或通過你正在構建的上下文中的Environment API），則該配置文件中的屬性也會加載，與常規Spring Boot應用程序相同 — 例如，來自bootstrap-development.properties的development配置文件。

bootstrap上下文添加到應用程序的屬性源通常是“遠程”的（例如，來自Spring Cloud Config Server），默認情況下，它們無法被本地覆蓋。如果要讓應用程序使用自己的系統屬性或配置文件覆蓋遠程屬性，遠程屬性源必須通過設置spring.cloud.config.allowOverride=true來授予它權限（它不能在本地設置它），設置該標志后，兩個更細粒度的設置將控制遠程屬性相對于系統屬性和應用程序本地配置的位置：

spring.cloud.config.overrideNone=true：從任何本地屬性源覆蓋。

spring.cloud.config.overrideSystemProperties=false：只有系統屬性、命令行參數和環境變量（但不是本地配置文件）才應覆蓋遠程設置。

通過向/META-INF/spring.factories下添加鍵名為org.springframework.cloud.bootstrap.BootstrapConfiguration的條目，可以將bootstrap上下文設置為執行任何操作。它包含一個以逗號分隔的用于創建上下文的Spring @Configuration類列表，你可以在此處創建你希望可用于主應用程序上下文以進行自動裝配的任何Bean。ApplicationContextInitializer類型的@Beans有一個特殊的合約，如果要控制啟動順序，可以使用@Order注解標記類（默認順序為last）。

添加自定義BootstrapConfiguration時，請注意你添加的類不是@ComponentScanned錯誤地進入你的“主”應用程序上下文，可能不需要它們。為引導配置類使用多帶帶的包名稱，并確保@ComponentScan或@SpringBootApplication注解的配置類尚未涵蓋該名稱。

引導過程通過將初始化器注入主SpringApplication實例（這是正常的Spring Boot啟動順序，無論是作為獨立應用程序運行還是部署在應用程序服務器中）而結束，首先，從spring.factories中的類創建bootstrap上下文，然后，所有類型為ApplicationContextInitializer的@Beans在它啟動之前都會添加到主SpringApplication中。

引導過程添加的外部配置的默認屬性源是Spring Cloud Config Server，但你可以通過將類型為PropertySourceLocator的bean添加到bootstrap上下文中來添加其他來源（通過spring.factories），例如，你可以從不同的服務器或數據庫插入其他屬性。

例如，請考慮以下自定義locator：

@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {

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

}

傳入的Environment是要創建的ApplicationContext的環境 — 換句話說，我們為其提供其他屬性源的環境。它已經有了正常的Spring Boot提供的屬性源，因此，你可以使用它們來查找特定于此Environment的屬性源（例如，通過將其鍵入spring.application.name，就像在默認的Spring Cloud Config Server屬性源定位器中所做的那樣）。

如果在其中創建包含此類的jar，然后添加包含以下內容的META-INF/spring.factories，則customProperty PropertySource將出現在其類路徑中包含該jar的任何應用程序中：

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

如果要使用Spring Boot配置日志設置，則應將此配置放在‘bootstrap.[yml | properties]’，如果你希望它適用于所有事件。

要使Spring Cloud正確初始化日志記錄配置，你不能使用自定義前綴，例如，初始化日志記錄系統時，使用custom.loggin.logpath不被Spring Cloud識別。

應用程序偵聽EnvironmentChangeEvent并以幾種標準方式對更改做出反應（用戶可以正常方式將其他ApplicationListener添加為@Beans），當觀察到EnvironmentChangeEvent時，它有一個已更改的鍵值列表，應用程序使用它們：

在上下文中重新綁定任何@ConfigurationProperties bean

為logging.level.*中的任何屬性設置記錄器級別

請注意，默認情況下，Config Client不會輪詢Environment中的更改，通常，我們不建議使用這種方法來檢測更改（盡管你可以使用@Scheduled注解進行設置）。如果你有一個擴展的客戶端應用程序，最好將EnvironmentChangeEvent廣播到所有實例，而不是讓它們輪詢更改（例如，通過使用Spring Cloud Bus）。

EnvironmentChangeEvent涵蓋了一大類刷新用例，只要你可以實際更改環境并發布事件即可，請注意，這些API是公共的，并且是核心Spring的一部分。你可以通過訪問/configprops端點（一個正常的Spring Boot Actuator功能）來驗證更改是否綁定到@ConfigurationProperties bean。例如，DataSource可以在運行時更改其maxPoolSize（Spring Boot創建的默認DataSource是@ConfigurationProperties bean）并動態增加容量。重新綁定@ConfigurationProperties不包括另一大類用例，這類用例你需要更多地控制刷新，并且需要對整個ApplicationContext進行原子性更改，為了解決這些問題，我們有@RefreshScope。

當配置發生變化時，標記為@RefreshScope的Spring @Bean會得到特殊處理，該特性解決了只有在初始化狀態bean時才注入配置的有狀態bean的問題。例如，如果DataSource在通過Environment更改數據庫URL時具有打開的連接，你可能希望這些連接的持有者能夠完成他們正在做的事情，然后，下次從池中借用某個連接時，它會獲得一個帶有新URL的連接。

有時，甚至可能必須在某些只能初始化一次的bean上應用@RefreshScope注解，如果bean是“不可變的”，則必須使用@RefreshScope注解bean，或者在屬性鍵spring.cloud.refresh.extra-refreshable下指定classname。

如果你自己創建一個DataSource bean并且該實現是一個HikariDataSource，則返回最具體的類型，在本例中為HikariDataSource，否則，你需要設置spring.cloud.refresh.extra-refreshable=javax.sql.DataSource。

刷新作用域bean是在使用它們時初始化的惰性代理（即，在調用方法時），并且作用域充當初始化值的緩存，要強制bean在下一個方法調用上重新初始化，必須使其緩存條目無效。

RefreshScope是上下文中的一個bean，它有一個公共refreshAll()方法，通過清除目標緩存來刷新作用域中的所有bean，/refresh端點公開此功能（通過HTTP或JMX），要按名稱刷新單個bean，還有一個refresh(String)方法。

要公開/refresh端點，你需要將以下配置添加到你的應用程序：

management:
  endpoints:
    web:
      exposure:
        include: refresh

@RefreshScope（在技術上）在@Configuration類上工作，但它可能會導致令人驚訝的行為。例如，它并不意味著該類中定義的所有@Beans本身都在@RefreshScope中，具體來說，依賴于那些bean的任何東西都不能依賴于在啟動刷新時更新它們，除非它本身在@RefreshScope中。在這種情況下，它會在刷新時重建，并重新注入其依賴項，此時，它們將從刷新的@Configuration重新初始化。

Spring Cloud有一個Environment預處理器，用于在本地解密屬性值，它遵循與Config Server相同的規則，并通過encrypt.*具有相同的外部配置。因此，你可以使用{cipher}*形式的加密值，只要有有效密鑰，它們就會在主應用程序上下文獲取Environment設置之前被解密。要在應用程序中使用加密功能，你需要在類路徑中包含Spring Security RSA（Maven："org.springframework.security:spring-security-rsa"），并且你還需要JVM中的全強度JCE擴展。

如果由于“Illegal key size”而導致異常，并且你使用Sun的JDK，則需要安裝Java加密擴展（JCE）無限制強度權限策略文件，有關更多信息，請參閱以下鏈接：

Java 6 JCE

Java 7 JCE

Java 8 JCE

無論你使用哪種版本的JRE/JDK x64/x86，都要將文件解壓縮到JDK/jre/lib/security文件夾中。

對于Spring Boot Actuator應用程序，可以使用一些其他管理端點，你可以使用：

POST到/actuator/env以更新Environment并重新綁定@ConfigurationProperties和日志級別。

/actuator/refresh重新加載引導上下文并刷新@RefreshScopebean。

/actuator/restart關閉ApplicationContext并重新啟動它（默認情況下禁用）。

/actuator/pause和/actuator/resume用于調用Lifecycle方法（ApplicationContext上的stop()和start()）。

如果禁用/actuator/restart端點，則/actuator/pause和/actuator/resume端點也將被禁用，因為它們只是/actuator/restart的特殊情況。