乐趣区

关于java:Spring-Boot-24-配置文件将加载机制大变化

Spring Boot 2.4.0.M2 刚刚公布,它对 application.propertiesapplication.yml 文件的加载形式进行重构。如果应用程序仅应用单个 application.propertiesapplication.yml 作为配置文件,那么可能感触不到任何区别。然而如果您的应用程序应用更简单的配置(例如,Spring Cloud 配置核心等),则须要来理解更改的内容以及起因。

为什么要进行这些更改

随着最新版本 Spring Boot 公布,Spring 始终在致力晋升对 Kubernetes 的原生反对。在 Spring Boot 2.3 中,官网减少 Kubernetes Volume 的配置反对,然而未能实现。

Volume 配置挂载是 Kubernetes 的一项罕用性能,其中 ConfigMap 指令用于间接在文件系统上显示配置。您能够装载蕴含多个键和值合并的残缺 YAML 文件,也能够应用更简略的目录树格局,其中文件名是键,文件内容是值。

心愿同时提供两者的反对,并且可能兼容咱们现有的 application.propertiesapplication.yml。为此须要批改 ConfigFileApplicationListener 类。

ConfigFileApplicationListener 问题

在 Spring Boot 中配置文件加载类 ConfigFileApplicationListener 属于比拟外围的底层代码,每次保护都是十分的艰难。并不是因为代码编写谬误或者短少相干单元测试,而是在增加新性能时,很难解决之前存在的问题。

即:

  • 配置文件非常灵活,能够在以后文件启用其余配置文件。
  • 文档加载程序不固定。

以上面的例子来说:

security.user.password: usera
---
spring.profiles: local
security.user.password: userb
runlocal: true
---
spring.profiles: !dev
spring.profiles.include: local
security.user.password: userc

在这里,咱们有一个 多文档 YAML 文件(一个文件由三个逻辑文档组成,由 --- 分隔)。

如果应用 --spring.profile.actives=prod 运行,那么 security.user.password 的值是什么?是否设置 runlocal 属性?两头局部文档是否包含在内,因为配置文件在解决时没有激活?

咱们常常会遇到对于这个文件解决逻辑的问题,然而每当试图修复它们时,最初带来各种各样的负面问题。

因而,在 Spring boot 2.4 中对 Properties 和 YAML 文件的加载形式进行两个重大更改:

  1. 文档将按定义的程序加载。
  2. profiles 激活开关不能被配置在特定环境中。

文档排序

从 Spring Boot 2.4 开始,加载 Properties 和 YAML 文件时候会遵循, 在文档中申明排序靠前的属性将被靠后的属性笼罩

这点与 .properties 的排序规定雷同。咱们能够想一想,每次将一个 Value 放入 Map,具备雷同 key 的新值放入时,将替换曾经存在的 Value。

同理对 Multi-document 的 YAML 文件,较低的排序也将被较高的笼罩:

test: "value"
---
test: "overridden-value"

Properties 文件反对多文档属性

在 Spring Boot 2.4 中,Properties 反对相似 YAML 多文档性能。多文档属性文件应用正文(#)后跟三个(—)破折号来分隔文档( 抉择应用正文,以使现有的 IDE 失常反对 )。

例如,下面的 YAML 等效的 properties 为:

test=value
#---
test=overridden-value

特定环境激活配置

上述示例实际上没有任何意义, 在咱们开发过程中更为常见是申明某个属性仅在特定环境失效激活。

在 Spring Boot 2.3 中能够配置 spring.profiles 来实现。但在 Spring Boot 2.4 中 属性更改 spring.config.activate.on-profile

例如,咱们想要 test 属性仅仅在 dev Profile 激活时笼罩它,则能够应用以下配置:

test=value
#---
spring.config.activate.on-profile=dev
test=overridden-value

Profile Activation

应用 spring.profiles.active 属性在 application.propertiesapplication.yaml 文件的 根配置文件 来激 相干环境文件。

例如,上面这样:

test=value
spring.profiles.active=local
#---
spring.config.activate.on-profile=dev
test=overridden value

不容许的是将 spring.profiles.active 属性与 spring.config.activate.on-profile 一起应用。例如,以下文件将引发异样:

test=value
#---
spring.config.activate.on-profile=dev
spring.profiles.active=local # will fail
test=overridden value

通过这一新限度能使 application.propertiesapplication.yml 文件更加容易了解。使得 Spring Boot 自身更易于治理和保护。

Profile Groups

Profile Groups 是 Spring Boot 2.4 中的一项新性能,可让您将单个配置文件扩大为多个子配置文件。例如,假如有一组简单的 @Configuration 类,能够应用 @Profile 正文有条件地启用它们。应用 @Profile("proddb") 开启数据库配置,应用 @Profile("prodmq") 开启音讯配置等等。

应用多个配置文件能够使咱们的代码更易于了解,然而对于部署而言并不是现实的抉择。若用户须要同时激活 proddbprodmqprodmetrics 等。那么 Profile Groups 可让您做到这一点。

您能够在 application.propertiesapplication.yml 文件中定义 spring.profiles.group,那么开启 prod 则就相当于激活了此组的全副环境 。例如:

spring.profiles.group.prod=proddb,prodmq,prodmetrics

Importing 扩大 Configuration

当初,咱们曾经解决了配置文件解决的根本问题,咱们终于可能思考咱们想要提供的新性能。咱们应用 Spring Boot 2.4 提供的次要性能是反对导入其余配置。

对于晚期版本的 Spring Boot,很难在 application.propertiesapplication.yml 之外导入其余 propertiesyaml 文件。能够应用 spring.config.additional-location 属性但它能够解决的文件类型十分无限。

在 Spring Boot 2.4 能够间接在 application.propertiesapplication.yml 文件中应用新的 spring.config.import 属性。例如心愿导入一个 “ 疏忽的 git” 的 developer.properties 文件,以便团队中的任何开发人员都能够疾速更改属性:

application.name=myapp
spring.config.import=developer.properties

甚至能够将 spring.config.importspring.config.activate.on-profile 联合起来应用。例如,这里 prod.properties 仅在 prod 配置文件处于激活状态时加载:

spring.config.activate.on-profile=prod
spring.config.import=prod.properties

Import 能够被视为在申明它们的文档下方插入的其余文档。它们 遵循与惯例多文档文件雷同的自上而下的程序:导入仅被导入一次,无论申明了多少次。

volume 挂载配置

导入定义应用与 URL 一样语法作为其值。如果您的地位没有前缀,则它被视为惯例文件或文件夹。然而,如果您应用 configtree: 前缀,则通知 Spring Boot,您将冀望在该地位应用 Kubernetes volume 装载的配置树。

例如,您能够在 application.properties 配置:

spring.config.import=configtree:/etc/config

如果您有以下装载的内容:

etc/
 +- config/
     +- my/
     |  +- application
     +- test

将在 Spring Environment 中领有 my.applicationtest 属性。my.application 的值是 /etc/config/my/application 的内容,test 的值是 /etc/config/test 的内容。

依据云平台类型激活

如果只心愿 Volume 挂载的配置(或该内容的任何属性)在特 定的云平台上 处于激活状态,能够应用 spring.config.activate.on-cloud-platform 属性。它的工作形式与 spring.config.activate.on-profile 相似,但它应用 CloudPlatform 的值,而不是配置文件名称。

如果咱们想要在部署到 Kubernetes 时启用上述配置树,咱们能够执行以下操作:

spring.config.activate.on-cloud-platform=kubernetes
spring.config.import=configtree:/etc/config

反对其余地位

spring.config.import 属性中指定的地位字符串是齐全可插拔的,能够通过编写几个自定义类来扩大,第三方库将对自定义地位提供反对。例如,你能想到的第三方 jar 文件,例如 archaius://…vault://…zookeeper://…

如果您有趣味增加其余地位反对,请查看 org.springframework.boot.context.configConfigDataLocationResolverConfigDataLoader 的 javadoc。

版本回滚

正如上文所形容的,Spring Boot 针对配置文件的性能变更是十分大的。思考到低版本的兼容性

能够设置 spring.config.use-legacy-processing=true 属性即可,复原到之前版本的文件解决机制。

如果发现对于此处的问题,则须要切换到旧版解决,请 在 GitHub 上提出问题,官网将尝试解决该问题。

总结

官网心愿新的配置数据处理更加好用,并且不会引起太多降级麻烦。如果您想理解更多无关它们的信息,能够查阅更新的 参考文档。

欢送关注我,后续会通过代码来具体阐明此处变更。

翻译:冷冷、如梦技术

原文链接:https://spring.io/blog/2020/0…

退出移动版