开篇语
很多人都说,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配置文件读取优先级顺序如下:
文件 | 优先级 (值越小优先级越高) |
说明 |
---|---|---|
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容器部署应用的,通过设置容器环境变量指定配置中心的访问地址就可以了。