软件开发中什么是配置文件（谈谈开发过程中的配置文件）

软件开发中什么是配置文件（谈谈开发过程中的配置文件）问题一：如何传入这个参数带来了一些新的工作量，尽管spring提供了各种各样的方式设置这个参数，比如：设置在操作系统环境变量里、设置在tomcat的jvm参数等，但是这些方法都需要在程序的目标主机上做些操作，尽管这工作量并不大，但是程序不再是随处迁移的，必须要在相应的主机上进行设置才行。上述spring.profile.active操作方式解决了不少的问题，但是这还是遗留了一些问题：2、日志打印的位置不一样。在本地调试时，我的日志打印到一个目录下，但是在测试环境的主机上，我希望日志打印到另外一个目录下在程序启动时jvm参数传入-Dspring.profile.active=test打包工具和占位符

在应用程序开发中，配置文件是一个重要但反而总是被忽略掉的问题，因为它的解决方案很简单，而且在项目中往往被架构师一次性就写好了，其他的开发人员只是用就可以了，根本不用关心。但是初学者在从头搭建项目脚手架时，往往被这貌似简单的问题绊住手脚，浪费时间。今天花点时间说下我所理解的配置化

单独说配置文件其实非常简单，无非就是把一些程序中会用到的参数放置到文本文件中，方便之后修改，但是往往这些配置项是程序的关键参数，比如数据库连接地址、接口地址，连接池定义、程序的logo等。这些参数往往都与环境相关，在本地开发时、测试环境、灰度环境、生产环境都不一样，于是需要根据不同的环境用不同的配置文件，这就是我们的需求的来源

随便列举几种应用场景：

1、中间件地址不同。我们的应用都依赖于一个队列集群，不同环境下的队列集群地址不一样。

2、日志打印的位置不一样。在本地调试时，我的日志打印到一个目录下，但是在测试环境的主机上，我希望日志打印到另外一个目录下

在程序启动时jvm参数传入-Dspring.profile.active=test

打包工具和占位符

上述spring.profile.active操作方式解决了不少的问题，但是这还是遗留了一些问题：

问题一：如何传入这个参数带来了一些新的工作量，尽管spring提供了各种各样的方式设置这个参数，比如：设置在操作系统环境变量里、设置在tomcat的jvm参数等，但是这些方法都需要在程序的目标主机上做些操作，尽管这工作量并不大，但是程序不再是随处迁移的，必须要在相应的主机上进行设置才行。

问题二：在一些并不是spring团队出品或者没有遵循spring.profile.active设计的一些软件上时，这种方式并不好用的。当然还是可以通过一些修改，把配置迁移到spring中以遵循这个设计，但是成本还是有点高。

问题三：分布式应用越来越流行，相同的应用越来越多，每一份配置文件都要在程序中放一份，当修改了一个配置项时，所有的相关程序都要重新部署打包。

针对问题一和二，工程师们想出了另外的一种解决思路，就是利用maven或者gradle等打包工具，把环境参数的定义放在打包部署的环节，在编译打包的时候，传入相应的环境参数，来决定将什么样的配置项打包部署到程序包中去，这样就不需要在运行时做处理，而且也不依赖spring.profile.active设计。

以gradle下spring boot为例，配置文件通常是放置到src/main/resources中的，比如：

开发环境下

bootstrap.properties定义了队列集群的地址：

log4j2.xml定义了日志文件的路径及名称：

测试环境下

bootstrap.properties定义了队列集群的地址：

将log4j2.xml中的内容替换为：

再声明一个新的配置文件config.groovy

看明白了吗，我们的目标就是将config.groovy中的内容根据不同的环境（dev or test），替换不同的配置项到配置文件中去，如何做到这一点呢，利用gradle的一个内置任务processResources

修改build.gradle文件（gradle的打包配置文件，同maven的pom文件，不懂得去百度）

定义好了的话，当你使用gradle bootRun -DprofileMode=test的时候，程序中配置文件的@@占位符最终都会被替换成config.groovy的test下的内容。

当然，不使用占位符的话，使用不同的文件夹也可以作区分比如test文件都放到test文件夹下，在打包命令gradle bootRun -DprofileMode=test时，使用test文件夹的内容替换src/main/resources的内容，但是我认为这种方式处理起来还是不如占位符更加清晰明了。