全面解读Spring Boot 中的Profile配置体系

Pre

配置体系是基于 Spring Boot 框架开发应用程序的基础，而自动配置也是该框架的核心功能之一,梳理使用 Spring Boot 配置体系的系统方法.

接下来，我们为这个代码工程添加一些支持 RESTful 风格的 Http 端点，在这里我们同样创建一个 CustomerController 类，如下所示

@RestController
@RequestMapping(value="customers")
public class CustomerController {

    @RequestMapping(value = "/{id}", method = RequestMethod.GET)

     public CustomerTicket getCustomerTicketById(@PathVariable Long id) {        

        CustomerTicket customerTicket = new CustomerTicket();
        customerTicket.setId(1L);
        customerTicket.setAccountId(100L);
        customerTicket.setOrderNumber("Order00001");
        customerTicket.setDescription("DemoOrder");
        customerTicket.setCreateTime(new Date());
        return customerTicket;

    }

}

请注意，这里是为了演示方便，我们才使用了硬编码完成了一个 HTTP GET 请求的响应处理。

现在 RESTful 端点已经开发完成，我们需要对这个应用程序进行打包。基于 Spring Boot 和 Maven，当我们使用 mvn package 命令构建整个应用程序时，将得到一个 customerservice-0.0.1-SNAPSHOT.jar 文件，而这个 jar 文件就是可以直接运行的可执行文件，内置了 Tomcat WEB 服务器。也就是说，我们可以通过如下命令直接运行这个 Spring Boot 应用程序：

java –jar customerservice-0.0.1-SNAPSHOT.jar

通过 Postman 访问“http://localhost:8083/customers/1”端点，可以得到如下图所示的HTTP响应结果，说明整个服务已经启动成功。

Spring Boot 中的配置体系

在 Spring Boot 中，其核心设计理念是对配置信息的管理采用约定优于配置。在这一理念下，则意味着开发人员所需要设置的配置信息数量比使用传统 Spring 框架时还大大减少。

当然，今天我们关注的主要是如何理解并使用 Spring Boot 中的配置信息组织方式，这里就需要引出一个核心的概念，即 Profile。

配置文件与 Profile

Profile 本质上代表一种用于组织配置信息的维度，在不同场景下可以代表不同的含义。例如，如果 Profile 代表的是一种状态，我们可以使用 open、halfopen、close 等值来分别代表全开、半开和关闭等。再比如系统需要设置一系列的模板，每个模板中保存着一系列配置项，那么也可以针对这些模板分别创建 Profile。这里的状态或模版的定义完全由开发人员自主设计，我们可以根据需要自定义各种 Profile，这就是 Profile 的基本含义。

为了达到集中化管理的目的，Spring Boot 对配置文件的命名也做了一定的约定，分别使用 label 和 profile 概念来指定配置信息的版本以及运行环境，其中 label 表示配置版本控制信息，而 profile 则用来指定该配置文件所对应的环境

在 Spring Boot 中，配置文件同时支持 .properties 和 .yml 两种文件格式，结合 label 和 profile 概念，如下所示的配置文件命名都是常见和合法的：

/{application}.yml

/{application}-{profile}.yml

/{label}/{application}-{profile}.yml

/{application}-{profile}.properties

/{label}/{application}-{profile}.properties

Yaml 的语法和其他高级语言类似，并且可以非常直观地表达各种列表、清单、标量等数据形态，特别适合用来表达或编辑数据结构和各种配置文件。在这里，我们指定了如下所示的数据源配置，这里使用了 . yml 文件，如下所示：

spring: 

  datasource:

    driver-class-name: com.Mysql.cj.jdbc.Driver

    url: jdbc:mysql://127.0.0.1:3306/account

    username: root

	passWord: root

如果采用 .propertie 配置文件，那么上述配置信息将表示为如下的形式：

spring.datasource.driverClassName=com.mysql.cj.jdbc.Driver

spring.datasource.url=jdbc:mysql://127.0.0.1:3306/account

spring.datasource.username=root 

spring.datasource.password=root

显然，类似这样的数据源通常会根据环境的不同而存在很多套配置。假设我们存在如下所示的配置文件集合：

注意，这里有一个全局的 application.yml 配置文件以及多个局部的 profile 配置文件。

主 application.properties 中指定激活的Profile

那么，如何指定当前所使用的那一套配置信息呢？

在 Spring Boot 中，我们可以在主 application.properties 中使用如下的配置方式来激活当前所使用的 Profile：

spring.profiles.active = test

上述配置项意味着系统当前会读取 application-test.yml 配置文件中的配置内容。同样，如果使用 .yml 文件，则可以使用如下所示的配置方法：

spring:

  profiles:

    active: test

事实上，我们也可以同时激活几个 Profile，这完全取决于你对系统配置的需求和维度：

spring.profiles.active: prod, myprofile1, myprofile2

Profile 配置信息只保存在一个文件

当然，如果你想把所有的 Profile 配置信息只保存在一个文件中而不是分散在多个配置文件中， Spring Boot 也是支持的，需要做的事情只是对这些信息按 Profile 进行组织、分段，如下所示：

spring: 

         profiles: test

         #test 环境相关配置信息

spring: 

         profiles: prod

         #prod 环境相关配置信息

推荐按多个配置文件的组织方法管理各个 Profile 配置信息，这样才不容易混淆和出错。

java –jar 激活Profile

最后，如果我们不希望在全局配置文件中指定所需要激活的 Profile，而是想把这个过程延迟到运行这个服务时，那么我们可以直接在 java –jar 命令中添加“–spring.profiles.active”参数，如下所示

java –jar customerservice-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

这种实现方案在通过脚本进行自动化打包和部署的场景下非常有用。

代码控制与Profile

在 Spring Boot 中，Profile 这一概念的应用场景还包括动态控制代码执行流程。为此，我们需要使用 @Profile 注解，先来看一个简单的示例。

@Configuration

public class DataSourceConfig {

 

    @Bean

    @Profile("dev")

    public DataSource devDataSource() {

        //创建 dev 环境下的 DataSource 

    }

 

    @Bean()

    @Profile("prod")

    public DataSource prodDataSource(){

        //创建 prod 环境下的 DataSource 

    }

}

可以看到，我们构建了一个 DataSourceConfig 配置类来专门管理各个环境所需的 DataSource。注意到这里使用 @Profile 注解来指定具体所需要执行的 DataSource 创建代码，通过这种方式，可以达到与使用配置文件相同的效果。

更进一步，能够在代码中控制 JavaBean 的创建过程为我们根据各种条件动态执行代码流程提供了更大的可能性。

例如，在日常开发过程中，一个常见的需求是根据不同的运行环境初始化数据，常见的做法是独立执行一段代码或脚本。基于 @Profile 注解，我们就可以将这一过程包含在代码中并做到自动化，如下所示：

@Profile("dev")

@Configuration

public class DevDatainitConfig {

 

@Bean

  public CommandLineRunner dataInit() { 

    return new CommandLineRunner() {

      @Override

      public void run(String... args) throws Exception {

        //执行 Dev 环境的数据初始化

    };  

}

这里用到了 Spring Boot 所提供了启动时任务接口 CommandLineRunner，实现了该接口的代码会在 Spring Boot 应用程序启动时自动进行执行 。

@Profile 注解的应用范围很广，我们可以将它添加到包含 @Configuration 和 @Component 注解的类及其方法，也就是说可以延伸到继承了 @Component 注解的 @Service、@Controller、@Repository 等各种注解中。

常见配置场景和内容

下面来看几个常见的配置示例 ， 加深对 Spring Boot 中配置体系的理解。

对于一个 Web 应用程序而言，最常见的配置可能就是指定服务暴露的端口地址，如下所示：

server:

    port: 8080

同时，数据库访问也是 Web 应用程序的基本功能，因此，关于数据源的设置也是常见的一种配置场景，上一篇博文时给出了一个基本的示例。

这里再以 JPA 为例，给出如下所示的一种配置方案：

spring:
  jpa:
    hibernate:
      ddl-auto: create
    show-sql: true

显然，这里使用了 Hibernate 作为 JPA 规范的实现框架，并设置了 show-sql 等相关属性。然后，开发人员一般也需要设置日志级别和对象，如下所示的就是一个典型的配置示例：

logging.level.root=WARN
logging.level.com.springCSS.customer=INFO

我们设置了系统的全局日志级别为 WARN，而针对自定义的 com.sprinGCss.customer 包下的日志则将其级别调整到 INFO。

这里需要注意的是，Spring Boot 基于 application.properties 或 application.yml 全局配置文件已经自动内置了很多默认配置。即使我们不设置上述配置内容，Spring Boot 仍然可以基于这些默认配置完成系统的初始化。

自动配置是 Spring Boot 中的一个核心概念，我们会在后续内容中给出详细的实现原理分析。

如何在应用程序中嵌入系统配置信息

我们知道 Spring Boot 通过自动配置机制内置了很多默认的配置信息，而在这些配置信息中，有一部分系统配置信息也可以反过来作为配置项应用到我们的应用程序中。

例如，如果想要获取当前应用程序的名称并作为一个配置项进行管理，那么很简单，我们直接通过 ${spring.application.name} 占位符就可以做到这一点，如下所示：

myapplication.name : ${spring.application.name}

通过 ${} 占位符同样可以引用配置文件中的其他配置项内容，如在下列配置项中，最终“system.description”配置项的值就是“The system springcss is used for health”。

system.name=springcss
system.domain=health
system.description=The system ${name} is used for ${domain}.

再来看一种场景，假设我们使用 Maven 来构建应用程序，那么可以按如下所示的配置项来动态获取与系统构建过程相关的信息：

info: 
  app:
    encoding: @project.build.sourceEncoding@
    java:
      source: @java.version@
      target: @java.version@

上述配置项的效果与如下所示的静态配置是一样的：

info:
  app:
    encoding: UTF-8
    java:
        source: 1.8.0_31
        target: 1.8.0_31

根据不同的需求，在应用程序中嵌入系统配置信息是很有用的，特别是在一些面向 devops 的应用场景中。

如何创建和使用自定义配置信息

在现实的开发过程中，面对纷繁复杂的应用场景，Spring Boot 所提供的内置配置信息并不一定能够完全满足开发的需求，这就需要开发人员创建并管理各种自定义的配置信息。

例如，对于一个电商类应用场景，为了鼓励用户完成下单操作，我们希望每完成一个订单给就给到用户一定数量的积分。从系统扩展性上讲，这个积分应该是可以调整的，所以我们创建了一个自定义的配置项，如下所示：

springcss.order.point = 10

这里，我们设置了每个订单对应的积分为 10，那么应用程序该如何获取这个配置项的内容呢？通常有两种方法。

使用 @Value 注解

使用 @Value 注解来注入配置项内容是一种传统的实现方法。针对前面给出的自定义配置项，我们可以构建一个 SpringCssConfig 类，如下所示：

@Component
public class SpringCssConfig {

    @Value("${springcss.order.point}")
    private int point;

}

在 SpringCssConfig 类中，我们要做的就是在字段上添加 @Value 注解，并指向配置项的名称即可。

使用 @ConfigurationProperties 注解

相较 @Value 注解，更为现代的一种做法是使用 @ConfigurationProperties 注解。在使用该注解时，我们通常会设置一个“prefix”属性用来指定配置项的前缀，如下所示：

@Component
@ConfigurationProperties(prefix = "springcss.order")
public class SpringCsshConfig {

	private int point;

	//省略 getter/setter

}

相比 @Value 注解只能用于指定具体某一个配置项，@ConfigurationProperties 可以用来批量提取配置内容。只要指定 prefix，我们就可以把该 prefix 下的所有配置项按照名称自动注入业务代码中。

我们考虑一种更常见也更复杂的场景：假设用户根据下单操作获取的积分并不是固定的，而是根据每个不同类型的订单会有不同的积分，那么现在的配置项的内容，如果使用 Yaml 格式的话就应该是这样：

springcss:
    points:
      orderType[1]: 10
      orderType[2]: 20
      orderType[3]: 30

如果想把这些配置项全部加载到业务代码中，使用 @ConfigurationProperties 注解同样也很容易实现。我们可以直接在配置类 SpringCssConfig 中定义一个 Map 对象，然后通过 Key-Value 对来保存这些配置数据，如下所示：

@Component
@ConfigurationProperties(prefix="springcss.points")
public class SpringCssConfig {


    private Map<String, Integer> orderType = new HashMap<>();

	//省略 getter/setter

}

可以看到这里通过创建一个 HashMap 来保存这些 Key-Value 对。类似的，我们也可以实现常见的一些数据结构的自动嵌入。

为自定义配置项添加提示功能

如果你已经使用过 Spring Boot 中的配置文件，并添加了一些内置的配置项，你就会发现，当我们输入某一个配置项的前缀时，诸如 idea、Eclipse 这样的，IDE 就会自动弹出该前缀下的所有配置信息供你进行选择，效果如下：

上图的效果对于管理自定义的配置信息非常有用。如何实现这种效果呢？当我们在 application.yml 配置文件中添加一个自定义配置项时，会注意到 IDE 会出现一个提示，说明这个配置项无法被 IDE 所识别，如下所示：

遇到这种提示时，我们是可以忽略的，因为它不会影响到任何执行效果。

但为了达到自动提示效果，我们就需要生成配置元数据。生成元数据的方法也很简单，直接通过 IDE 的“Create metadata for ‘springcss.order.point'”按钮，就可以选择创建配置元数据文件，这个文件的名称为 additional-spring-configuration-metadata.JSON，文件内容如下所示：

{"properties": [{
  "name": "springcss.order.point",
  "type": "java.lang.String",
  "description": "A description for 'springcss.order.point'"
}]}

现在，假如我们在 application.properties 文件中输入“springcss”，IDE 就会自动提示完整的配置项内容，效果如下所示：

另外，假设我们需要为 springcss.order.point 配置项指定一个默认值，可以通过在元数据中添加一个"defaultValue"项来实现，如下所示：

{"properties": [{
  "name": "springcss.order.point",
  "type": "java.lang.String",
  "description": "'springcss.order.point' is userd for setting the point when dealing with an order.",
  "defaultValue": 10
}]}

这时候，在 IDE 中设置这个配置项时，就会提出该配置项的默认值为 10，效果如下所示：

如何组织和整合配置信息

Profile 可以认为是管理配置信息中的一种有效手段。

下面，我们继续介绍另一种组织和整合配置信息的方法，这种方法同样依赖于前面介绍的 @ConfigurationProperties 注解。

使用 @PropertySources 注解

在使用 @ConfigurationProperties 注解时，我们可以和 @PropertySource 注解一起进行使用，从而指定从哪个具体的配置文件中获取配置信息。

例如，在下面这个示例中，我们通过 @PropertySource 注解指定了 @ConfigurationProperties 注解中所使用的配置信息是从当前类路径下的 application.properties 配置文件中进行读取。

@Component
@ConfigurationProperties(prefix = "springcss.order")
@PropertySource(value = "classpath:application.properties")
public class SpringCssConfig {

}

既然我们可以通过 @PropertySource 注解来指定一个配置文件的引用地址，那么显然也可以引入多个配置文件，这时候用到的是 @PropertySources 注解，使用方式如下所示：

@PropertySources({
        @PropertySource("classpath:application.properties "),
        @PropertySource("classpath:Redis.properties"),
        @PropertySource("classpath:MQ.properties")
})

public class SpringCssConfig {

这里，我们通过 @PropertySources 注解组合了多个 @PropertySource 注解中所指定的配置文件路径。SpringCssConfig 类可以同时引用所有这些配置文件中的配置项。

spring.config.location 来改变配置文件的默认加载位置

另一方面，我们也可以通过配置 spring.config.location 来改变配置文件的默认加载位置，从而实现对多个配置文件的同时加载。例如，如下所示的执行脚本会在启动 customerservice-0.0.1-SNAPSHOT.jar 时加载D盘下的 application.properties 文件，以及位于当前类路径下 config 目录中的所有配置文件：

java -jar customerservice-0.0.1-SNAPSHOT.jar --spring.config.location=file:///D:/application.properties, classpath:/config/

通过 spring.config.location 指定多个配置文件路径也是组织和整合配置信息的一种有效的实现方式。

理解配置文件的加载顺序

通过前面的示例，我们看到可以把配置文件保存在多个路径，而这些路径在加载配置文件时具有一定的顺序。Spring Boot 在启动时会扫描以下位置的 application.properties 或者 application.yml 文件作为全局配置文件：

–file:./config/

–file:./

–classpath:/config/

–classpath:/

以下是按照优先级从高到低的顺序，如下所示：

Spring Boot 会全部扫描上图中的这四个位置，扫描规则是高优先级配置内容会覆盖低优先级配置内容。而如果高优先级的配置文件中存在与低优先级配置文件不冲突的属性，则会形成一种互补配置，也就是说会整合所有不冲突的属性。

如何覆写内置的配置类

关于 Spring Boot 配置体系，最后值得介绍的就是如何覆写它所提供的配置类。我们已经反复强调 Spring Boot 内置了大量的自动配置，如果我们不想使用这些配置，就需要对它们进行覆写。

覆写的方法有很多，我们可以使用配置文件、Groovy 脚本以及 Java 代码。这里，我们就以Java代码为例来简单演示覆写配置类的实现方法。

以Spring Security为例

在 Spring Security 体系中，设置用户认证信息所依赖的配置类是 WebSecurityConfigurer 类。顾名思义，这是一个设置 Web 安全的配置类。

Spring Security 提供了 WebSecurityConfigurerAdapter 这个适配器类来简化该配置类的使用方式，我们可以继承 WebSecurityConfigurerAdapter 类并且覆写其中的 configure() 的方法来完成自定义的用户认证配置工作。

典型的 WebSecurityConfigurerAdapter 子类及其代码实现如下所示

@Configuration
public class SpringHCssWebSecurityConfigurer extends WebSecurityConfigurerAdapter {

    @Override
    @Bean
    public AuthenticationManager authenticationManagerBean() throws Exception {
       return super.authenticationManagerBean();
    }

 

    @Override
    @Bean
    public UserDetailsService userDetailsServiceBean() throws Exception {
        return super.userDetailsServiceBean();
    }

 

    @Override
    protected void configure(AuthenticationManagerBuilder builder) throws Exception {
   			  builder.inMemoryAuthentication().withUser("springcss_user").password("{noop}password1").roles("USER").and()
                .withUser("springcss_admin").password("{noop}password2").roles("USER", "ADMIN");

    }

}

这里我们只需要知道，在 Spring Boot 中，提供了一些类的内置配置类，而开发人员可以通过构建诸如上述所示的 SpringCssWebSecurityConfigurer 类来对这些内置配置类进行覆写，从而实现自定义的配置信息。

以上就是Spring Boot 中的配置体系Profile全面解读的详细内容，更多关于Spring Boot配置体系Profile的资料请关注编程网其它相关文章！