共计 3108 个字符，预计需要花费 8 分钟才能阅读完成。
起源：https://lepdou.github.io/blog…
引言
我的项目开发中总是有各种各样的配置，对于程序开发老手来说，配置是摆在面前的第一座大山。回忆当年在学校学习经典的“SSH”的时候，一个 web.xml 配置都是异样的艰苦。工作多年的你，对配置真的理解吗？
什么是配置？
首先咱们来看一下配置文件的定义:
“A software file used to configure the initial settings for a computer program.” — From wikipedia
配置起源可能有以下这些:
- 硬编码参数
- 我的项目里的配置文件
- 文件系统上的配置文件
- 网络上的配置文件
- 启动参数（JVM 属性）
- 操作系统参数
上面会具体介绍每一种配置类型的应用场景。
硬编码参数
最常见的就是定义动态变量形式。例如：public static final int PAGE_SIZE = 10;
另外就是通过框架裸露的各种 API 接口设置参数。
长处
- 这种是最简略、老本最低的形式
- 不必额定创立文件
- 代码里能间接能读取
- 离配置应用中央最近的一种形式
毛病
- 代码和配置糅合在一起，不易于保护
- 批改配置必须批改源代码，从新编译、打包、上线
- 同一个框架的配置散落到我的项目各个角度，不利于查找
实用场景
- Hard Code 实用于配置极其简略且简直不会变更
- 为了赋予常量语义
- 配置极少从而创立配置文件老本高
我的项目里配置文件
这种形式是最常见的。规范的 maven 我的项目有一个 resources 目录就是用来搁置各种类型的配置文件，例如：
- web 我的项目的 web.xml
- log 框架的配置
- spring 的 bean 定义的 xml 文件
- mybatis 的 sql 配置文件
- spring boot 的 application.yml application.properties
- 自定义的 properties 文件
另外 maven 我的项目的外围 pom.xml 也算是配置文件。我的项目里应用到的各种各样的框架、中间件基本上都须要配置文件来撑持。框架在运行时，读取配置文件来决定运行时的行为。配置文件门路个别有两种形式：
- 依照框架约定的目录（绝对于 classpath）
- 通知框架配置文件的门路
长处
- 配置和代码拆散
- 集中统一治理配置
- 不依赖我的项目内部资源
毛病
- 跟 Hard Code 一样不能动静批改配置
- 配置文件增生，导致我的项目臃肿
实用场景
- 非常适合框架或者中间件的配置
- 我的项目中自定义业务配置
文件系统上的配置文件
此类配置文件是放在利用运行的机器上。常见的比方携程公司外部机器上都会搁置一个 server.properties 文件。文件内容次要是以后机器的一些信息，比方 env=dev 标示以后机器属于 dev 环境。公司配套提供 framework-fundation 根底 jar 包，用来解析这个文件。
那么利用只有通过 framework-foundation 来获取机器的相干信息。framework-foundation 在这里的作用就是作为机器和利用之间的桥梁。这种形式次要益处是标准运维。另外一种应用比拟多的场景是利用间接读取文件系统上的某个文件。这种形式的益处就是能够动静更新配置，无需从新编译、打包、运行利用。
长处
- 配置和代码拆散
- 可动静批改配置
毛病
- 配置和利用代码不在一个中央（我的项目源码），不易于了解和运行
- 批改配置须要登录机器
- 批改配置文件可能波及权限问题
- 配置文件门路也须要沟通
实用场景
- 不倡议作为利用业务相干的配置，老本高且不易于开发保护
- 实用于运维相干的配置，如后面举的例子
笔者遇到过一个 dal 框架，datasource 配置文件就是放在文件系统上，后果开发人员在上线时，遗记在机器上搁置这个文件导致线上 bug。
网络上的配置文件
常见的包含两种：DB 上的配置表、配置核心。如果公司没有对立的配置核心，那么最简略的动静批改配置的形式莫过于把配置搁置在 DB 上。置信大部分的开发都应用过或者遇到过。
配置核心是最适宜集中化治理配置、动静批改配置的中央。常见的配置核心都会提供治理配置后盾、实时推送配置、分环境治理配置、配置版本治理等。笔者目前就在开发一款开源的配置核心零碎。
长处
- 集中管理配置、全方位治理配置
- 动静批改配置、实时推送、更新配置
- 配置更加灵便，例如能够分环境、集群以及灰度公布等
毛病
- 须要依赖数据库或者配置核心，老本高
实用场景
- 常常须要变更的配置
- 配置值每个环境不统一
- 不心愿配置值随着代码一起公布，例如开源我的项目中的某些配置
启动参数（JVM 属性）
JVM 属性次要是利用运行的 JVM 过程相干的属性，比方 java.class.version、java.class.path 等 Java 相干的参数。在代码里，能够通过 System.getProperty() 获取参数值。另外，能够通过在启动时指定 - D 参数来设置 JVM 属性。最常见的应用场景是用来解决不同环境须要配置不同的参数。例如作为中间件，依赖的内部零碎越少越好，如果不依赖配置核心，那么就能够通过这种形式来实现不同环境配置不同的参数，例如每个环境的数据库连贯串不一样。另外须要提到的是 maven 打包参数。
相比于 - D 运行时参数，maven 打包参数是在编译时设置配置属性，maven 会获取打包参数而后替换掉配置文件里的 placeholder。假如一个可运行的 jar 包，只须要在打包的时候传入参数值，打进去的 jar 包就能够到处运行了，如果不这么做，那么须要每次运行的时候指定参数，老本太高。应用形式则是在 mvn package 时指定 - D 参数。老手很容易混同这两种参数。换个角度看 - D 是命令行参数。
长处
- 以十分小的代价就能够达到运行时指定非凡参数值
毛病
- 启动运行我的项目须要设置启动参数，减少应用老本
实用场景
- 适宜中间件类零碎，不举荐业务零碎应用（业务零碎用配置核心解决此类场景）
- 减少对立运维老本
操作系统参数
操作系统参数个别是只读的，当然也能够设置。例如后面提到的 server.properties 文件里的 env 参数，其实也能够作为零碎参数，然而不倡议这么做。
后记
配置的益处不言而喻，然而咱们在工作中常常会遇到这种状况。拿到一个我的项目，看到乌七八糟的配置无从下手，我的项目中应用的框架、中间件配置格调更不雷同，更头疼的是配置项如果不理解框架的根底上很难了解。
导致的后果就是如果不复制、粘贴配置，手写配置基本上很难写对。验证这种状况最简略的形式就是不复制其它我的项目的配置，手动搭建一个新我的项目。我置信绝大多数的人都难以做到。
全面的说学习一个框架其实是在学习这个框架的 API 和配置参数。如果你十分相熟一个框架的配置，那么你对框架的应用就得心应手了。当然，晓得框架的原理也十分重要。说这么多，只想阐明我的项目的配置真的十分重要，更好的治理、标准配置更加重要。
对于框架、中间件开发者来说，配置应该越少越好，减少一个配置对于使用者应用老本就会大大提高。如果配置很多，那么你的框架基本上就是很难用了。Spring 始终是 Java 界最权威的框架体系，最新的 Spring Boot 框架的配置就非常少，一眼看上去十分舒心。
Spring 当初提倡缩小配置文件，例如 Spring 晚期版本的 xml 配置其实是很繁琐的。新的 Spring 更多的配置搁置在代码中，利用注解以及 API 形式配置。Servlet 最新版本也不须要 web.xml 文件了。
阐明一个情理: 大道至简？
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
