阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 lepdou.github.io/blogs/config/config.html 「lepdou」欢迎转载，保留摘要，谢谢！

• 引言
• 什么是配置？
• 硬编码参数
• 项目里配置文件
• 文件系统上的配置文件
• 网络上的配置文件
• 启动参数（JVM属性）
• 操作系统参数
• 后记

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

引言

项目开发中总是有各种各样的配置，对于程序开发新手来说，配置是摆在面前的第一座大山。回想当年在学校学习经典的“SSH”的时候，一个web.xml配置都是异常的艰辛。工作多年的你，对配置真的了解吗？

什么是配置？

首先我们来看一下配置文件的定义:

“A software file used to configure the initial settings for a computer program.” -- From wikipedia

配置来源可能有以下这些:

1. 硬编码参数
2. 项目里的配置文件
3. 文件系统上的配置文件
4. 网络上的配置文件
5. 启动参数（JVM属性）
6. 操作系统参数

下面会详细介绍每一种配置类型的使用场景。

硬编码参数

最常见的就是定义静态变量方式。例如：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文件了。

说明一个道理: 大道至简？