内容简介:很多人都说,Spring Boot最大的作用就是简化配置,摆脱原来Spring的配置地狱。确实,相比Spring原来的配置,Spring Boot简直就是天堂,所以说Spring Boot就是一个又大又深的坑,跳进去了就再也出不来(你也不愿意出来),这也是这个系列文章为什么叫入坑指南的原因。 不过,任何应用都不可能摆脱配置,像数据库相关配置、业务自定义配置等就肯定需要进行配置的。所以,在本文主要讲一下Spring Boot的一些配置方式,主要参考官方文档和自己项目中的一些使用方式。Spring Boot默认
开篇语
很多人都说,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
创建多个配置文件如:
spring.profiles.active
多环境配置切换方式
上面说的是如何管理多环境配置,配置文件配置好了,如何在持续集成的流程中进行配置文件的动态切换呢?我接触的项目中,注意是以下几种方式,给大家介绍一下。
方式一:原始方式(手工切换,非常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 容器部署应用的,通过设置容器环境变量指定配置中心的访问地址就可以了。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- Android Gradle进阶配置指南
- Android Studio 代理配置指南
- WiFi 配置 IPv6 指南
- 数据库连接池配置(案例及排查指南)
- 使用SSL配置Nginx反向代理的简单指南
- Spring Boot配置文件application.properties说明指南
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。