熟悉JAVA服务器开发的同学应该都使用过日志模块，并且大概率使用过"log4j-over-slf4j"和“slf4j-log4j”这两个包。那么这两个包的区别是什么？为什么会互相引用包含呢？这篇文章会解释下这几个概念的区别。

首先说一下SLF4J。

SLF4J全称"Simple Logging Facade for Java (SLF4J) ", 它诞生之初的目的，是为了针对不同的log解决方案，提供一套统一的接口适配标准，从而让业务代码无须关心使用到的第三方模块都使用了哪些log方案。

举个例子， Apache Dubbo和RabbitMQ使用到的日志模块便不相同。从某种意义上而言，SLF4J只是一个facade,类似于当年的ODBC(针对不同的数据库厂商而制定的统一接口标准， 下文会涉及到)。而这个facade对应的包名，是 “slf4j-api-xxx.xxx.xxx.jar”。所以，当你应用了"slf4j-api-xxx.jar"的包时，其实只是引入了一个日志接口标准，而并没有引入日志具体实现。

SLF4J标准在应用层的核心类，就是两个: org.slf4j.Logger 和 org.slf4j.LoggerFactory。其中，自版本1.6.0后，如果并没有具体的实现，slf4j-api会默认提供一个啥也不干的Logger实现(org.slf4j.helpers.NOPLogger)。

在当前(本稿件于2022-03-01拟制)的市面上，既有的实现SLF4J的方案有以下几种：

那么整个SLF4J的工作机制是如何运作的呢，换句话说，系统是如何知道应该使用哪个实现方案的呢？

对于那种不需要适配器的原生实现方式，直接引入对应的包即可。

对于那种需要适配器的委托式实现方式，则需要通过另外的一个渠道来告知SLF4J应该使用哪个实现类: SPI机制。

举个例子，我们看一下slf4j-log4j的包结构：

slf4j-log4j同时引入了slf4j-api和log4j。那么slf4j-log4j本身的作用不言而喻：使用LOG4J的功能，实现SLF4J的接口标准。

整体的接口/类关系路径如下图：

但是这仍然没有解决本章节开始提出的问题（程序怎么知道应该用哪个Logger）。

可以从源码入手：(slf4j/slf4j-log4j12 at master · qos-ch/slf4j · GitHub)，我们看到了以下关键的文件：

也就是说：slf4j-log4j使用了java的SPI机制告知JVM在运行时调用具体哪一个实现类。由于SPI机制暂不属于本文章讨论范围，读者可以去官网获取信息。

读者可以去GitHub - qos-ch/slf4j: Simple Logging Facade for Java看其他的实现方式的适配器是如何工作的。

那么本章开始的问题答案便是：

我们回到SLF4J。为什么它会用委派模式呢？因为日志打印功能存在各种不同的实现方式。对于应用开发者而言，最好需要一个标准的打印流程，其他第三方组件可以在某些地方有些不同，但是核心流程是最好不要变。对于标准制定者 而言，他无法控制每一个第三方组件的所有细节，所以只能暴露出有限的自定制能力。

而我们放大到软件领域，或者在互联网开发领域，不同的开发者的协作模式，主要靠jar包应用：第三方开发一个工具包，放在中心仓库中(maven, gradle)， 使用者从其他信息渠道(csdn, stackoverflow等等)根据问题定位到这个jar包，然后在代码工程中引用。理论上，如果这个第三方jar包很稳定(例如c3p0)，那么该jar包的维护者就很少甚至几乎不会和使用者建立联系。如果某些中间件开发者觉得不满足自己公司/部门的需求，会根据该jar包再做一次自定义封装。

纵观上述整个过程，不难发现两点：

1. 工具包开发者和使用者没有建立稳定的协同渠道

2. 工具包开发者对自己成品的发展掌控很薄弱

那么如果有人想要建立一套标准呢？比如log标准，比如数据库连接标准，那么只能有几个大公司联盟，或者著名的开发团队联盟，制定一个标准，并实现其中核心链路部分。至于为什么不实现全部链路，原因也很简单：软件领域的协同本身就是弱中心化的 ，否则你不带别人玩，别人也不会采用你的标准(参考当年IBM推广的COBOL)。

综上而言：委派模式是基于当前软件领域的协作特性，采取的较好的软件结构模式。

基于上述的讨论，委派模式的核心构成就显而易见了：核心链路， 开放接口。

核心链路指的是：为了达到某个目的，特定的一组构件，按照特定的顺序，特定的协同标准，共同执行计算的逻辑。

开放接口指的是：给定特定的输入和输出，将实现细节交给外部的功能接口。

几乎每一辆传统汽车，都按照三大件进行集成和协作：发动机，变速器，底盘。发动机做功， 通过变速器将动力传输给底盘(这么说并不标准，甚至在汽车工业的工人眼中，这种描述几乎是谬论，但是大致是这样)。也基于此，发动机的接口， 变速箱的接口，底盘的接口都已经固定，剩下的就各个厂商去实现了：三菱的发动机， 日产的发动机，爱信的变速箱，采埃孚的变速箱，伦福德的底盘，天合的底盘等等。甚至连轮胎的接口都制定好了：大陆的轮胎，普利司通的轮胎，固特异的轮胎。

不同的汽车厂商，选择不同公司的组件，集成出某个汽车型号。当然也有公司自己去实现某个标准：比如大众自己生产EA888发动机，PSA自己生产并调教的底盘并引以为傲。

经历过00年代的软件开发者，应该知道当时开发一个web应用是多么的困难：如何监听socket, 如何编码解码，如何处理并发，如何管理进程等等。但是有一点是共通的：每一个Web开发者都想要一个框架去管理整个http服务的协议层和内核层。于是出现了JBoss, WebSphere, Tomcat（笑到了最后）。

这些产品，都是指定了核心的链路：监听socket → 读数据包→ 封装成http报文 → 派发给处理池子 → 处理池的线程调用处理逻辑去处理 → 编码返回的报文 → 编组成tcp包 → 调用内核函数→ 发出数据。

基于这个核心链路，制定标准：业务处理逻辑的输入是什么，输出是什么，如何让web框架识别到业务处理模块。

Tomcat的方案就是web.xml。开发者只要遵从web.xml标准去实现servlet即可。也就是说，在整个http服务器链路中，Tomcat将特定的几个流程处理构件(listener, filter, interceptor, servlet)委派给了业务开发者去实现。

如果并不符合条件一，那么就不需要考虑使用委派模式；如果符合条件一但是不符合条件二，那就先预留好接口，采用依赖注入的方式，自己开发接口实现类并注入到主流程中。这个做法在很多的第三方依赖包中能够看到，比如spring的BeanFactory， BeanAware等等，还有各个公司开发SSO时预留的一些hook和filter等等。

在确定使用委派模式后，第一件事就是“确定核心链路”，这一步最难，因为往往使用者都有某种期望，但是让他们具体描述出来，却又经常不够精准，甚至有时候后主次颠倒。笔者的建议是：直接让他们说出原始的需求/痛点，然后自己尝试给出方案，再对比他们的方案，进行沟通，并逐渐将两个方案统一。统一的过程也就是不断试探和确定的过程。

上述的过程是笔者自己的经验，仅当借鉴。

在确定核心流程后，再将流程中的一些需要自定制的功能抽象成接口暴露出去。接口的定义中，尽量减少对整个流程中其他类的调用依赖。

所以整体的流程分为三步：确认使用该模式；提取核心流程；抽象开放接口。

至于是采用SPI机制还是像TOMCAT一样使用XML配置识别，需要看具体情况，在此不做涉及。

JDBC的诞生很大程度上是借鉴了ODBC的思想，为JAVA设计了专用的数据库连接规范JDBC(JAVA Database Connectivity)。JDBC期望的目标是让Java开发人员在编写数据库应用程序时，可以有统一的接口，无须依赖特定数据库API，达到“ 一次开发，适用所有数据库”。虽然实际开发中，经常会因为使用了数据库特定的语法、数据类型或函数等而无法达到目标，但JDBC的标准还是大大简化了开发工作。

整体而言，JDBC的接入结构大致如下图：

也是说，形式上，出现了初步委派的结构形式。

下文会只针对单次委托的JDBC层级做分析。

按照上文所言，每一个委派结构，必然存在两个要素：核心路径和开放接口。我们从这两个维度开始分析JDBC。

JDBC的核心路径分为六步， 包含委托机制需要的两步(引入包，声明委托承接人)，总共八步，如下：

纵观整个过程，核心的参与者为：Driver, Connection, Statement, ResultSet。transaction实际上是基于Connection的三个方法(setAutoCommit, commit, rollback)包装而成的会话层，理论上不属于标准层。

以mysql-connector-java为例，具体实现JDBC接口的情况如下：

通过Java自带的overriding机制，只要使用com.mysql.jdbc.Driver，那么其他组件的实现类便直接被应用实现。具体细节不做讨论。那么mysql-connector-java是如何告知JVM应该使用com.mysql.jdbc.Driver呢？

两种模式

Dubbo的可定制接口有很多，整体大量采用了“类SPI”机制，为整个RPC流程的很多环节，提供了自定制的注入机制。相较于传统的Java SPI, Dubbo SPI在封装性和实现类发现性上做了很多的扩展和自定制。

Dubbo SPI整体实现机制及工作机制不在本文范围，但为了行文方便，在此做一些必要说明。整体的Dubbo SPI机制可以分为三部分：

我们以Dubbo-Auth

(dubbo/dubbo-plugin/dubbo-auth at 3.0 · apache/dubbo · GitHub)为例，从核心路径和开放接口两个维度进行分析。

Dubbo-Auth的实现逻辑，是基于Dubbo-filter的原理，也就是说：Dubbo-Auth本身就是Dubbo整体流程中的某一个环节的委派实现方。

Dubbo-Auth的核心入口(也就是核心路径的起始点)， 是ProviderAuthFilter，

是org.apache.dubbo.auth.filter的具体实现， 也就是说：

ProviderAuthFilter的核心路径比较简单：获取Authenticator对象，使用Authenticator对象进行auth验证。

具体代码如下：

@Activate(group = CommonConstants.PROVIDER, order = -10000)public class ProviderAuthFilter implements Filter {     @Override    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {        URL url = invoker.getUrl();        boolean shouldAuth = url.getParameter(Constants.SERVICE_AUTH, false);        if (shouldAuth) {            Authenticator authenticator = ExtensionLoader.getExtensionLoader(Authenticator.class)                    .getExtension(url.getParameter(Constants.AUTHENTICATOR, Constants.DEFAULT_AUTHENTICATOR));            try {                authenticator.authenticate(invocation, url);            } catch (Exception e) {                return AsyncRpcResult.newDefaultAsyncResult(e, invocation);            }        }        return invoker.invoke(invocation);    }}

由于核心路径包含了Authenticator ，那么Authenticator 自然就很可能是对外暴露的开发接口了。也就是说，Authenticator 的声明类中，必然是注解了@SPI。

最后一个案例，我们又回到了日志组件，而之所以介绍LOG4J, 是由于它使用了非常规的“反向委派”机制。

LOG4J借鉴了SLF4J的思想(或者LOG4J在前？SLF4J借鉴的LOG4J ?), 也采用了 接口标准+ 适配器+第三方方案的思路来实现委派。

所以说，如果我同时引入了"log4j-over-slf4j"和"slf4j-log4j"，会造成stackoverflow。

这个问题非常典型， google一下就可能看到很多的案例，比如Analysis of stack overflow exception of log4j-over-slf4j and slf4j-log4j12 coexistence - actorsfit等等， 官方也给出了警告（SLF4J Error Codes）。

由于此文的关注点在委派模式，所以关于此问题并不详细讨论。而此案例的重点，是说明了一件事：委派模式的缺点，就是对于开放接口的实现逻辑不可控。如果第三方实现存在重大机制性隐患，会导致整体核心流程出现问题。

综上所述， 

委派模式的使用场景是：

委派模式的核心点： 核心路径， 开放接口。

委派模式的隐藏机制：实现方式的注册/发现。