SpringBoot 工程中多环境下 application.properties 的维护问题
背景
我们知道 SpringBoot 有一个全局的配置文件 application.properties, 可以把工程里用到的占位符,第三方库的配置项如 dubbo 端口,工程的 db 配置等统一放在这个配置文件里,方便对工程里所有配置项的统一管理。我们知道,在企业开发中,我们一般会先在测试环境中开发,在预发环境环境,最后上生产环境部署,也就意味着一个工程需要分别部署在测试,预发,生产环境上,而这三种环境的一些配置项(如测试环境和生产环境的 db 配置)很多时候都是不一样的,所以我们通常需要为每一个环境准备一份 application.properties, 接下来就引申出一个问题
如何维护多环境下的 application.properties 文件
方法一:在工程里维护多个环境的 application.properties ,部署的时候通过 spring.profiles.active 来指定工程应用哪个环境的 application.properties 文件,比如预发配置文件我们用 application-pre.properties, 线上配置文件我们用 application-prod.properties,当想在预发部署工程时,我们在部署脚本里用 java -jar xxxxx.jar --spring.profiles.active=pre 这样的方式来指定工程启动使用预发的 application-pre.properties 配置文件
以上这种方式虽然可以满足要求,但有一个比较棘手的问题:在部署脚本里需要先根据 ip 等来判定当前环境是预发还是线上
if [ "$flag" == "预发" ]; then
java -jar xxxxx.jar --spring.profiles.active=pre
else
java -jar xxxxx.jar --spring.profiles.active=prod
如上所示,部署脚本需要根据一个标志来判断是预发还是线上,以便指定相应的 spring.profiles.active,这个标志的维护就是一个成本 ,每个环境的部署机器都要能正确设置这个 flag 的值,维护的成本很大
方法二:也就是我们工程当前采用的方式除了用 spring.profiles.active 来指定到底用工程中哪种环境的 application.properties,我们还可以用
java -jar xxxxx.jar --spring.config.location=/opt/conf/application.properties
这种指定配置文件位置的方式来使用指定的 application.properties 文件
使用这种方式就解决了方法一的问题,只要在工程里维护多个环境下的 application.properties 文件(如下)
当 gradle build 通过之后,在每个环境的机器部署前都会把工程里相应环境对应的 application.properties 统一 copy 到机器的固定目录下,如 /opt/conf
下, 然后在启动的时候,通过在启动命令里指定 spring.config.location=/opt/conf/application.properties 的方式来指定 jar 包使用此环境下的 application.properties 文件即可
问题初现:多环境下的 application.properties 如何维护
在上图我们可以看到,由于我们有多个预发及线上环境,不得不为这些环境分别指定一个 application.properties,这样导致的后果就是如果我需要在一个 application.properties 文件里添加一个配置,不得不在其他环境下的 application.properties 文件里也 手动 添加此配置,这样的工作不仅烦琐,而且很容易出错, 之前就有发生过同事只在预发的 application.properties 加配置而忘记在线上加导致的线上部署失败的问题
如何解决
实际上预发和线上的配置大部分都是一样的,只有少部分是不一样的,所以我们想是否能将大部分一样的配置都统一放到一个文件(姑且叫 application-common.properties)里维护,这样如果要配置一个属性,只需要统一在这一个文件里配置即可,极大地降低了维护成本
那如何解决不同环境下某些配置不同的问题呢,比如在预发和线上我们对 MQ 的 topic 的命名有一个统一的规范,预发我们统一叫 topic-pre-xxx, 线上我们统一叫 topic-prod-xxx。
针对这种不同环境下配置不同的问题,我们可以单独为预发和线上建一个文件,比如预发叫 application-pre.properties, 线上叫 application-prod.properties,把各个环境独有的配置都分别放在这两个文件里即可
好了,现在我们有了三个文件,公用配置文件:application-common.properties, 以及两个环境配置文件:application-pre.properties, application-prod.properties,那怎么生成如下最终各个环境的 application.properties 文件呢
很明显应该把公用配置文件与各个环境的配置文件合并
合并工作的思路很简单,我们以生成预发环境的 application.properties为例
具体步骤如下:
- 遍历 application-common.properties 文件中的每一行,然后取出每一行的 key,value(以等号分割),将其存储到 map中
- 遍历 application-pre.properties 的每一行,然后取出每一行的 key,value(以等号分割),取出的同时拿 key 到上一步的 map去查找, 如果存在则覆盖,如果不存在则在上一步的 map 中新增 key, value
- 遍历步骤 2 最终生成的 map,将每个键值对以key=value的形式写入 pre 中的 applicaton.properties 文件
还有一个问题,这个合并工作写在哪里呢,答案是 gradle 的 task 里,我们的工程是基于 gradle 构建的,一般我们是通过 gradle build 来编译打包工程的,我们可以在 gradle build 打包之后再执行这个 task ,假设这个 task 名为 regeneratePropertyFile ,则可写成如下形式
build.finalize(regeneratePropertyFile)
这样在 build 构建完之后就会自动执行合并文件的工作了。最后我们来看看最终的合并生成各个环境 application.properties 的 task
task regeneratePropertyFile(type:Exec){
["pre", "prod"].each { env ->
def envMap = [:]
// 取出公共文件的键值对
def destFileName = "src/main/resources/META-INF/spring/properties/application-common.properties"
def destFile = file(destFileName)
String content = destFile.text
def commonLines = destFile.readLines()
for (line in commonLines) {
Integer equalSignLoc = line.indexOf("=")
if (equalSignLoc == -1) {
continue
}
String key = line.substring(0, equalSignLoc)
String value = line.substring(equalSignLoc + 1)
envMap.put(key, value)
}
// 取出环境配置文件 application.properties 的键值对,写入envMap中
File envFile = file("src/main/resources/META-INF/spring/properties/application-${env}.properties")
def envLines = envFile.readLines()
for (line in envLines) {
Integer equalSignLoc = line.indexOf("=")
if (equalSignLoc == -1) {
continue
}
String key = line.substring(0, equalSignLoc)
String value = line.substring(equalSignLoc + 1)
envMap.put(key, value)
}
content = ""
envMap.each { key, val ->
content = "${content}\n"
}
// 写入最终环境的 application.properties 文件
destFile = file("${rootProject.projectDir}/bb_conf/${env}/application.properties")
destFile.text = content
}
}
搞定!妈妈再也不用担心我在多环境下维护多个 application.properties 的噩梦了
本文转载自公众号:码海