企业级SpringBoot应用多个子项目配置文件规划、多环境支持（二）

上面有两段profile，分别代表开发环境和生产环境，核心以id为准，properties标签里面包含不同环境的参数值。

激活 profile 配置

用户可以在 mvn 命令行中添加参数“-P”，指定要激活的 profile 的 id。如果一次要激活多个 profile，可以用逗号分开一起激活。例如：

1.  `mvn clean install -Pdev`

如果希望某个 profile 默认一直处于激活状态，可以在 profile 中配置 activation 元素，指定某个 profile 为默认激活状态，样例配置代码如下：

1.  ``

2.  `true`

3.  ``

那我们yml的配置文件中，如何引用到pom里面配置profile的参数呢？那就是利用@@标记。我们可以在rb-common-config子项目的配置文件中引用pom文件中profile参数值，如下

在maven进行构建时，会把@XXX@替换为相应的参数值。这样就起到了通过maven构建达到区分不同的环境。

这种方案最大的好处就是，我们只需要建一个配置文件，不需要为每个环境新建一个配置文件了，看上去还比较清晰。

其他引用项目rb-user-server如何引用rb-common-config配置的参数呢？其实比较简单就是${}方式，如图

获取配置参数流程

我们总结一下上面的整个获取参数的流程

遗留问题二

还有一个问题就是安全性问题，我们不可能把生产环境的一些重要的参数暴露给开发人员，生产环境一般都是运维进行管理的，那如何配置生产环境呢？

一般我们配置的方式就是外部化配置，什么意思呢？继续往下看。

采用springboot项目，默认是把配置文件和lib依赖都打到了一个jar中，我们在运行的时候直接采用

1.  `java -jar xxx.jar`

这种方式简化了jar包的启动，但是也有不好的地方。

第一：jar包比较大，这是因为这个jar包含了第三方依赖的jar包，所以很大，给运维带来一些麻烦，这个还不是太重要。

上面的问题还不是太重要，下面的问题就比较致命了。

第二：配置文件也打进了jar包中，不方便我们进行查看配置，而且不能够修改配置，这个也太难受了，要修改配置，需要重新打包。

那怎么处理呢？

分离lib和resources

就是利用maven插件把springboot的jar里面的lib和resources文件分离出来，里面涉及到

maven-jar-plugin spring-boot-maven-plugin maven-dependency-plugin maven-resources-plugin

各自插件的使用，这里就不介绍了，直接上配置。

spring-boot-maven-plugin 排除启动jar包中依赖的jar包

maven-jar-plugin 自定义maven jar打包内容

maven-dependency-plugin 复制项目的依赖包到指定目录

分离lib中，需要把config子项目中的配置文件解压里面，也一起放到当前项目的config中。

maven-resources-plugin复制配置文件

通过上面的配置，我们就分离出了lib和resources文件，用maven构建。

这样我们达到了把config配置文件分离了出来。

我们把配置文件分离出来了就好办了，在生产环境的时候，真实的配置文件在运维手上，运维会替换掉maven构建出来的config配置文件。

这样就很好的保护了生产环境的参数值。

备注：如果配置文件包含其他的，就需要在启动的时候 加上–spring.config.location；通过此属性指定配置

外部配置文件绝对目录,如果是目录需要/结尾，也可以直接指定文件。

如果指定的是目录,spring则会读取目录中的所有配置文件。

总结

介绍到这里我们已经做到了配置文件外部化了，大型项目在配置规划时，会引入配置中心这个概念（这个之前老顾已经介绍过了），不需要引入子项目config，直接连接配置中心即可。

还有在企业级应用中，还要**结合持续化集成方案，自动打包、部署。**这些就不是这篇文章介绍的内容了，老顾下次再介绍。

onfig，直接连接配置中心即可。

还有在企业级应用中，还要**结合持续化集成方案，自动打包、部署。**这些就不是这篇文章介绍的内容了，老顾下次再介绍。

[外链图片转存中…(img-2tT1nnUX-1739160698814)]