2. 日志模块（上）_blade 日志模块-CSDN博客

本文链接：https://blog.csdn.net/weixin_34452850/article/details/131561328

日志需求分析

无论对于业务系统还是中间件来说，日志都是必不可少的基础功能。完善、清晰地日志可以帮助我们观测系统运行的状态，并且快速定位问题。现在让我们站在 MyBatis 框架开发者的角度，来简单做一下日志功能的需求分析：

作为一个成熟的中间件，日志功能是必不可少的。那么，MyBatis 是要自己实现日志功能，还是集成现有的日志呢？MyBatis 没有选择重复造轮子，而是直接集成了第三方日志框架。
第三方的日志框架种类繁多，常用的如 slf4j、log4j2、logback 等等，而且每种框架的日志级别定义、打印方式、配置格式都不尽相同。MyBatis 作为底层的中间件，每个依赖 MyBatis 的业务系统都可能使用不同的日志组件，那 MyBatis 如何进行兼容呢？如果业务方引入了多个日志框架，MyBatis 按照什么优先级进行选择？
在 MyBatis 的核心处理流程中，包括 SQL 拼接、SQL 执行、结果集映射等关键步骤，都是需要打印日志的，如果在各处都显式地进行 log.info(“xxx”) 打印肯定不太合适，那么如何将日志打印优雅地织入到核心流程中？

Adapter Pattern 适配器模式

我们要在系统中集成多个第三方组件，每个组件具有相似的功能，但是接口定义各不相同，而我们自己的系统希望以统一地方式对组件进行调用。这么典型的使用场景，第一时间就可以想到 Adapter Pattern 适配器模式。
我们先来复习一下经典适配器模式的 UML 图：

（图片来源：https://refactoring.guru/design-patterns/adapter）

适配器模式的作用：将一个接口转换成满足客户端期望的另一个接口，使得接口不兼容的那些类可以一起工作。

Adapter 模式主要包含了以下角色：

Client：客户端，即我们自己的业务系统；
Client Interface：目标接口，定义了统一的、所有第三方组件都需要遵循的规范；
Service：需要集成的第三方组件，它包含了我们需要的功能，但是因为接口定义不匹配，所以无法直接使用；
Adapter：即最核心的适配器，它实现了 Client Interface 接口，并且对于 Service 进行了包装。这样一来，Adapter 就成为了既符合业务接口规范，同时又具备了期望的功能的组件，可以直接在项目中使用。

集成第三方日志框架

了解了适配器模式之后，我们来看下 MyBatis 是怎么把它灵活运用于日志模块中的。

首先，MyBatis 定义了 Log 接口，并指定了四种日志级别：

/**
 * MyBatis日志接口定义
 * 指定了trace、debug、warn和error四种日志级别
 */
public interface Log {

  boolean isDebugEnabled();

  boolean isTraceEnabled();

  void error(String s, Throwable e);

  void error(String s);

  void debug(String s);

  void trace(String s);

  void warn(String s);

}

可以看出，这其实是所有主流日志框架所支持的级别的交集。

接下来，MyBatis 为常用的日志框架都进行了 Adapter 的实现。这里以常用的 slf4j 为例：

/**
 * slf4j日志框架的Adapter实现
 * 该Adapter实现了Log接口,并且内部包装了slf4j的Logger对象以完成实际的日志打印功能
 */
class Slf4jLoggerImpl implements Log {

  private final Logger log;

  public Slf4jLoggerImpl(Logger logger) {
    log = logger;
  }

  @Override
  public boolean isDebugEnabled() {
    return log.isDebugEnabled();
  }

  @Override
  public boolean isTraceEnabled() {
    return log.isTraceEnabled();
  }

  @Override
  public void error(String s, Throwable e) {
    log.error(s, e);
  }

  @Override
  public void error(String s) {
    log.error(s);
  }

  @Override
  public void debug(String s) {
    log.debug(s);
  }

  @Override
  public void trace(String s) {
    log.trace(s);
  }

  @Override
  public void warn(String s) {
    log.warn(s);
  }

}

该 Adapter 实现了 Log 接口，并且内部包装了 slf4j 的 org.slf4j.Logger 对象以完成实际的日志打印功能，是一种经典的适配器实现。

这样一来，日志适配器的整体结构就比较清晰了，我简单画一张图类比一下：

这里的对应关系为：

Adapter 模式	MyBatis 实现
Client Interface	`Logger` 接口
Service	`org.slf4j.Logger` 组件
Adapter	`Slf4jLoggerImpl` 适配器

有了日志适配器，就可以在 MyBatis 中实现日志打印的功能了。但是第三方的日志框架众多，如果业务方引入了多个框架，MyBatis 应该如何决策该使用哪一个呢？我们来看下 MyBatis 中 LogFactory 日志工厂的实现：

/**
 * 日志工厂,通过getLog()方法获取日志实现类
 */
public final class LogFactory {

  public static final String MARKER = "MYBATIS";

  private static Constructor<? extends Log> logConstructor;

  //按照顺序依次尝试加载Log实现类
  //优先级为:slf4j -> commons-logging -> log4j2 -> log4j -> jdk-logging -> no-logging
  static {
    tryImplementation(LogFactory::useSlf4jLogging);
    tryImplementation(LogFactory::useCommonsLogging);
    tryImplementation(LogFactory::useLog4J2Logging);
    tryImplementation(LogFactory::useLog4JLogging);
    tryImplementation(LogFactory::useJdkLogging);
    tryImplementation(LogFactory::useNoLogging);
  }

  private LogFactory() {
    // disable construction
  }

  public static Log getLog(Class<?> clazz) {
    return getLog(clazz.getName());
  }

  public static Log getLog(String logger) {
    try {
      return logConstructor.newInstance(logger);
    } catch (Throwable t) {
      throw new LogException("Error creating logger for logger " + logger + ".  Cause: " + t, t);
    }
  }
  ...省略非必要代码
}

可以看到，在 LogFactory 的静态代码块中，按照指定的顺序尝试加载 Log 实现类，具体的优先级为：slf4j -> commons-logging -> log4j2 -> log4j -> jdk-logging -> no-logging 。如果加载成功，则不再继续加载。这样就实现了主流日志框架的选择。从 MyBatis 的选择中也可以看出，slf4j 确实是日志框架的首选。

最后，可以稍微留意一下，日志适配器中有一个 no-logging，它对应的是 NoLoggingImpl 类，它是一个空的实现，里面什么都没做。这其实是一种 Null Object Pattern（空对象模式），它也实现了目标接口，但是内部实际上是 Do Noting，这样能够以统一的方式使用目标组件，并且省去了很多判空操作。

/**
 * 空日志适配器
 * Null Object模式
 */
public class NoLoggingImpl implements Log {

  public NoLoggingImpl(String clazz) {
    // Do Nothing
  }

  @Override
  public boolean isDebugEnabled() {
    return false;
  }

  @Override
  public boolean isTraceEnabled() {
    return false;
  }

  @Override
  public void error(String s, Throwable e) {
    // Do Nothing
  }

  @Override
  public void error(String s) {
    // Do Nothing
  }

  @Override
  public void debug(String s) {
    // Do Nothing
  }

  @Override
  public void trace(String s) {
    // Do Nothing
  }

  @Override
  public void warn(String s) {
    // Do Nothing
  }

}