一. 配置文件的作用

配置文件在整个项目当中, 都是非常重要的, 所有的重要数据都配置在这个文件里, 例如

• 连接数据库的信息( 用户名, 密码 )
• 项目端口号
• 定位问题的日志和异常日志
• 三方系统的调用秘钥等信息

如果没有这个配置文件, 数据库连不上, Spring Boot 项目无法连接和操作数据库, 日志也无法持久化存储. 因此配置文件的作用是非常大的.

二. 两种配置文件格式

1. properties 后缀配置文件

properties 配置文件是早期的配置文件格式, 也是创建 Spring Boot 项目默认的的配置文件

2. properties 的用法

properties 的用法是非常简单的, 以键值的形式存在, 不一样的时, 和平常的键值对之间不再是 " : " 这个冒号连接, 而是用的 " = " 去连接, 并且语句后面是不需要用 " ; " 来结尾的

上面就是一个简单的在 properties 配置文件中去连接数据库的基本操作, 它的 key 和平时 Java 语法中通过点引用去获取是一样的. 语法用起来是很方便的. 除了连接数据库, 还可以去设置一些其他的信息, 甚至可以是自定义的信息, 只要符合语法即可. 想要获得更多的配置文件中有哪些信息可以配置, 可以去官网查看  properties 还有那些系统配置信息 ( 点击链接即可跳转 )

在配置文件中, 都是用 " # " 符号来作为注释的符号

上面还有一个问题就是, 如果大家是第一次创建这个 Spring Boot 文件, 那么在配置文件下进行中文注释的时候, 中文是会在下次打开项目时乱码的. 因此需要更改项目的字符集. 当配置完以后, 删掉原本的 application.properties 文件, 在创建一个新的 application.properties 文件, 此时就可以解决中文注释乱码了.

2 .yml 后缀配置文件

2.1 yml( yaml ) 的用法

yml 是树形的配置文件, 它和 properties 一样, 都是使用的键值对的形式, 但此处是 " key : value " 的形式, 不是 properties 中的 " key=value" 的形式, 并且 yml 中键值对的形式里, value 在冒号后面还有一个空格, 这是不能省略的 !!!

知道 yml 的语法后, 用 yml 来写一个连接数据库的操作

通过连接数据库的操作可以看到, yml 是一种树的形式, 例如上面, spring 中有个数据源, 数据源里有 url 和 username 以及 password 可以设置, 并且不同层级之间是有 Tab 空格距离的

3. 两种配置文件的优缺点

3.1 properties 的优缺点

优点 :

• 易于使用: properties 配置文件是一种纯文本文件, 使用简单, 易于读和编辑
• 快速调整配置 : 在需要修改是, 只需要打开配置文件修改其中的键值对即可. 修改以后不需要重新编译代码就能生效, 方便快捷
• 轻量级 : properties 配置文件不需要复杂的语法和结构, 而且文件本身占用小, 可以轻松地在各个项目之间分享和复制

缺点 :

• 语法冗余 : 在配置文件里, 写的都是一些非常重要的信息, 因此会精简一点, 而properties 的语法就很冗余了, 每次都需要去写层级
• 缺乏层次结构 : 可以看到 properties 特性上只支持一级 key-value 的方式, 如果需要表达键值对之间的嵌套款系, 就需要采用一些特定的格式, 例如 " **. **" 点 或者 " _ " 来分隔 key
• 可读性差 : 由于没有明显的层次结构, 当遇到大量配置文件时, 配置文件就会变得混乱, 维护起来不方便

3.2 yml 的优缺点

优点 :

• 可读性好 : yml 采用类似于 Python 的缩进方式来表达层次结构, 使得配置文件有更好的可读性和可维护性. 这样的语法风格更加易于开发者理解和修改配置文件
• 易于使用 : 相比于 XML 和 JSON 等格式, yml 的语法更加的简洁, 容易上手, 并且支持包括 JavaScript、 Java、Python、C# 等在内的多种语言
• 支持注释 : yml 支持多行和单行注释, 可以对配置文件进行详尽的注释, 方便开发者理解
• 语言兼容性好 : yml 被多种编程语言支持, 如 Python、Ruby、Java 等, 而且解析速度非常快, 适用于数据集成和持久化场景下
• 支持更多的数据类型 : yml 支持更多的数据类型, 如字符串、数字、数组、日期等等, 而且还支持自定义的数据类型, 方便处理各种复杂的配置

缺点 :

• 可读性受限 : 虽然相对于其他配置文件格式, yml 语法更加简洁, 但当层级过深时, 代码可读性就会变差
• 容易出错 : yml 看起来很简单, 但是在使用上有很多细节的东西, 比如空格、层级之间的 Tab, 不太容易被发现错误, 很难及时发现修复. 并且由于 yml 文件是将数据集成到一个文件中的格式, 因此如果文件在一处修改出现错误, 可能会影响整个系统
• 不利于分布式环境下使用 : 由于 yml 的特点是将数据集成到一个文件中, 因此在分布式系统中, 很难将不同的配置文件放到不同的节点中去, 导致很难维护
• 性能方面不如其他配置文件格式 : yml 文本数据占用空间比 XML 和 JSON 更大, 所以在大规模的数据存储和传输中不太合适**

3.3 yml 的更多数据类型配置

• 配置字符串

• 配置布尔值

• 配置整数

• 配置浮点数

• 配置 NULL

• 配置数组

数组内容需要用缩进后用 ’ - ’ 来表示, 注意数组中的内容都是同一层级的, 缩进要一致

• 配置日期

• 配置对象数组

对象数组中, 每个对象以 - 空格开头, 表示一个新的对象. 并且每个对象之间层级缩进要一致

properties 和 yml 的关系

在企业中, 业务越来越细化, 每个业务之间的配置文件语言不同, 进行业务整合时配置文件的整合就会非常的麻烦, 学习成本也非常的高, 需要清楚各种不同语言的配置文件语法. 因此 yml 的诞生支持多语言, 跨平台就解决了这个问题.

• 无论是 properties 和 yml 都是配置文件的一种, 只是时期不同, properties 是最早期的配置文件, 而 yml 是后面发展起来的, 并且 properties 是官方默认的, 权重比 yml 更高
• 既然 properties 和 yml 都可以用, 同时创建也不会报错. 但是当同时存在并启动时, 配置文件中同样的属性会优先加载 properties 的配置信息, 如 properties 设置 prot 为 7777, yml 设置 prot 为 8888, 那么启动后, 项目的启动端口号就是 7777 才能用, 以 properties 为主
• 虽然 properties 的优先级更高, 二者同时存在时, 同一属性以 properties 为主, 但并不代表 yml 中的该属性不加载. 当 properties 加载完毕后, yml 文件也会加载配置信息
• 在实际业务中, 通常会采取统一的配置文件格式, 这样可以更好地维护

三. 获取配置文件信息

1. @Value 注解读取配置信息

使用 @Value 注解来读取配置文件中的信息, 例如读取 properties 配置文件中自定义的 key 为 Java 的 Value 值

在类中注入, 并设置路由观察能否正确获取到配置信息

运行启动

为什么这里获取到的是key 值 而非 value 值, 此处的@Value 起的是将 Java 这个字符串赋值给 config 这个对象, 而并非是读取 Java 的 value 赋值给 config. 想要正确获取需要加上 ${ } , 才能正确获取

2. 读取系统配置信息

除了获取自定义的配置信息以外, 也可以获取系统配置信息, 例如配置文件中设置的端口号

3. 读取对象

例如在配置文件中有一个 person 对象如下

这时候使用 @Value 注解去读取配置信息

启动运行查看

可以看到, 通过 @Value 同样可以正确的获取到配置文件中的自定义对象. 但是这里有一个问题, 就是 @Value 每次只能获取一个属性, 没法同时获取多个, 当这个对象中有多个字段的时候, 哪每个属性都需要去通过 @Value 注解获取一次就会很麻烦, 因此 Spring Boot 中提供了另一个注解来解决这个问题

4. @ConfigurationProperties 注解

• 配置文件中自定义对象

• 创建一个 Person 类用于存储从配置文件中读取到的属性

需要注意的是, 这里的 prefix 是可以省略不写的, 直接写配置文件中对象的前缀名即可, 它会自动通过 key 值去寻. 同时还必须提供 get 和 set 方法. 一是因为通过 key 去配置文件中找到对象以后, 就是通过 get 和 set 方法去赋值的. 二是这个对象要随着 Spring Boot 的项目启动而启动, 要在初始化之前进行属性设置. 因此 get 和 set 方法必不可少 !

并且上面这些赋值都是发生在 Spring 里, Spring 自动注入的东西都需要放在加载阶段, 否则启动后在注入就来不及了. 因此这里需要加载类注解, 此处加的为 @Component , 这样就可以在 Spring 启动后在其他地方注入使用

• 在指定类中注入对象使用

通过路由访问观察结果

可以看到, 同样是可以拿到指定的对象的. 同时控制台中还输出了 person 对象, 这是在初始化时候的, 可以证明在初始化之前, person 的属性就已经被赋值了

四. 不同环境下的配置文件

现在由于微服务, 细化了很多工作, 每个人或者部门使用的编程语言不一样, 因此就需要多个配置文件, 那么这些配置文件该怎么去建立呢 ?

因为 yml 的诞生就是为了去解决跨平台的问题的, 因此对于多环境的配置文件是采取 yml 配置文件

**规则 : **

• 必须要有主配置文件, 且文件名必须是 : application.yml( properties )
• 不同环境中, 每个平台有一个配置文件, 并且配置文件名称有要求 : application-XXX.yml ( properties ), 这里的 XXX 就是不同平台可以自己修改的

那么, 如何在将他们都整理到主配置文件中, 如创建一个生产环境下的名为 application-dec.yml (简称为 dec, XXX命名为什么, 简称就是什么 )的配置文件, 并且设置端口号为 9999

在主配置文件 application.yml 中设置生产环境下的配置文件

运行启动看端口号是否从默认的 8080 变更为生产环境下 dec 的端口号

成功的将端口号修改为 9999, 因此 yml 在不同环境下多语言情况下, 可以很好的将配置文件进行整合, 让运维人员可以减少成本进行维护