您现在的位置是:首页 > 文章详情

SpringBoot入坑指南之二:配置篇

日期:2019-01-29点击:240

开篇语

很多人都说,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_locationclasspath:./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容器部署应用的,通过设置容器环境变量指定配置中心的访问地址就可以了。

原文链接:https://my.oschina.net/centychen/blog/3006976
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章