SpringCloud入门之常用的配置文件 application.yml和 bootstrap.yml区别

作者其他技术文章

1) Spring Boot 简介

2)SpringCloud入门之YAML格式文件规范学习

3)SpringCloud入门之Spring Boot多环境配置切换指南

4) Elasticsearch从入门到精通

5) Kibana从入门到精通

6) logstash快速入门实战指南

7)Oracle性能优化之查询语句通用原则  

8)Redis常用命令

9) 详解Maven用户的配置settings.xml

10)#ifndef、#def、#endif说明

 

SpringBoot默认支持properties和YAML两种格式的配置文件。前者格式简单,但是只支持键值对。如果需要表达列表,最好使用YAML格式。SpringBoot支持自动加载约定名称的配置文件,例如application.yml。如果是自定义名称的配置文件,就要另找方法了。可惜的是,不像前者有@PropertySource这样方便的加载方式,后者的加载必须借助编码逻辑来实现。

一、bootstrap.yml(bootstrap.properties)与application.yml(application.properties)执行顺序

bootstrap.yml(bootstrap.properties)用来程序引导时执行,应用于更加早期配置信息读取,如可以使用来配置application.yml中使用到参数等

application.yml(application.properties) 应用程序特有配置信息,可以用来配置后续各个模块中需使用的公共参数等。

bootstrap.yml 先于 application.yml 加载

二、典型的应用场景如下:

  • 当使用 Spring Cloud Config Server 的时候,你应该在 bootstrap.yml 里面指定 spring.application.name 和 spring.cloud.config.server.git.uri
  • 和一些加密/解密的信息

技术上,bootstrap.yml 是被一个父级的 Spring ApplicationContext 加载的。这个父级的 Spring ApplicationContext是先加载的,在加载application.yml 的 ApplicationContext之前。

为何需要把 config server 的信息放在 bootstrap.yml 里?

当使用 Spring Cloud 的时候,配置信息一般是从 config server 加载的,为了取得配置信息(比如密码等),你需要一些提早的或引导配置。因此,把 config server 信息放在 bootstrap.yml,用来加载真正需要的配置信息。

三、高级使用场景

启动上下文

Spring Cloud会创建一个`Bootstrap Context`,作为Spring应用的`Application Context`的父上下文初始化的时候,`Bootstrap Context`负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的`Environment`。`Bootstrap`属性有高优先级,默认情况下,它们不会被本地配置覆盖。 `Bootstrap context`和`Application Context`有着不同的约定,所以新增了一个`bootstrap.yml`文件,而不是使用`application.yml` (或者`application.properties`)。保证`Bootstrap Context`和`Application Context`配置的分离。下面是一个例子: **bootstrap.yml**

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

 

推荐在`bootstrap.yml` or `application.yml`里面配置`spring.application.name`. 你可以通过设置`spring.cloud.bootstrap.enabled=false`来禁用`bootstrap`。

应用上下文层次结构

如果你通过`SpringApplication`或者`SpringApplicationBuilder`创建一个`Application Context`,那么会为spring应用的`Application Context`创建父上下文`Bootstrap Context`。在Spring里有个特性,子上下文会继承父类的`property sources` and `profiles` ,所以`main application context` 相对于没有使用Spring Cloud Config,会新增额外的`property sources`。额外的`property sources`有:

  • “bootstrap” : 如果在Bootstrap Context扫描到PropertySourceLocator并且有属性,则会添加到CompositePropertySourceSpirng Cloud Config就是通过这种方式来添加的属性的,详细看源码ConfigServicePropertySourceLocator`。下面也也有一个例子自定义的例子。
  • “applicationConfig: [classpath:bootstrap.yml]” ,(如果有spring.profiles.active=production则例如 applicationConfig: [classpath:/bootstrap.yml]#production): 如果你使用bootstrap.yml来配置Bootstrap Context,他比application.yml优先级要低。它将添加到子上下文,作为Spring Boot应用程序的一部分。下文有介绍。

由于优先级规则,Bootstrap Context不包含从bootstrap.yml来的数据,但是可以用它作为默认设置。

你可以很容易的扩展任何你建立的上下文层次,可以使用它提供的接口,或者使用SpringApplicationBuilder包含的方法(parent()child()sibling())。Bootstrap Context将是最高级别的父类。扩展的每一个Context都有有自己的bootstrap property source(有可能是空的)。扩展的每一个Context都有不同spring.application.name。同一层层次的父子上下文原则上也有一有不同的名称,因此,也会有不同的Config Server配置。子上下文的属性在相同名字的情况下将覆盖父上下文的属性。

注意SpringApplicationBuilder允许共享Environment到所有层次,但是不是默认的。因此,同级的兄弟上下文不在和父类共享一些东西的时候不一定有相同的profiles或者property sources

修改Bootstrap属性配置

源码位置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 就是配置了profiledevelopment的配置文件.

覆盖远程属性

property sourcesbootstrap 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"));
    }
}
 

 

EnvironmentApplicationContext建立,并传入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将会被包含到应用。

### Spring Boot 中 `application.yml` `bootstrap.yml` 的作用与区别 #### 1. 文件加载顺序 在 Spring Boot 应用程序启动过程中,`bootstrap.yml` 或 `bootstrap.properties` 是优先于 `application.yml` 或 `application.properties` 加载的。这意味着如果存在 `bootstrap.yml`,它会在应用程序上下文初始化之前被读取并应用于引导阶段[^1]。 #### 2. `bootstrap.yml` 的用途 `bootstrap.yml` 主要用于配置需要在应用程序上下文初始化之前的引导阶段完成的任务。这些任务通常涉及外部化配置源或服务注册发现机制。以下是其主要功能: - **配置中心集成**:当使用分布式配置管理工具(如 Spring Cloud Config)时,可以在 `bootstrap.yml` 中指定配置服务器的位置以及环境信息。 - **全局共享配置**:可以定义一些通用属性供多个微服务实例继承覆盖。 - **早起绑定参数**:某些框架组件可能依赖特定的早期可用配置项来正常工作,比如 Eureka 客户端的服务地址设置等[^2]。 #### 3. `application.yml` 的用途 相比之下,`application.yml` 更侧重于描述具体的应用级特性及其运行时行为调整选项。它的适用范围更广也更加灵活多样,适合用来存储那些仅限当前应用内部使用的个性化定制数据。主要包括但不限于以下几个方面: - 数据库连接字符串、用户名密码认证凭证等相关细节; - 缓存策略设定; - 日志级别控制以及其他各类中间件交互接口的具体实现方式等等。 #### 4. 结合场景分析 在一个典型的基于云原生架构设计下的 Java 微服务体系里头,我们往往会看到如下实践模式: - 将所有关于远程仓库链接指向或者默认版本号之类的基础元数据放置到单独分开维护的一份名为 “global-config”的 GitLab/GitHub Repository 当中去,并通过引入 spring-cloud-starter-config 来动态拉取最新版次的内容填充至本地内存映射表结构之中以便后续操作调用所需;与此同时,在此期间所涉及到的一切必要的网络通信协议类型切换开关状态标志位均需提前写入位于根目录下命名为“boostrap.yaml”(注意大小写敏感度差异!)这样的特殊命名规则遵循严格限定条件约束下的专属文件当中加以固定下来不可随意更改以免造成不必要的混乱局面发生; 另一方面,则把诸如针对某个具体的 RESTful API 接口请求超时时长限制值或者是 Kafka 消息队列分区数分配比例之类的细粒度级别的业务逻辑关联性强的数据要素记录保存进另一个叫做“applicaton.yaml”的常规意义上的资源配置文档里面去统一管理分发给各个不同的子模块单元独立自主地按照各自的需求情况自行选取适配最佳方案执行下去即可。 ```yaml # Example of bootstrap.yml content spring: application: name: my-service-name cloud: config: uri: http://config-server.example.com ``` ```yaml # Example of application.yml content server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/mydb username: root password: secret logging: level: org.springframework.web: DEBUG ``` ### 总结 综上所述,虽然两者都是 YAML 格式的纯文本形式存在的静态资源文件,但是它们之间存在着本质上的不同之处——前者偏向于是整个系统的基础设施层面搭建过程中的前置准备工作环节不可或缺的一部分构成要素之一; 而后者则更多体现出来的是面向最终用户的实际应用场景需求满足方面的高度灵活性特点表现出来的强大适应能力优势所在[^2].
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值