一般我们会将SpringBoot应用需要的配置内容放在项目工程中,然后通过spring.profiles.active或是通过Maven来实现多环境的支持.但是,当团队逐渐壮大,分工越来越细之后,往往不需要让开发人员知道测试或生产环境的细节,而是希望由每个环境各自的负责人(QA或运维)来集中维护这些信息,那么如果还是以则海洋的方式存储配置内容,对于不同环境配置的修改就不得不去获取工程内容来修改这些配置内容,当应用非常多的时候就变得非常不方便.同时,配置内容对开发人员都可见,这本身也是一种安全隐患.对此,出现了很多将配置内容外部化的框架和工具,Spring Cloud Config就是其中之一.为了能够更合理的重写各个属性的值,SpringBoot使用下面的顺序来加载配置:

1.在命令行中传入的参数;

2.SPRING_APPLICATION_JSON 中的属性。SPRING_APPLICATION_JSON 是以JSON 格式配置在系统环境变量中的内容；

3.java:comp/env 中的 JNDI 属性;

4.java 的系统属性，可以通过System.getProperties()获得的内容;

5.操作系统的环境变量。

6.通过random.*配置的随机属性；

7.位于当前应用jar包之外，针对不同{profile}环境的配置文件内容，例如 applicaiton-{profile}.properties 或是 yaml 定义的配置文件；

8.位于当前应用jar包之内，针对不同{profile}环境的配置文件内容，例如 applicaiton-{profile}.properites 或是 yaml 定义的配置文件；

9.位于当前应用jar包之外的 application.properties 和yaml配置内容；

10.位于当前应用jar包之内的 application.properties 和yaml配置内容；

11.在@Configration注解修改的类中，通过@PropertySource注解定义的属性；

12.应用默认属性，使用SpringApplication.setDefaultProperties定义的内容；

优先级按照上面的顺序由高到低，数字越小优先级越高。

可以看到，第7项到第9项都是从应用jar包之外读取配置文件，所以，实现外部化配置的原理就是从此切入，为其指定外部配置文件的加载位置来取代jar包之内的配置内容。通过这样的实现，我们的工程在配置中就变得非常干净，只需在本地放置开发需要的配置即可，而不需要其他环境的配置，由其对应环境的负责人去维护即可。

 

版权声明：本文为jun1019原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/jun1019/p/10893661.html