如同世界上任何东西一样，一个服务的配置应当越简单越好。最好是没有配置。然而这毕竟是一种理想状态。一些依赖必须提供，例如一些调用的第三方服务地址，或者自身依赖的数据库。目前比较主流的方式是环境变量和配置文件。
使用配置文件使得运行启动服务的脚本非常简单，并且所有的配置能以类似代码的形态存在，但是却降低了灵活性。而使用环境变量则走向了另一个极端，也就是非常灵活但是启动命令却异常复杂。一些固定的配置更是在任何环境中都会使用到，却要在每一个启动命令上输入。两种方式都会有自身的局限性。都只能针对部分场景。
仔细思考会发现，一般配置可以分为若干类别：
- 所有部署版本均要使用到的(一份)
- 开发和部署来区分的配置(两份，一份开发一份部署)
- 第三方依赖和功能开关(每个环境一份)
第一类配置一般用于业务逻辑配置，相当于项目中的常量。这类配置文件最为稳定，适合使用配置文件。第二类配置可以描述部署与本地环境的区别，一份用于开发一份用于部署。这类配置相对稳定，和第一类的区别就在于他不是所有版本相同的。可以放在配置文件当中，通过环境变量控制使用哪一个。第三类是为最不稳定的配置，每一个环境都需要相应的配置，最适合放在环境变量中。
项目使用这种分类方式进行配置可以最大程度的减少冗余性，并且保持配置文件功能的同时尽量减少开发部署的复杂度。