在工作中经常在某些场景会用到一些设计模式，今天写一篇文档记录下`责任链模式`的使用。






# 责任链模式

责任链模式通过将多个处理器对象以链式结构串联起来，然后调用链路上处理器对象方法，直至链路上处理器都调用完成。

对于我们所了解的设计原则，责任链模式更符合`单一职责原则`和`迪米特原则`，各个实现类只要关注的自己业务逻辑，按照我们定义好的顺序进行处理。

## 本质

解耦数据和行为分离，整体提高扩展性

## 使用场景

当对请求需要多种逻辑处理或者校验符合规则的对象时，可以使用责任链模式。


:::tip{title="思考哪些场景能更好的适用`责任链模式`？"}
我看过一些文章，描述的是通过不同的处理器去处理对象，每个处理器开头就是校验请求是否匹配我当前的业务，那为什么不直接用`适配器模式`呢？

其实在某些场景中，结合设计模式，只是`没有最好，只有更好`，主要还是看自己的内功掌握的怎么样，如何去定义一个场景更贴合哪种设计模式才是真理，拿我个人理解而言，我更多的会在某些串行逻辑执行或者串行校验的业务，才会使用此模式，例如：`业务A -> 业务B -> 业务C`

:::

## 优点

> 降低耦合度：发送者和接收者之间解耦。  
> 简化对象：对象不需要知道链的结构。  
> 灵活性：通过改变链的成员或顺序，动态地新增或删除责任。  
> 易于扩展：增加新的请求处理类很方便。


## 缺点

> 性能影响：可能影响系统性能，且调试困难，可能导致循环调用。  
> 难以观察：运行时特征不明显，可能妨碍除错。

## 实现方式

定义处理器接口：通常包含一个处理请求的方法，指定顺序或者一个指向下一个处理者的引用。
定义管理器类：可以通过管理器来管理责任链，管理器可以动态地增加或删除责任链成员以及指定顺序。

### 示例1

结合 Spring 的 Ordered 接口和 SmartInitializingSingleton 接口，实现指定顺序的处理器，交由 Spring 管理使用。

```java
// 定义指定顺序的处理者接口 - 基于Spring实现

import org.springframework.beans.factory.SmartInitializingSingleton;
import org.springframework.core.Ordered;

public interface BusinessChainHandler extends Ordered, SmartInitializingSingleton {
    void handle(InterfaceParamDTO param);
}
```

定义不同的处理器实现

```java
@Component
public class OneChainHandler implements BusinessChainHandler {
    @Override
    public void handle(InterfaceParamDTO param) {
        System.out.println("链路中第一个执行逻辑！");
    }

    @Override
    public int getOrder() {
        return 1;
    }

    @Override
    public void afterSingletonsInstantiated() {
        ChainHandlerManager.addChainHandler(this);
    }
}

@Component
public class TwoChainHandler implements BusinessChainHandler {
    @Override
    public void handle(InterfaceParamDTO param) {
        System.out.println("链路中第二个执行逻辑！");
    }

    @Override
    public int getOrder() {
        return 2;
    }

    @Override
    public void afterSingletonsInstantiated() {
        ChainHandlerManager.addChainHandler(this);
    }
}

@Component
public class ThreeChainHandler implements BusinessChainHandler {

    @Override
    public void handle(InterfaceParamDTO param) {
        System.out.println("链路中第三个执行逻辑！");
    }

    @Override
    public int getOrder() {
        return 3;
    }

    @Override
    public void afterSingletonsInstantiated() {
        ChainHandlerManager.addChainHandler(this);
    }
}
```

责任链管理器也可以有不同实现，例如通过本地缓存实现，也可以定义为 Bean，交由 Spring 管理，通过Bean信息实例化完成时进行初始化操作。

对于管理器的这些实现方式有利有弊，像本地缓存可无需依赖Spring，调用简单，实现方便，但是需要考虑自定义的顺序，像基于Spring容器管理的方式更加快捷，缺点就是需要依赖注入，增加代码复杂度。

```java
// 责任链管理器 - 本地缓存实现
public class ChainHandlerManager {

    private static final List<BusinessChainHandler> chainHandler = new ArrayList<>();

    public static List<BusinessChainHandler> getChainHandler() {
        return chainHandler;
    }

    public static void addChainHandler(BusinessChainHandler handler) {
        chainHandler.add(handler);
        chainHandler.sort(Comparator.comparingInt(BusinessChainHandler::getOrder));
    }

    public static void execute(InterfaceParamDTO param) {
        chainHandler.forEach(handler -> handler.handle(param));
    }
}

// 责任链管理器 - 基于 Spring 容器管理实现
@Component
public class SpringChainHandlerManager implements SmartInitializingSingleton {

    @Resource
    private OneChainHandler oneChainHandler;

    @Resource
    private TwoChainHandler twoChainHandler;

    @Resource
    private ThreeChainHandler threeChainHandler;

    private static final List<BusinessChainHandler> chainHandler = new ArrayList<>();

    public static void execute(InterfaceParamDTO param) {
        chainHandler.forEach(handler -> handler.handle(param));
    }

    @Override
    public void afterSingletonsInstantiated() {
        chainHandler.add(oneChainHandler);
        chainHandler.add(twoChainHandler);
        chainHandler.add(threeChainHandler);
    }
}

```

以下对不同的实现方式进行测试。

```java
@SpringBootTest(classes = XenergyMonitorApplication.class)
class ChainHandlerManagerTest {

    @Resource
    private SpringChainHandlerManager springChainHandlerManager;

    @Resource
    private ApplicationContext applicationContext;

    @Autowired
    private List<BusinessChainHandler> businessChainHandlerList;

    @Test
    public void test() {
        ChainHandlerManager.execute(new InterfaceParamDTO());
        System.out.println();

        springChainHandlerManager.execute(new InterfaceParamDTO());
        System.out.println();

        Map<String, BusinessChainHandler> beansOfType = applicationContext.getBeansOfType(BusinessChainHandler.class);
        beansOfType.values().stream().sorted(Comparator.comparingInt(BusinessChainHandler::getOrder)).collect(Collectors.toList()).forEach(v -> v.handle(new InterfaceParamDTO()));

        System.out.println();
        businessChainHandlerList.forEach(x -> x.handle(new InterfaceParamDTO()));
    }
}
```

### 示例2

此示例与示例1一致，只不过是自定义排序，而不是通过 Spring 容器进行管理，需要结合管理器的方式进行调用。

```java
// 定义指定顺序的处理者接口 - 自定义实现

import org.springframework.beans.factory.SmartInitializingSingleton;
import org.springframework.core.Ordered;

public interface BusinessChainHandler {

    void sort();

    void handle(InterfaceParamDTO param);
}
```

### 示例3

此实现是通过主动设置下一个处理者的引用，来完成链式调用。也就是明确的指定下一个处理者，而不需要进行单独排序处理。

```java
// 指向下一个处理者的引用的实现

import org.springframework.beans.factory.SmartInitializingSingleton;
import org.springframework.core.Ordered;

public interface NextBusinessChainHandler {

    void next(InterfaceParamDTO param);

    void handle(InterfaceParamDTO param);
}
```

以上的接口实现方式为,此实现只需要找到头节点即可

```java

@Component
public class OneNextBusinessChainHandler implements NextBusinessChainHandler {

    @Resource
    private TwoNextBusinessChainHandler twoNextBusinessChainHandler;

    @Override
    public void next(InterfaceParamDTO param) {
        twoNextBusinessChainHandler.handle(param);
    }

    @Override
    public void handle(InterfaceParamDTO param) {
        // 逻辑处理
        System.out.println("链路中第一个执行逻辑！");

        // 下个节点
        this.next(param);
    }
}

@Component
public class TwoNextBusinessChainHandler implements NextBusinessChainHandler {

    @Resource
    private ThreeNextBusinessChainHandler threeNextBusinessChainHandler;

    @Override
    public void next(InterfaceParamDTO param) {
        threeNextBusinessChainHandler.handle(param);
    }

    @Override
    public void handle(InterfaceParamDTO param) {
        // 逻辑处理
        System.out.println("链路中第二个执行逻辑！");

        // 下个节点
        this.next(param);
    }
}

@Component
public class ThreeNextBusinessChainHandler implements NextBusinessChainHandler {

    @Override
    public void next(InterfaceParamDTO param) {
        // 没有下一个调用了
    }

    @Override
    public void handle(InterfaceParamDTO param) {
        // 逻辑处理
        System.out.println("链路中第三个执行逻辑！");

        // 下个节点
        this.next(param);
    }
}
```

## 思考

对于责任链模式的实现，网上的实现各式各样，其实只要我们掌握原理以后，就可有千变万化的玩法，就拿以上3种示例而言，可以相互组合，选择一种更适合自己的方式。

模式是在经验中积累的，是知识的结晶，而不是死板硬套的模子！不要因为一些写模式的书比较流行就膜拜了，自己要多加动脑思考代码上的实现真是就只能是这样吗？ 是不是有更优秀的方式来替代呢？

设计模式 - 责任链模式

技术⽅案本质上需要回答两个问题：  
>* 其⼀，为什么该⽅案可⾏？  
>* 其⼆，在已有资源限制下，为什么该⽅案是最优的？  

为了回答第⼀个问题，我们需要在技术⽅案⾥补充架构图、接⼝设计和时间⼈⼒估算。  

⽽要回答第⼆个问题，需要我们在关键点或争议处提供⼆到三种⽅案，并给出建议⽅案，这样才有说服⼒。  

通常情况下，我们会花费很多的时间准备第⼀个问题，⽽忽略第⼆个问题。  
其实，回答好第⼆个问题很重要，⼤型项⽬的设计已经复杂到没⼈能够⼀次就想到最佳⽅案，⼀个仅仅“可⾏”的⽅案，可能会给系统增加额外的复杂性。  





# 项目技术方案模板

## 背景

讲清楚what+why，介绍项⽬的背景、相关系统的现状以及相关名词定义。

着重说明项⽬以下问题：

必要性（为什么要做）

⻛险（不做这个事情有哪些影响）


## ⽬标

要达成的效果，最好是与问题对应。

如果是产品的需求，这⾥直接贴需求对应的⽬标

业务需求是什么？项⽬产出是什么？衡量指标是什么？


## 整体设计

⼏个部分，分别是⼲什么的，系统的整体流程图和系统的分层架构图


## 详细设计

⽅案部分，重点讨论：How，怎么做。

如果是概览的⽅案，则需要描述清楚

宏观的架构，主要是模块的关系（组织⽅式）

模块的定义，定位、职责、边界、输⼊输出

对于技术中出现的⼀些具体的技术难点，则需要描述清楚怎么做的。


### 1、业务流程

业务流程的流程图，不同⻆⾊不同阶段的处理过程，以及各种分⽀情况的条件及处理逻辑。要覆盖

所有流程分⽀，不重不漏。

### 2、模型/数据库设计

表结构设计，包含：ER图、建表语句

### 3、关键逻辑/算法

业务流程图中 系统最关键逻辑的具体说明，重点说清楚本系统最关键部分的处理逻辑

### 4、数据产出逻辑

从原始数据 到 最终结果 过程中的关键计算逻辑说明，包括该逻辑在系统中的的应⽤场景，及具体

逻辑实现等。关键数据指标（需要⾃测和部分QA测试时验证正确性）

### 5、定时任务

定时任务的作⽤，时间选择，处理逻辑，是否需要失败重试等。数据重跑⽅案（重跑⽅案需要保证幂等性）

### 6、系统依赖

对上游系统或第三⽅系统的服务依赖，说明具体的依赖场景，围绕该依赖的设计思路等。


## 接⼝⽂档

涉及到的新增和修改的接⼝⽂档，可以附上⽂档链接6、稳定性保障系统相关的监控，降级，回滚，业务灰度⽅案等措施。

## 稳定性保障

系统相关的监控，降级，回滚，业务灰度⽅案等措施。

## ⻛险点

如有相关⻛险点，可以记下来。包括思考点，结论，备注等信息。

## 项⽬计划

精确到天的时间安排和⼈员分⼯，有明确的检查点。

:::danger{title="📌 使⽤⽅式"}
此模板旨在给⼤家编写技术⽅案以及做⽅案评审时查缺补漏，如有部分章节项⽬不涉及，可以不写，但是需要保留整体结构。
:::

工作经验分享 - 项目技术方案模板

说到 SpringBoot 自动装配的原理，可能有的人就要开始 @EnableAutoConfiguration 的长篇大论了，感觉在背源码一样，那么 `自动装配` 的含义你是真的了解吗？它是如何与 Spring 相结合的，又是如何被 Spring 管理的？接下来我将告诉你 `自动装配` 原理的真正打开方式。



# 自动装配的本质

自动装配的本质其实就是将 `starter` 快速依赖包中的 Bean 信息，自动的整合到 Spring IOC 容器中被 Spring 所管理，掌握此本质，就可自由实现自定义的 `starter` 的各种工具包，学习本文以前，需要掌握 Spring 容器中的 Bean 生命周期流程。

# 代码上的核心实现

其实现的方式就是通过 `@SpringApplication` 复合注解中的 `@EnableAutoConfiguration` 注解的 `AutoConfigurationImportSelector` 类中调用 `SpringFactoriesLoader #loadFactoryNames` 方法，加载 `META-INF/spring.factories` 文件实现的

大体了解流程以后，开始分析源码，流程掌握比较简单，但是如何**从 SpringBoot 启动后基于 Spring 扩展进行的自动装配的实现才是最核心重点**。

## 从源码上看实现

查看 `@SpringBootApplication` 源码，可以看到存在一个 `@EnableAutoConfiguration` 注解，此注解即为 SpringBoot 内部注解，为 Spring 上下文提供自动配置的

![image.png](/static/img/f3958c42bcf3202a0644b4c5148e6be8.image.webp)


接着看 `@EnableAutoConfiguration` 注解的实现，内部使用了 `@Import` 注解（Spring 的核心注解，其用于导入一个或多个 Bean 信息），导入了 `AutoConfigurationImportSelector` Bean 信息

![image.png](/static/img/f5171b10991b43bc7f0a6ff2880782f6.image.webp)


此时 `AutoConfigurationImportSelector` 实例已被注册成 Bean，被 Spring 容器所管理，此实例的接口实现了 `DeferredImportSelector` 接口， 查看下源码的实现

![image.png](/static/img/ed03aa97156c5c4b6b91490f86d02674.image.webp)


齿轮开始转动，自动装配的实现也是从此刻开始，一直常说 SpringBoot 启动时会加载 `META-INF/spring.factories` 文件，并且将文件中的实现类加载到 Spring 容器中，那么到的是如何加载的呢？源码看到这，接下来要如何查找呢？

很简单粗暴的方法，一个查找当前源码的类，一个从源码中全局搜索，去查找到 `spring.factories` 文件在哪被定义过，看是否被当前类引用过，就找到了当前的接口调用

![image.png](/static/img/ccd68795061d1c9455499d0bdf062eaf.image.webp)


查看 `SpringFactoriesLoader #loadFactoryNames` 方法，可以看到其内部加载 `META-INF/spring.factories` 文件

![image.png](/static/img/d6037180f4ebc11d863b4d376c2f4133.image.webp)

源码看到这基本就差不多了，在看一眼 `META-INF/spring.factories` 文件内容

![image.png](/static/img/cbdc314d49f29ec9dddfecedf6716dca.image.webp)


## 结合 Spring 的扩展看实现（核心）

看完上面的流程，你以为就这样结束了么，感觉一切这么理所当然，转动脑筋思考下，SpringBoot 启动的时候，是如何来执行到上述的流程呢？接下来我们继续断点分析


### 阅读源码

通过对调用 `SpringFactoriesLoader #loadFactoryNames` 的方法进行断点，发现一切奥秘尽在堆栈之中，有没有看到那个特殊眼熟的 `refresh` 方法，这个是 Spring 容器刷新的入口，不了解的小伙伴可以去看下文章：[Spring 源码分析之 Bean 的全生命周期](https://blog.liushigong.cn/post/11)

![image.png](/static/img/4a10fb63a20b99aa6bc547cfa29e1287.image.webp)


开始看上层堆栈方法的源码，首先将 `META-INF/spring.factories` 文件读取的的内容构建成 `AutoConfigurationEntry` 对象

![image.png](https://blog.liushigong.cn/static/img/577c12eab83775dc506d6e0e0e3dc789.image.webp)


将构建的 `AutoConfigurationEntry` 对象，存储到本地缓存的 `this.autoConfigurationEntries` 集合中

![image.png](/static/img/b95cd347a33a2b16c4f4204b3dfba52b.image.webp)


接着找上层的调用，又打开了新世界的大门，调用到了 `ConfigurationClassParser` 类，此类主要是对配置类的解析，以下是从掘金社区提供的图片

![image.png](/static/img/6b64f9d25517f61d2e787474745f8efb.image.webp)

![image.png](/static/img/084242a2bb010d87267aef20852c4732.image.webp)

了解了 `ConfigurationClassParser` 类的作用，发现其内部调用了 `processImports` 方法，此方法就是解析的核心方法，递归加载，有兴趣可以自行阅读源码

![image.png](/static/img/880d4beb88000db7cabd17db870b345c.image.webp)

可以看出此处进行的for循环，包含我们的核心类  `AutoConfigurationImportSelector` ，那么，其中 `this.groupings.values()` 数据从哪里来呢

![image.png](/static/img/5df88f2f6fe971224cbde4b8594e3c5f.image.webp)

找到上层方法，发现有一个 `register` 方法，内部果然是构建了 `this.groupings.values()` 数据

![image.png](/static/img/2f550935b8b213fd98e03bc094eec833.image.webp)

![image.png](/static/img/dc946c2df6b7cfcdd5579d9fc224bf68.image.webp)


看到此处，发现解析的核心逻辑实现，有兴趣可以自行阅读源码，这里就不再赘述了

![image.png](/static/img/fbcf9aba27beea28f38ff0409e1aeba3.image.webp)

继续查找进入到了 `ConfigurationClassPostProcessor` 类中，见名知意，此类为配置类后置处理的作用，扩展实现了 `BeanDefinitionRegistryPostProcessor` 接口，被调用了 `#postProcessBeanDefinitionRegistry` 方法

![image.png](/static/img/1f13d62a89d90005d24412d202badb6c.image.webp)

![image.png](/static/img/987459505f7ac006524e1ac8f9c4106a.image.webp)


接着往上层查找，走到了 `invokeBeanDefinitionRegistryPostProcessors` 方法，此处是调用 BeanDefinition 注册的后置处理的所有扩展接口，在联想到上述的 `ConfigurationClassPostProcessor` 类实现了其接口，可以理解是在此处将所有的配置类信息以及 `starter` 中的信息加载到了 Spring 容器中

![image.png](/static/img/0efcc4fa7b92f25ebfaad12f853e4fc2.image.webp)

![image.png](/static/img/c571bfd3af83dfb9204ec537abcfe258.image.webp)


找到这，终于看到非常眼熟的 `refresh` 方法，原来这一切都是在 Spring 容器刷新的时候，创建完 BeanFactory 以后，在调用 `invokeBeanFactoryPostProcessors` 方法，进行后置处理中操作的

![image.png](/static/img/ac4cb18857956b6185089a66306a67d3.image.webp)


### 总结

通过上面的源码追溯，我们总结一下 `自动装配` 的扩展流程实现

对于 `starter` 的中加载到的Bean信息，是通过 Spring 提供的 `DeferredImportSelector` 接口进行扩展的，通过 `BeanFactoryPostProcessor #postProcessBeanFactory` 后置处理中调用 `BeanDefinitionRegistryPostProcessor` 后置处理进行实现的

:::tip{title="思考一下"}
根据上面的源码思路，如何实现动态Bean加载呢？ 如何基于Nacos配置中心来实现动态线程池的管理呢？
:::


## SpringBoot 2.7 版本以后得实现

在 `AutoConfigurationImportSelector #getCandidateConfigurations` 方法，由调用的 `SpringFactoriesLoader #loadFactoryNames` 方法变成了 `ImportCandidates #load` 方法，查找的文件也从 `META-INF/spring.factories` 改为了 `META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports`

![image.png](/static/img/8961d29b9f830c53a042b78eb2de58b3.image.webp)

其中文件的内容也进行了调整

```yaml
# 变更前 META-INF/spring.factories

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  cn.liushigong.cache.redis.RedisCacheAutoConfig

# 变更后 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

cn.liushigong.cache.redis.RedisCacheAutoConfig

```

# 结尾

我们所了解的 SpringBoot 不是一个全新的框架，而是对 Spring 的一种扩展，回答 `自动装配` 这个问题，除了 @SpringApplication 这千篇一律的逻辑以外，我们还需要能结合 Spring 源码进行有条理的分析出来，才能更好的体现自己的深度。

SpringBoot - 自动装配原理的满分解读

时序数据库 - InfluxDB  Web UI 实操大全

时序数据库 - InfluxDB 性能监控实战指标收集

baidu-site-verification

本人自己的博客，对工作与学习过程中的总结、一些场景设计的实现方案、遇到过的疑难问题与解决、以及面试总结等。