代码里的resource信息有很多，代码里写死某一个环境的配置的话，有以下若干问题。
1. dev，不同的beta上，使用的resource信息不同。
2. 代码没有发布到对应的环境上，需要去机器上需要手动修改。不锁住配置文件，则每次发布都需要手动修改；若锁住配置文件，则代码更新了配置文件，则机器上还是老的配置文件。把测试的环境写到代码里，容易引起配置不稳定，上线前忘了改过来可能造成问题。
3. 测试中有时日志中没有打出来是使用的是哪个环境配置，发现环境不对时，查起来费时又费劲。
4. 环境交付其他团队使用时，出问题还需要支出人力配合定位问题。
为了解决以上问题，我们可以做以下的事情。
一、profile
当resource配置信息内容根据环境种类的不同而不同时，如dev和beta使用不同的sql数据库连接配置等，使用profile来针对每个环境配置一套resource。pmo中加入：
dev hello.dev dev ${profiles.dir}/dev hello.beta hello.beta beta ${profiles.dir}/beta
指定dev和beta分别使用的resource目录。我们在profiles.dir里准备好对应的resource配置即可。发布时，使用maven命令激活相应的环境即可：mvn -P beta 即使用了beta的profile。
二、filter
有时，同一种环境，只是域名不同，可以使用filter来进行变量替换。如，环境A1上，域名应是xxxA1.beta.com; 环境A2上，域名应是xxxA2.beta.com。pmo上配置：
beta hello.beta beta src/main/filters/beta.properties ${profiles.dir}/beta true **/*.properties **/*.config **/*.xml
配置里说，${profiles.dir}/beta里符合条件的文件，需要被filter里配置的文件里的参数进行替换。filter配置里的文件怎么写呢？
all.use.A.domain=xxxA1.beta.comall.use.B.domain=xxxB1.beta.com
看到filter文件里，配置了A服务对应的域名是xxxA1.beta.com。就是说，resource文件里，遇到${all.use.A.domain}这个变量时，即替换为xxxA1.beta.com。
以上是默认的配置，在编译的时候，使用命令：mvn -Pbeta clean package -Dall.use.A.domain=xxxA2.beta.com，则在编译的时候，会将xxxA2.beta.com这个内容替换到resource里${all.use.A.domain}的变量处。
注意与profile下配置文件里的变量的区别。在filter文件里的变量，在编译时，会替换掉原文件中的值。而在profile配置文件中定义的变量，不会替换代码里的变量占用号，发布机器上，仍是变量符号。
比如，resources文件spring-dubbo-consumer.xml里，配置文件内容为：
其中，${dubbo.zk}这个变量内容定义在profiles下的文件中，内容为dubbo.zk=l-zk.beta.com:8888。代码发布到测试上后，查看spring-dubbo-consumer.xml，内容不变。变量替换是在服务执行时完成的。