使用Spring boot 的profile功能实现多环境配置自动切换

浅沫记忆

这篇文章主要介绍了使用Spring boot 的profile功能实现多环境配置自动切换的相关知识，非常不错，具有一定的参考借鉴价值 ,需要的朋友可以参考下
通常服务端应用开发需要经过以下几个流程：
开发 -> 测试 -> rc验证 -> 上线
这就涉及到四个不同的环境，开发环境、测试环境、rc环境以及生产环境，为了避免不同环境之间相互干扰，通常需要独立部署数据库、缓存服务器等，那么应用配置也要做相应的调整。
为了解决不同环境配置切换问题，很多人的做法是：把配置文件根据不同的环境，放到不同的目录或文件中，打包时通过gradle或maven，通过命令行参数指定要打哪个环境的包。这样就可以针对不同的环境生成不同的包。但这样的做法有以下几个问题：

• gradle或maven打包脚本文件需要重复编写“选择文件”打包的逻辑，增加很多重复劳动的成功；
  
• 在jenkins等集成环境中，需要针对每个应用，不同的环境做相应的设置；
  
• 需要管理不同环境的包，带来的成本；
  
• 部署时，需要注意包与运行环境是否一致；
  
• 如果运行在docker中时，因为包不同所以要针对不同的环境，构建相应的镜像。
  

这时也许有人会说，把配置都从包里剥离出来，放到配置中心就可以了，但是不同环境对应的配置中心地址也是不一样的。
spring中的profile 是什么?
spring中的profile功能其实早在spring 3.1的版本就已经出来，它可以理解为我们在spring容器中所定义的bean的逻辑组名称，只有当这些profile被激活的时候，才会将profile中所对应的bean注册到spring容器中。
举个更具体的例子，我们以前所定义的bean，当spring容器一启动的时候，就会一股脑的全部加载这些信息完成对bean的创建；而使用了profile之后，它会将bean的定义进行更细粒度的划分，将这些定义的bean划分为几个不同的组，当spring容器加载配置信息的时候，首先查找激活的profile，然后只会去加载被激活的组中所定义的bean信息，而不被激活的profile中所定义的bean定义信息是不会加载用于创建bean的。
为了使用不同的环境，我们首先对不同的环境，定义相应的profile名称。
比如，开发环境的profile为:dev；测试环境的profile为：test；rc环境的profile为：rc；生产环境的profile为：prod。
下面举个dubbo不同环境下，使用不同配置的方法：


上面例子中，当激活相应的profile时，相应的配置文件才会导入。
比如：profile为dev时，导入dubbo-dev.properties。
注意：所有spring xml schema的版本必须是4.0以上，比如：http://www.springframework.org/schema/util/spring-util-4.3.xsd。spring 默认profile为default， 在没有指定profile的，会被默认为default。
如果我们使用配置中心的话，上面的配置还可以更简单。等配置中心投产后我们再讨论。
spring boot中使用profile切换配置
spring boot中默认加载的配置文件是：application.properties或application.yml。当激活profile后（后面我们讨论如何激活profile）,可以通过profile自动选择加载的application-{profile}.properties或application-{profile}.yml格式的配置文件。
比如：profile为dev时，会加载application.properties或application.yml外，还会加载application-dev.properties或application-dev.yml配置。
另外如果引入spring cloud 时，也会加载启动配置bootstrap.properties或bootstrap.yml以及bootstrap-{profile}.properties 或 bootstrap-{profile}.yml。
所以把各个环境公共的配置写在application.properties或application.yml中。把不同环境的配置写在application-{profile}.properties或application-{profile}.yml中。
@profile注解的使用
使用java进行配置时，可以通过@profile注解，实现不同环境使用配置策略。比如swagger现在使用很普遍了，但是它存在一定的安全问题，如果生产环境中也暴露swagger的话，风险还是比较大的，建议只在开发环境和测试环境启用，配置例子如下：


将上面的代码保存到logback-spring.xml文件中，而不是logback.xml中。
logback中profile的使用
在开发环境或测试环境中，为了方便排查问题，我们会使用debug甚至trace级别的日志，而在生产环境中，避免日志增长过快，尽量只是输出error级别的日志。这就需要日志配置也要能根据不同的环境，使用不同的配置策略。
spring boot中的logback就可以满足这样的需求，例子如下：


将上面的代码保存到logback-spring.xml文件中，而不是logback.xml中。
spring boot 激活 profile的几种方式
在配置文件中直接指定
spring.profiles.active=test
这种方式非常不灵活，在实际开发部不太会使用到
使用占位符
在打包时替换，以mavne为例：
首先在配置文件中增加：
spring.profiles.active=@package.target@
在pom.xml中增加不同环境打包的配置：


执行打包命令：
mvn package -ptest
缺点：每次打包都要指定profile
jvm参数方式
java命令行指定：
java -jar app.jar --spring.profiles.active=dev
tomcat 中 catalina.bat（.sh中不用“set”） 添加java_ops。通过设置active选择不同配置文件：
set java_opts="-dspring.profiles.active=test"
eclipse 中启动tomcat。项目右键 run as –> run configuration–>arguments–> vm arguments中添加。
-dspring.profiles.active="dev"
在微服务的时代，会不会觉得有点麻烦呢？
web.xml方式
标注方式（junit单元测试非常实用）
@activeprofiles({"dev"})
env方式（建议使用此方式）
设置系统环境变量：spring_profiles_active（注意：是大写）
比如mac开发环境中设置环境变量的方法：
vi ~/.bash_profile
在~/.bash_profile中增加如下内容：
export spring_profiles_active=dev
总结
上面关于profile的东西，基本能满足工作的需要了。使用profile后，可以减化因不同环境配置差异，而带来的配置管理以及打包工作。
尽量使用环境变量来激活profile，如果是可执行的包，也可以使用java命令行指定，其它方式不建议使用。
使用profile后，使得应用能更容易接入配置中心，以及使用docker容器技术，所以非常有意义。
原文链接：http://www.cnblogs.com/heishao/p/10008436.html