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

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

为什么要进行这些更改

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

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

心愿同时提供两者的反对，并且可能兼容咱们现有的 application.properties 和 application.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.properties 或 application.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.properties 和 application.yml 文件更加容易了解。使得 Spring Boot 自身更易于治理和保护。

Profile Groups

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

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

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

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

Importing 扩大 Configuration

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

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

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

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

甚至能够将 spring.config.import 与 spring.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.application 和 test 属性。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.config 包 ConfigDataLocationResolver 和 ConfigDataLoader 的 javadoc。

版本回滚

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

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

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

总结

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

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

翻译：冷冷、如梦技术

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