Spring Cloud配置服务器环境变量的优先级

在使用spring cloud配置服务器时，我有一个关于环境变量优先级的问题

在我的服务中，我有一个本地属性文件application.yml，其中包含此内容

foo:
  bar: "some"
  buz: "some"
  joe: "some"

该服务还连接到具有配置存储库的配置服务器，该配置存储库包含文件testservice-api.yml（其中testservice-api是该服务的spring应用程序名称）。该文件的内容为：

foo:
  bar: "some-specific"

因此，通过这种设置，运行时的配置将导致以下结果：

{
    "foo.bar": "some-specific",
    "foo.buz": "some",
    "foo.joe": "some"
}

现在我尝试用一个环境变量覆盖foo.bar和foo.joe。

所以我用这个命令启动服务：

FOO_BAR=some-env FOO_JOE=some-env gradle bootRun

根据我在spring-boot文档的这一部分中所读到的内容，环境变量应该优先于配置文件-而且spring-cloud配置文档也没有说明什么不同-所以我希望结果是：

{
    "foo.bar": "some-env",
    "foo.buz": "some",
    "foo.joe": "some-env"
}

但我得到的却是：

{
    "foo.bar": "some-specific",
    "foo.buz": "some",
    "foo.joe": "some-env"
}

因此，只有jar中本地配置文件中的配置才会被环境变量覆盖——配置repo中的属性似乎比环境变量具有优先级。

这是可以解释的吗？或者这是一个bug？这个有什么提示吗？

请在此处找到示例代码：

https://github.com/mduesterhoeft/configserver-test

存储库中的自述文件列出了此处描述的问题，称为用例3

在git-reo中定义以下属性（作为配置服务器的源）[用于给定的配置文件]：spring.cloud.config: overrideSystemProperties: false overrideNone: true

请记住bootsrap.yml中的属性（尤其是overrideSystemProperties和overrideNone）默认情况下会被配置服务器中的属性覆盖

相关内容