抢先⽬睹：SpringBoot2.4配置⽂件加载机制⼤变化
Spring Boot 2.4.0.M2 刚刚发布，它对 application.properties 和 l ⽂件的加载⽅式进⾏重构。如果应⽤程序仅使⽤单个application.properties 或 l 作为配置⽂件，那么可能感受不到任何区别。但是如果您的应⽤程序使⽤更复杂的配置（例如，Spring Cloud 配置中⼼等），则需要来了解更改的内容以及原因。
为什么要进⾏这些更改
随着最新版本 Spring Boot 发布，Spring ⼀直在努⼒提升对 Kubernetes 的原⽣⽀持。在 Spring Boot 2.3 中，官⽅增
加 Kubernetes Volume 的配置⽀持，但是未能实现。
Volume 配置挂载是 Kubernetes 的⼀项常⽤功能，其中 ConfigMap 指令⽤于直接在⽂件系统上显⽰配置。您可以装载包含多个键和值合并的完整 YAML ⽂件，也可以使⽤更简单的⽬录树格式，其中⽂件名是键，⽂件内容是值。
希望同时提供两者的⽀持，并且能够兼容我们现有的 application.properties 和 l 。为此需要修改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 中 属性更改为 -profile 。
例如，我们想要 test 属性仅仅在 dev Profile 激活时覆盖它，则可以使⽤以下配置：
test=value
#---
<-profile=dev
test=overridden-value
Profile Activation
使⽤ spring.profiles.active 属性在 application.properties 或 application.yaml ⽂件的 根配置⽂件 来激 相关环境⽂件。
例如，下⾯这样：
test=value
spring.profiles.active=local
#---
<-profile=dev
test=overridden value
不允许的是将 spring.profiles.active 属性与 -profile ⼀起使⽤。例如，以下⽂件将引发异常：
test=value
#---
<-profile=dev
spring.profiles.active=local # will fail
test=overridden value
通过这⼀新限制能使 application.properties 和 l ⽂件更加容易理解。使得 Spring Boot 本⾝更易于管理和维护。Profile Groups
Profile Groups 是 Spring Boot 2.4 中的⼀项新功能，可让您将单个配置⽂件扩展为多个⼦配置⽂件。例如，假设有⼀组复杂的
@Configuration 类，可以使⽤ @Profile 注释有条件地启⽤它们。使⽤ @Profile("proddb") 开启数据库配置，使⽤
@Profile("prodmq") 开启消息配置等等。
使⽤多个配置⽂件可以使我们的代码更易于理解，但是对于部署⽽⾔并不是理想的选择。若⽤户需要同时激活 proddb ， prodmq ，prodmetrics 等。那么 Profile Groups 可让您做到这⼀点。
您可以在 application.properties 或 l ⽂件中定义 up，那么开启 prod 则就相当于激活了此组的全部环境 。例如：
up.prod=proddb,prodmq,prodmetrics
Importing 扩展 Configuration
现在，我们已经解决了配置⽂件处理的基本问题，我们终于能够考虑我们想要提供的新功能。我们使⽤ Spring Boot 2.4 提供的主要功能是⽀持导⼊其他配置。
对于早期版本的 Spring Boot，很难在 application.properties 和 l 之外导⼊其他 properties 或 yaml ⽂件。可以使⽤fig.additional-location 属性但它可以处理的⽂件类型⾮常有限。
在 Spring Boot 2.4 可以直接在 application.properties 或 l ⽂件中使⽤新的 fig.import 属性。例如希望导⼊⼀个 "忽略的 git" 的 developer.properties ⽂件，以便团队中的任何开发⼈员都可以快速更改属性：
application.name=myapp
甚⾄可以将 fig.import 与 -profile 结合起来使⽤。例如，这⾥ prod.properties 仅在 prod 配置⽂件处于激活状态时加载：
<-profile=prod
Import 可以被视为在声明它们的⽂档下⽅插⼊的其他⽂档。它们 遵循与常规多⽂档⽂件相同的⾃上⽽下的顺序：导⼊仅被导⼊⼀次，⽆论声明了多少次。
volume 挂载配置spring到底是干啥的
导⼊定义使⽤与 URL ⼀样语法作为其值。如果您的位置没有前缀，则它被视为常规⽂件或⽂件夹。但是，如果您使⽤ configtree: 前缀，则告诉 Spring Boot，您将期望在该位置使⽤ Kubernetes volume 装载的配置树。
例如，您可以在 application.properties 配置:
如果您有以下装载的内容：
etc/
+- config/    +- my/    |  +- application    +- test
将在 Spring Environment 中拥有 my.application 和 test 属性。 my.application 的值是 /etc/config/my/application 的内容， test 的值是 /etc/config/test 的内容。
根据云平台类型激活
如果只希望 Volume 挂载的配置（或该内容的任何属性）在特 定的云平台上 处于激活状态，可以使⽤ -cloud-platform 属性。它的⼯作⽅式与 -profile 类似，但它使⽤ CloudPlatform 的值，⽽不是配置⽂件名称。
如果我们想要在部署到 Kubernetes 时启⽤上述配置树，我们可以执⾏以下操作：
<-cloud-platform=kubernetes
⽀持其他位置
如果您有兴趣添加其他位置⽀持，请查看 org.t.config 包 ConfigDataLocationResolver 和ConfigDataLoader 的 javadoc。
版本回滚
正如上⽂所描述的，Spring Boot 针对配置⽂件的功能变更是⾮常⼤的。考虑到低版本的兼容性
可以设置 fig.use-legacy-processing=true 属性即可，恢复到之前版本的⽂件处理机制。
如果发现关于此处的问题，则需要切换到旧版处理，请 在 GitHub 上提出问题，官⽅将尝试解决该问题。
总结
官⽅希望新的配置数据处理更加好⽤，并且不会引起太多升级⿇烦。如果您想了解更多有关它们的信息，可以查阅更新的 参考⽂档。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。