前置导入
什么是多环境?其实就是说你的电脑上写的程序最终要放到别人的服务器上去运行。每个计算机环境不一样,这就是多环境。常见的多环境开发主要兼顾3种环境设置,开发环境——自己用的,测试环境——自己公司用的,生产环境——甲方爸爸用的。因为这是绝对不同的三台电脑,所以环境肯定有所不同,比如连接的数据库不一样,设置的访问端口不一样等等。
多环境开发(yaml单一文件版)
那什么是多环境开发?就是针对不同的环境设置不同的配置属性即可。比如你自己开发时,配置你的端口如下:
server: port: 80
如何想设计两组环境呢?中间使用三个减号分隔开
server: port: 80 --- server: port: 81
如何区分两种环境呢?起名字呗
spring: profiles: pro server: port: 80 --- spring: profiles: dev server: port: 81
那用哪一个呢?设置默认启动哪个就可以了
spring: profiles: active: pro # 启动pro --- spring: profiles: pro server: port: 80 --- spring: profiles: dev server: port: 81
就这么简单,再多来一组环境也OK
spring: profiles: active: pro # 启动pro --- spring: profiles: pro server: port: 80 --- spring: profiles: dev server: port: 81 --- spring: profiles: test server: port: 82
其中关于环境名称定义上述格式是过时格式,标准格式如下
spring: config: activate: on-profile: pro
总结
- 多环境开发需要设置若干种常用环境,例如开发、生产、测试环境
- yaml格式中设置多环境使用—区分环境设置边界
- 每种环境的区别在于加载的配置属性不同
- 启用某种环境时需要指定启动时使用该环境
多环境开发(yaml多文件版)
将所有的配置都放在一个配置文件中,尤其是每一个配置应用场景都不一样,这显然不合理,于是就有了将一个配置文件拆分成多个配置文件的想法。拆分后,每个配置文件中写自己的配置,主配置文件中写清楚用哪一个配置文件就好了。
主配置文件
spring: profiles: active: pro # 启动pro
环境配置文件
server: port: 80
环境配置文件因为每一个都是配置自己的项,所以连名字都不用写里面了。那问题是如何区分这是哪一组配置呢?使用文件名区分。
application-pro.yaml
server: port: 80
application-dev.yaml
server: port: 81
文件的命名规则为:application-环境名.yml
上图中的application.yml就是我们说的主配置文件,其他的都是环境配置文件。
在配置文件中,如果某些配置项所有环境都一样,可以将这些项写入到主配置中,只有哪些有区别的项才写入到环境配置文件中。
- 主配置文件中设置公共配置(全局)
- 环境分类配置文件中常用于设置冲突属性(局部)
总结
- 可以使用独立配置文件定义环境属性
- 独立配置文件便于线上系统维护更新并保障系统安全性
多环境开发(properties多文件版)
SpringBoot最早期提供的配置文件格式是properties格式的,这种格式的多环境配置也可以了解一下。
主配置文件
spring.profiles.active=pro
环境配置文件
application-pro.properties
server.port=80
application-dev.properties
server.port=81
文件的命名规则为:application-环境名.properties
总结
properties文件多环境配置仅支持多文件格式
多环境开发独立配置文件书写技巧
作为程序员在搞配置的时候往往处于一种分久必合合久必分的局面。开始先写一起,后来为了方便维护就拆分。对于多环境开发也是如此,下面给大家说一下如何基于多环境开发做配置独立管理,务必掌握。
准备工作
将所有的配置根据功能对配置文件中的信息进行拆分,并制作成独立的配置文件,命名规则如下
- application-devDB.yml
- application-devRedis.yml
- application-devMVC.yml
使用
使用include属性在激活指定环境的情况下,同时对多个环境进行加载使其生效,多个环境间使用逗号分隔
spring: profiles: active: dev include: devDB,devRedis,devMVC
比较一下,现在相当于加载dev配置时,再加载对应的3组配置,从结构上就很清晰,用了什么,对应的名称是什么
注意
当主环境dev与其他环境有相同属性时,主环境属性生效;其他环境中有相同属性时,最后加载的环境属性生效
改良
但是上面的设置也有一个问题,比如我要切换dev环境为pro时,include也要修改。因为include属性只能使用一次,这就比较麻烦了。SpringBoot从2.4版开始使用group属性替代include属性,降低了配置书写量。简单说就是我先写好,你爱用哪个用哪个。
spring: profiles: active: dev group: "dev": devDB,devRedis,devMVC "pro": proDB,proRedis,proMVC "test": testDB,testRedis,testMVC
现在再来看,如果切换dev到pro,只需要改一下是不是就结束了?完美!
总结
- 多环境开发使用group属性设置配置文件分组,便于线上维护管理 多环境开发控制
最后说一个冲突问题。就是maven和SpringBoot同时设置多环境的话怎么搞。
要想处理这个冲突问题,你要先理清一个关系,究竟谁在多环境开发中其主导地位。也就是说如果现在都设置了多环境,谁的应该是保留下来的,另一个应该遵从相同的设置。
maven是做什么的?项目构建管理的,最终生成代码包的,SpringBoot是干什么的?简化开发的。简化,又不是其主导作用。最终还是要靠maven来管理整个工程,所以SpringBoot应该听maven的。整个确认后下面就好做了。大体思想如下:
- 先在maven环境中设置用什么具体的环境
- 在SpringBoot中读取maven设置的环境即可
maven中设置多环境(使用属性方式区分环境)
env_dev dev true env_pro pro
SpringBoot中读取maven设置值
spring: profiles: active: @profile.active@
上面的@属性名@就是读取maven中配置的属性值的语法格式。
总结
- 当Maven与SpringBoot同时对多环境进行控制时,以Maven为主,SpringBoot使用@…@占位符读取Maven对应的配置属性值
- 基于SpringBoot读取Maven配置属性的前提下,如果在Idea下测试工程时pom.xml每次更新需要手动compile方可生效(此问题在IDEA21、22版本已经得到解决)
日志前导
日志其实就是记录程序日常运行的信息,主要作用如下:
- 编程期调试代码
- 运营期记录信息
- 记录日常运营重要信息(峰值流量、平均响应时长……)
- 记录应用报错信息(错误堆栈)
- 记录运维过程数据(扩容、宕机、报警……)
日志的使用格式非常固定,直接上操作步骤:
步骤①:添加日志记录操作
@RestController @RequestMapping("/books") public class BookController extends BaseClass{ private static final Logger log = LoggerFactory.getLogger(BookController.class); @GetMapping public String getById(){ log.debug("debug..."); log.info("info..."); log.warn("warn..."); log.error("error..."); return "springboot is running...2"; } }
上述代码中log对象就是用来记录日志的对象,下面的log.debug,log.info这些操作就是写日志的API了。
结果:
默认的我们的系统在启动起来的时候,日志级别是info级别,所以这里我们只能看到info以及其上的日志信息
步骤②:设置日志输出级别
日志设置好以后可以根据设置选择哪些参与记录。这里是根据日志的级别来设置的。日志的级别分为6种,分别是:
- TRACE:运行堆栈信息,使用率低
- DEBUG:程序员调试代码使用
- INFO:记录运维过程数据
- WARN:记录运维过程报警数据
- ERROR:记录错误堆栈信息
- FATAL:灾难信息,合并计入ERROR
一般情况下,开发时候使用DEBUG,上线后使用INFO,运维信息记录使用WARN即可。下面就设置一下日志级别:
# 开启debug模式,输出调试信息,常用于检查系统运行状况 debug: true
在开启了debug模式之后我们在开启项目的时候会有大篇幅的文字,这个模式我们一般在项目上线之后的检测才会使用到。
这么设置太简单粗暴了,日志系统通常都提供了细粒度的控制
# 开启debug模式,输出调试信息,常用于检查系统运行状况 debug: true # 设置日志级别,root表示根节点,即整体应用日志级别 logging: level: root: debug
我们设置成debug级别之后,再运行就可以看到:
还可以再设置更细粒度的控制(例如我们不想看框架里面的debug日志)
步骤③:设置日志组,控制指定包对应的日志输出级别,也可以直接控制指定包对应的日志输出级别
logging: # 设置日志组 group: # 自定义组名,设置当前组中所包含的包 ebank: com.nefu.controller,com.nefu.service level: root: warn # 为对应组设置日志级别 ebank: debug # 为对包设置日志级别 com.nefu.controller: debug
说白了就是总体设置一下,每个包设置一下,如果感觉设置的麻烦,就先把包分个组,对组设置。
总结
- 日志用于记录开发调试与运维过程消息
- 日志的级别共6种,通常使用4种即可,分别是DEBUG,INFO,WARN,ERROR
- 可以通过日志组或代码包的形式进行日志显示级别的控制
写代码的时候每个类都要写创建日志记录对象,这个可以优化一下,使用前面用过的lombok技术给我们提供的工具类即可。
@RestController @RequestMapping("/books") public class BookController extends BaseClass{ private static final Logger log = LoggerFactory.getLogger(BookController.class); //这一句可以不写了 }
导入lombok后使用注解搞定,日志对象名为log
@Slf4j //这个注解替代了下面那一行 @RestController @RequestMapping("/books") public class BookController extends BaseClass{ private static final Logger log = LoggerFactory.getLogger(BookController.class); //这一句可以不写了 }
日志输出格式控制
日志已经能够记录了,但是目前记录的格式是SpringBoot给我们提供的,如果想自定义控制就需要自己设置了。先分析一下当前日志的记录格式。
- PID:进程ID,用于表明当前操作所处的进程,当多服务同时记录日志时,该值可用于协助程序员调试程序。
- 所属类/接口名:当前显示信息为SpringBoot重写后的信息,名称过长时,简化包名书写为首字母,甚至直接删除。
对于单条日志信息来说,日期,触发位置,记录信息是最核心的信息。级别用于做筛选过滤,PID与线程名用于做精准分析。了解这些信息后就可以DIY日志格式了。
模拟的官方日志模板的书写格式:
logging: pattern: console: "%d %clr(%p) --- [%16t] %clr(%-40.40c){cyan} : %m %n"
日志文件
日志信息显示,记录已经控制住了,下面就要说一下日志的转存了。日志不能仅显示在控制台上,要把日志记录到文件中,方便后期维护查阅。
对于日志文件的使用存在各种各样的策略,例如每日记录,分类记录,报警后记录等。这里主要研究日志文件如何记录。
记录日志到文件中格式非常简单,设置日志文件名即可。
logging: file: name: server.log
虽然使用上述格式可以将日志记录下来了,但是面对线上的复杂情况,一个文件记录肯定是不能够满足运维要求的,通常会每天记录日志文件,同时为了便于维护,还要限制每个日志文件的大小。下面给出日志文件的常用配置方式:
logging: logback: rollingpolicy: #代表日志的滚动 max-file-size: 3KB #文件大小限度 file-name-pattern: server.%d{yyyy-MM-dd}.%i.log #滚动日志的文件名怎么启
以上格式是基于logback日志技术设置每日日志文件的设置格式,要求容量到达3KB以后就转存信息到第二个文件中。文件命名规则中的%d标识日期,%i是一个递增变量,用于区分日志文件。
到此这篇关于SpringBoot多环境开发与日志的文章就介绍到这了,更多相关SpringBoot多环境开发内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!