作者 | antonybi
导读
配置都是天天在用，偶尔加个配置都是沿着前人的规则照着写。但是，你是否有想过有哪些配置的方法，如何配置才是合理的？本文带你理一理配置的思路，文末还有作者的一个推荐方案可供参考。
1. 配置文件的类型
首先，我们明确一下什么是配置。
配置的定义：程序启动所需要从外部加载的参数。
那么，业务上的参数、三方类库的配置、甚至JVM的启动参数，这些都算是配置。
我们通常有以下三种方式编写配置：
启动脚本中给参数变量赋值
配置文件中填写参数
从配置中心中加载参数
以上三类从上至下所实现的能力会越来越复杂，配置文件可以实现分环境加载，配置中心可以实现统一在线热修改。
然而，他们并不是可以简单的替代关系，本文就是探讨一下到底如何合理的进行选择。
2. 配置的各种归类
配置混乱性的源头就在于有很多视角可以用来进行归类，所以这里我们罗列一些视角，进一步认清配置的使用场景。
2.1 基于加载时机的分类
启动配置：即程序启动时所必要的参数，必须放在工程本地文件中，启动时会自动加载
运行配置：系统运行过程中，程序中设定变量所需的对应参数值
2.2 基于操作角色的分类
研发配置：程序启动必要的配置
运维配置：根据运行环境相应的配置
运营配置：根据运营策略所需设定的参数
2.3 基于运行环境的分类
开发配置
测试配置
预发布配置
灰度配置
生产配置
2.4 基于打包发布策略的分类
直接打入发布包
根据对应条件，决定特定文件加入或排除到发布包
通过独立发布通道上线（如：配置中心）
3. 推荐的解决方案
实际工程中，我们需要的是一套统一、可执行的标准，所以要考虑如何把以上各种维度的分类归纳成一种。
其实，这比较难有一个完美的解决方案，只能综合利弊给出一个相对合理、可行的解决办法。
因此，我归纳了一下比较看重的几条配置原则：
秉承
DRY原则
，尽可能减少重复配置。对于不同工程，相同的配置会抽象出来；对于同一工程不同环境，以一套配置为基础，采用继承的方式覆盖。测试环境的包应该与线上是
对等
的，应该测试包是可以直接拿到生产环境运行的。
（注：内存大小和日志打印不同，这是由于考虑到这些配置由研发维护，所以还是放在项目中，打包时替换）特定场景既要允许为方便调试、测试做特殊配置或处理，但是必须有
可靠
的方式确保发布到对应的环境不会出错。
基于以上原则，我作出了以下的推荐方案：
注：环境配置，我们联合运维部门做了一个解决方案，直接将通用的环境配置发布到项目所在的机器上，在启动脚本时进行依赖。欲了解详情，可参考：
http://wiki.fenqile.com/pages/viewpage.action?pageId=37269276
end
