最近一直在研究前公司的架構，發現原公司的架構還是很不錯的，對於生產環境以及測試環境這一點，雖然沒有配置中心，但也是一定程度實現了正式環境以及測試環境的分離。
閒話不多說，現在直接上代碼：
首先需要在pom文件中確定filter和要filter的資源，這是通過在build節點中添加filter和resource來實現的，示例如下：
<build>
<filters>
<filter>${env}.properties</filter>
</filters>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
上述配置表示要對<filter>採用的過濾文件${env}.properties</filter>下的資源進行過濾，如果不寫，默認當前目錄，因爲該目錄下沒有二進制文件，所以沒有excluding。<filtering></filtering>true表示需要過濾，<directory></directory>表示需要過濾的文件，過濾時採用的過濾文件爲${env}.properties文件，其中${env}是一個變量，表示當前使用的環境，這是通過在pom文件中通過profile定義的，如下所示：
<profiles>
<profile>
<id>dev</id>
<properties>
<!-- 測試環境 -->
<env>dev</env>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<profile>
<id>formal</id>
<properties>
<!-- 正式環境 -->
<env>formal</env>
</properties>
</profile>
</profiles>
這裏需要解釋一下activation的意思：
<!--自動觸發profile的條件邏輯。Activation是profile的開啓鑰匙。profile的力量來自於它能夠在某些特定的環境中自動使用某些特定的值；這些環境通過activation元素指定。activation元素並不是激活profile的唯一方式。-->
通俗一點說，如果檢測到匹配的屬性，則激活該該配置項。
這樣在開發時就不用每次指定這個值。在測試和部署上線時分別通過-P傳入當前的profile id，這樣maven就會將env變量設置爲對應的值，從而導致使用不同的filter文件來對resources下的文件進行過濾替換。
具體如下圖
