项目配置文件多环境解决方案

记得在刚入门做软件开发时，经常发生配置文件不正确导致数据出错的问题。现在回想起来那时的做法确实比较simple，本地开发环境，把所有的配置项都预先写在一个文件当中，当需要调试测试环境的问题，就直接把开发环境的配置项注释掉，放开测试环境的配置项。我们暂且就叫配置管理原始阶段。

 随着开发经验的丰富，我们引入了maven、gradle等构建工具，它们有个一个叫profile特性，在打包的时候，（maven 通过 -p ）参数动态的打包环境的配置文件，这样就解决了原始阶段手工改配置文件的问题。我们暂且就叫配置管理第一阶段。这阶段主要的改进点，就是把原始阶段所有环境的配置文件写在一个文件中，改成预先按环境分几个配置文件来保存。例如把jdbc的配置文件分成【jdbc-dev、jdbc-uat、jdbc-prd 】，然后在spring的配置中通过定义一个与maven的profile相同变量属性的占位符来适配。

# maven的配置

<profiles>
<profile>
<id>dev</id>
<properties>
<runtime_env>dev</runtime_env>
<properties>
</profile>
<profile>
<id>uat</id>
<properties>
<runtime_env>uat</runtime_env>
<properties>
</profile>
<profile>
<id>prd</id>
<properties>
<runtime_env>prd</runtime_env>
<properties>
</profile>
</profiles>

# spring的配置项

<bean id="propertyConfig" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:jdbc-${runtime_env}.properties</value>
</list>
</property>
</bean>

配置ok后，在maven打包的时候带上-P参数,动态的打包配置文件，动态的替换spring的占位符。

开发包 mvn clean install -P dev

测试包 mvn clean install -P uat

线上包 mvn clean install -P prd

现在我们在回过头看下，第一阶段还有那些问题没有解决，首先我认为没解决的是，所有环境的配置全部暴露给所有的人了，存在很大的安全隐患。开发可以很方便的修改各环境的配置；线上环境的数据没有安全保障，数据库的账号密码都暴露了呀。当我正在与maven度着蜜月的时候，我的领导对我说，你这种方式有上述的种种问题时。我只得重新寻找新的解决方案。经过团队的思考，我们找到了两种解决方案，

方案一：配置文件服务化，项目在启动的时候从配置服务中心获取，当时我还找到了百度一个disconf开源的配置管理中心，考虑的复杂性就放弃了。

方案二：抛弃了maven的思想束缚，找到了一个全新的解决方案。我们让配置管理回归原始阶段，只不过这个时候，各环境的配置不在是全部在项目工程中配置好，是由各个环境自己管理。这阶段maven只做一个发布包，在把包部署到服务器上的时候，用脚本把配置文件替换成当前环境的配置文件。这样前面所说的安全问题似乎就解决了。我们暂且就叫配置管理第二阶段。

在我抛弃方案一后，时隔不久我融入到一个新的团队时，找到了方案一缺点（依赖maven的profile来标识当前环境）的解决方案。我现在的团队的做法也是把配置文件服务化，各环境的项目启动时，统一从服务器获取。当然我们现在是自研了一套配置系统，相对来说比计较simple，没有disconf强大。其实这个解决方案说来真是简单，就是通过dns域名解析的思想。如果改写过Windows的host文件，都知道如果把百度域名对应的主机该成csdn的ip，那么你就永远访问不了真正的百度了。我们暂且就叫配置管理第三阶段。

最后我总结下，希望对您有点小启发，寻找跟优秀的项目配置文件解决方案。原始阶段肯定是要退出历史舞台的。第一阶段适合没有运维同学的团队，团队规模非常小，且公司的数据安全按管理是可控。第二阶段适合数据要求安全高，但是团队的技术实力不是非常强的情况。第三阶段那就是团队规模大实力也非常强了。