Was ist der Unterschied zwischen SpringBoot application.yml und bootstrap.yml?

SpringBoot unterstützt standardmäßig Konfigurationsdateien in zwei Formaten: Eigenschaften und YAML. Ersteres hat ein einfaches Format, unterstützt jedoch nur Schlüssel-Wert-Paare. Wenn Sie eine Liste ausdrücken müssen, verwenden Sie am besten das YAML-Format. SpringBoot unterstützt das automatische Laden von Konfigurationsdateien mit vereinbarten Namen, z. B. application.yml. Wenn es sich um eine Konfigurationsdatei mit einem benutzerdefinierten Namen handelt, müssen Sie eine andere Methode finden. Im Gegensatz zu Ersterem, das über eine praktische Lademethode wie @PropertySource verfügt, muss das Laden von Letzterem leider mit Hilfe der Codierungslogik erreicht werden.

1. Ausführungsreihenfolge von bootstrap.yml (bootstrap.properties) und application.yml (application.properties)

bootstrap.yml (bootstrap.properties) wird zur Ausführung beim Booten des Programms und für frühere Konfigurationsinformationen verwendet Sie können damit beispielsweise die in application.yml verwendeten Parameter konfigurieren.

application.yml (application.properties) anwendungsspezifische Konfigurationsinformationen, die zum Konfigurieren der öffentlichen Parameter verwendet werden können jedes weitere Modul.

bootstrap.yml wird vor application.yml geladen

2. Typische Anwendungsszenarien sind wie folgt:

• Bei Verwendung von Spring Cloud Config Server sollten Sie spring.application.name und spring in bootstrap.yml angeben. config.server.git.uri

• und einige verschlüsselte/entschlüsselte Informationen

Technisch gesehen wird bootstrap.yml von einem übergeordneten Spring ApplicationContext geladen. Der Spring ApplicationContext des übergeordneten Elements wird zuerst geladen, bevor der ApplicationContext von application.yml geladen wird.

Warum müssen wir die Konfigurationsserverinformationen in bootstrap.yml einfügen?

Bei Verwendung von Spring Cloud werden Konfigurationsinformationen im Allgemeinen vom Konfigurationsserver geladen. Um Konfigurationsinformationen (z. B. Passwörter usw.) zu erhalten, benötigen Sie eine frühe Startkonfiguration. Fügen Sie daher die Konfigurationsserverinformationen in bootstrap.yml ein, um die in diesem Zeitraum wirklich benötigten Konfigurationsinformationen zu laden.

3. Erweiterte Nutzungsszenarien

Startkontext

Spring Cloud erstellt einen Bootstrap-Kontext als übergeordneten Kontext des Anwendungskontexts der Spring-Anwendung. Während der Initialisierung ist Bootstrap Context dafür verantwortlich, Konfigurationseigenschaften aus externen Quellen zu laden und Konfigurationen zu analysieren. Die beiden Kontexte teilen sich eine von außen erhaltene Umgebung. Bootstrap-Eigenschaften haben eine hohe Priorität und werden standardmäßig nicht durch die lokale Konfiguration überschrieben. Bootstrap-Kontext und Anwendungskontext haben unterschiedliche Konventionen, daher wird eine neue Datei „bootstrap.yml“ anstelle von „application.yml“ (oder „application.properties“) hinzugefügt. Stellen Sie die Trennung von Bootstrap-Kontext- und Anwendungskontext-Konfigurationen sicher. Hier ist ein Beispiel:

bootstrap.yml

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

Es wird empfohlen, spring.application.name in bootstrap.yml oder application.yml zu konfigurieren. Sie können Bootstrap deaktivieren, indem Sie spring.cloud.bootstrap.enabled=false festlegen.

Anwendungskontexthierarchie

Wenn Sie einen Anwendungskontext über SpringApplication oder SpringApplicationBuilder erstellen, wird der Bootstrap-Kontext des übergeordneten Kontexts für den Anwendungskontext der Spring-Anwendung erstellt. In Spring gibt es eine Funktion, mit der der untergeordnete Kontext die Eigenschaftsquellen und Profile der übergeordneten Klasse erbt, sodass der Hauptanwendungskontext im Vergleich zur Nichtverwendung von Spring Cloud Config zusätzliche Eigenschaftsquellen hinzufügt. Zusätzliche Eigenschaftsquellen sind:

• "bootstrap": Wenn der PropertySourceLocator im Bootstrap-Kontext gescannt wird und eine Eigenschaft vorhanden ist, wird diese zur CompositePropertySource hinzugefügt. Spirng Cloud Config fügt Eigenschaften auf diese Weise hinzu. Weitere Informationen finden Sie im Quellcode „ConfigServicePropertySourceLocator“. Unten finden Sie auch ein Beispiel für die Anpassung.

• "applicationConfig: [classpath:bootstrap.yml]" , (wenn spring.profiles.active=produktion vorhanden ist, dann zum Beispiel applicationConfig: [classpath:/bootstrap.yml]#produktion): Wenn Sie bootstrap.yml verwenden Um den Bootstrap-Kontext zu konfigurieren, hat er eine niedrigere Priorität als application.yml. Es wird als Teil der Spring Boot-Anwendung zum untergeordneten Kontext hinzugefügt. Nachfolgend vorgestellt.

Aufgrund von Prioritätsregeln enthält Bootstrap Context keine Daten aus bootstrap.yml, kann aber als Standardeinstellungen verwendet werden.

Sie können jede von Ihnen erstellte Kontexthierarchie problemlos erweitern, indem Sie die bereitgestellte Schnittstelle oder die in SpringApplicationBuilder enthaltenen Methoden (parent(), child(), sibling()) verwenden. Der Bootstrap-Kontext ist die übergeordnete Klasse der höchsten Ebene. Jeder erweiterte Kontext verfügt über eine eigene Bootstrap-Eigenschaftsquelle (die leer sein kann). Jeder erweiterte Kontext hat einen anderen spring.application.name. Grundsätzlich haben Eltern-Kind-Kontexte auf derselben Ebene auch unterschiedliche Namen und daher wird es auch unterschiedliche Config-Server-Konfigurationen geben. Eigenschaften des untergeordneten Kontexts überschreiben diejenigen des übergeordneten Kontexts, wenn sie denselben Namen haben.

Beachten Sie, dass SpringApplicationBuilder die gemeinsame Nutzung der Umgebung auf allen Ebenen ermöglicht, jedoch nicht standardmäßig. Daher haben Geschwisterkontexte auf derselben Ebene möglicherweise nicht unbedingt dieselben Profile oder Eigenschaftsquellen, wenn sie nichts mit der übergeordneten Klasse gemeinsam haben.

Ändern Sie die Konfiguration des Bootstrap-Attributs

Speicherort des Quellcodes 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将会被包含到应用。

Das obige ist der detaillierte Inhalt vonWas ist der Unterschied zwischen SpringBoot application.yml und bootstrap.yml?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!