开篇语

很多人都说，Spring Boot最大的作用就是简化配置，摆脱原来Spring的配置地狱。确实，相比Spring原来的配置，Spring Boot简直就是天堂，所以说Spring Boot就是一个又大又深的坑，跳进去了就再也出不来（你也不愿意出来），这也是这个系列文章为什么叫入坑指南的原因。 不过，任何应用都不可能摆脱配置，像数据库相关配置、业务自定义配置等就肯定需要进行配置的。所以，在本文主要讲一下Spring Boot的一些配置方式，主要参考官方文档和自己项目中的一些使用方式。

Spring Boot的配置文件

默认配置文件

Spring Boot默认的配置文件时application.yml（或application.properties），相对于properties文件，yaml格式层级结构清晰易于阅读和管理，故推荐使用yaml格式进行配置。需注意的是，当相同目录下同时存在application.properties和application.yml文件时，会优先读取properties文件中的配置。

application.properties/application.yml配置文件读取优先级顺序如下： 文件|优先级<br>(值越小优先级越高)|说明 --|--|-- file:./config/application.properties|1|Jar包所处的同级目录的下级config目录 file:./config/application.yml|2|Jar包所处的同级目录的下级config目录 file:./application.properties|3|Jar包所处的同级目录 file:./application.yml|4|Jar包所处的同级目录 classpath:./config/application.properties|5|ClassLoader根目录下级config目录 classpath:./config/application.yml|6|ClassLoader根目录下级config目录 classpath:./application.properties|7|ClassLoader根目录 classpath:./application.yml|8|ClassLoader根目录

上表只是在默认情况下，实际上你可以通过spring.config.location配置修改配置文件读取路径，该配置既可以直接指定读取的配置文件，也可以指定配置文件的目录，如果需要指定目录，配置值必须是斜杠“/”结尾。 比如将配置设置为spring.config.location=classpath:./custom_location/,file:./custom_location，那么读取的优先级顺序会变成：file:./custom_location、classpath:./custom_location。

需注意的是，spring.config.location配置需在环境变量或者命令行参数中进行配置。

其他配置方式

Spring Boot还可以通过环境变量或者命令行参数进行应用配置，这两种配置方式优先级高于配置文件，即： 命令行参数>>环境变量>>application.properties>>application.yml 这两种配置方式在实际应用中有很大的用处，特别是用于多环境配置文件切换，下文会进行介绍。

多环境配置

如何管理多环境配置

软件开发过程中，会涉及到开发、测试、灰度、生产等各部署环境，每个环境所需要的配置肯定会有差异，不同环境的配置文件怎么管理？CI/CD过程如何切换？ Spring Boot框架提供了多环境配置文件管理的解决方式，上文说到，Spring Boot默认的配置文件是application.yml，你可以按application-{profiles}.yml创建多个配置文件如：

• application-dev.yml
• application-test.yml
• application-prod.yml 之后在application.yml主配置文件中通过spring.profiles.active配置参数指定启用的profiles即可。

多环境配置切换方式

上面说的是如何管理多环境配置，配置文件配置好了，如何在持续集成的流程中进行配置文件的动态切换呢？我接触的项目中，注意是以下几种方式，给大家介绍一下。

方式一：原始方式（手工切换，非常Low，不推荐）

• 实现方式 如题，就是构建的时候手动将spring.profiles.active配置给改了，或者保证测试、或生产代码分支下该配置不变。

• 优点

  • 只有一个：简单粗暴。

• 缺点

  • 如果忘记改了或者合并分支的时候被覆盖，那就问题大了。
  • 测试、生产环境保存在源码中，安全性较低。

方式二：使用Maven变量

注意：使用maven变量时，项目的父项目需要是“spring-boot-starter-parent”，否则需要额外增加配置，可参考：https://docs.spring.io/spring-boot/docs/2.1.2.RELEASE/reference/htmlsingle/#howto-automatic-expansion

• 实现方式 (1).在项目pom.xml文件中增加profiles配置，配置参考如下：

<!-- 不同环境查找不同配置文件 --> <profiles> <profile> <id>dev</id> <properties> <profiles.active>dev</profiles.active> <maven.test.skip>true</maven.test.skip> </properties> <activation> <!-- 默认环境变量 --> <activeByDefault>true</activeByDefault> </activation> </profile> <profile> <id>test</id> <properties> <profiles.active>test</profiles.active> <maven.test.skip>true</maven.test.skip> </properties> </profile> <profile> <id>prod</id> <properties> <profiles.active>prod</profiles.active> <maven.test.skip>true</maven.test.skip> </properties> </profile> </profiles> 

(2).修改application.yml中的spring.profiles.active配置，使用maven变量替换。

spring: profiles: active: @profiles.active@ 

(3)..maven构建时通过参数指定替换变量，如下：

mvn clean package -Pprod 

• 优点
  • 构建时指定，只需调整持续集成逻辑即可。
  • 实现简单，符合软件部署逻辑。
• 缺点
  • 测试、生产环境保存在源码中，安全性较低。

方式三：利用配置文件读取优先级（推荐）

• 实现方式 Spring Boot一般来说都是通过构建Jar包进行部署（war包部署请绕路），参考上面介绍的配置文件读取路径优先级顺序，在测试/生产服务器对应的部署路径中放置对应环境的application配置文件，部署的时候直接将Jar部署到对应目录，启动时就会使用外部的配置。

• 优点

  • 测试、生产等环境配置文件无需放到代码中，避免泄漏。
  • 应用构建、部署过程无需处理配置。
  • 测试、生产的配置文件只存在于服务器上面，只有服务器相关运维人员能够查看和修改，安全性较高。

• 缺点

  • 只适合服务器相对固定的场景，对于使用容器分布式弹性部署的场景不适用。
  • 如果应用增加或修改配置，需要到各个服务器进行修改。

方式四：应用启动时指定（推荐）

• 实现方式 在Spring Boot应用启动时，通过命令行参数指定启用的profiles，由于命令行参数优先级高于配置文件，故生效的是命令行中指定的profiles。 参考启动命令如下：

# 启用test profiles java -jar target/spring-boot-examples-properties-1.0-SNAPSHOT.jar --spring.profiles.active=test 

• 优点

  • 无需关注打包过程，只需要在服务启动命令中设置后启动参数即可。
  • 配置文件可以保存在源码中，也可以保存在服务器中（参考上文方式三）。

• 缺点 暂无

本文示例代码

码云：https://gitee.com/centy/spring-boot-examples/tree/master/spring-boot-examples-properties

尾巴

通过Spring Boot可以快速构建一个微服务，那么微服务的服务治理就不得不提Spring Cloud全家桶，Spring Cloud提供各种配置中心解决方案（Spring Cloud Config、Consul、Zookeeper等）。 通过配置中心管理各个微服务的配置，开发、测试环境与生产的配置中心分离，就可以无需关注单个服务的不同环境配置的切换了，是不是很爽？ 但是还有一个问题，每个微服务需要指定配置中心的地址，这个地址还是需要切换不是吗？有没有方法可以不切换这个配置呢？实际不用考虑的那么复杂，有很简单的方式，如果你是通过Docker容器部署应用的，通过设置容器环境变量指定配置中心的访问地址就可以了。