最近遇到了一些设计相关的面试题，思考了一些边边角角，但是不全面不体系，复盘了下做一下系统化、体系化的梳理，让自己的内力猛增，展示一下雄厚的 “技术肌肉、技术实力”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提，offer自由”。

* 如果要你设计一个灰度发布组件，你会如何设计它的整体架构？
* 你们的灰度发布是如何设计的？发布的时候出现问题，如何 **进行版本的回滚？**

## 动态灰度发布

传统的负载均衡策略，如轮询（Round-Robin）或随机（Random），虽然简单高效，却也像一位“一视同仁”的舵手，无法应对日益复杂的生产环境需求。

有一个头疼的灰度场景：一个关键服务即将发布新版本，需要 **先让一小部分真实流量进入新版本进行“实弹演习”，验证其稳定性**，而不是 “一刀切”式的流量调度方式。当我们需要进行 A/B 测试、蓝绿部署、金丝雀发布（灰度发布）时，传统的负载均衡策略便显得力不从心。

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

在这我们就需要一个自研 Spring Cloud LoadBalancer 灰度负载均衡组件，实现 **服务发现与负载均衡组件，实现接口请求在众多服务实例间精准路由**。根据预设的规则，将请求流量按比例、按版本、按区域进行精妙的调度。

接下来我们将从剖析 Spring Cloud LoadBalancer 的核心机制出发，最终亲手实现一个企业级的、基于 Nacos 权重的动态灰度发布策略。这不仅是一次负载均衡器的开发实践，更是一场关于微服务治理、风险控制与平滑发布的深度思考。

### 大纲

为了更好地规划这次流量探索之旅，我们先通过以下蓝图来了解将要经历的各个阶段。

业务之殇 - 为何需要精细化流控？

* 传统策略的局限：轮询/随机
* 现代发布的需求：A/B测试、灰度发布、优雅停机

生产重器 - 动态灰度发布策略

* 设计理念：Nacos 权重 + 版本元数据
* 源码剖析：实例的选择

实战演练 - 驾驭生产流量

* 定义灰度版本
* 配置 Nacos 灰度规则
* 启动并验证流量

### 业务之殇 - 为何需要精细化流控？

在微服务实践的早期，我们最常使用的负载均衡策略是轮询。它简单、公平，将请求依次分发给后端的每一个服务实例，如同一个尽职尽责的交通警察，让每条车道都承载相同的车流。然而，随着业务的快速迭代和微服务架构的深入，新的问题开始浮现。

想象一下，你的团队刚刚完成了一个核心交易接口的重大重构。尽管经过了多轮测试，但谁也无法百分之百保证它在真实、复杂的生产流量下能完美运行。此时，最稳妥的方式是进行金丝雀发布（或称灰度发布）：先将 1% 的线上流量导入新版本的服务实例，观察其 CPU、内存、错误率等核心指标。如果一切正常，再逐步将流量比例提升到 10%、50%，直至 100%，最终完成新版本的平滑上线。

在这个场景下，轮询或随机策略不灵了。它们无法识别服务实例的版本差异，更无法按需分配流量比例。这使得我们陷入了一个两难的境地：要么承担巨大风险进行全量发布，要么为了追求绝对安全而大大降低发布效率。为了打破这一僵局，我们必须赋予负载均衡器“智能”，让它能够“看懂”服务实例的元数据（如版本、区域、环境等），并根据我们下发的“指令”（流量策略）进行决策。

### 深入 Spring Cloud LoadBalancer 的内部世界

在构建我们自己的智能负载均衡策略之前，我们必须先理解 Spring Cloud LoadBalancer 的工作原理，因为它是我们所有自定义策略的基石。

自 Spring Cloud 2020.0.0 版本（代号 Ilford）开始，Netflix Ribbon 被正式移除，Spring Cloud LoadBalancer 成为了官方推荐的客户端负载均衡解决方案。它以更简洁、更灵活、全面拥抱响应式编程（Project Reactor）的姿态，为我们提供了强大的扩展能力。

架构三大核心组件Spring Cloud LoadBalancer 的架构可以被精炼地概括为三大核心组件的协作：

* ReactorServiceInstanceLoadBalancer (负载均衡器)：这是负载均衡策略的直接体现者。它的核心职责是接收一个服务实例列表，并根据内部实现的算法（如轮询、随机或我们即将自定义的灰度策略）从中选择一个最合适的实例。
* ServiceInstanceListSupplier (服务实例列表供应商)：它的角色是 客户端 服务实例的“发现者”和“提供者”。它负责与服务发现组件（如 Nacos, Eureka）交互，获取指定服务 ID（serviceId）下所有健康的服务实例列表，并将其提供给负载均衡器。ServiceInstanceListSupplier 还内置了缓存机制，避免了对注册中心的频繁请求。
* ServiceInstance (服务实例)：这是对一个具体服务节点的抽象，包含了该实例的 IP 地址、端口、元数据（metadata）等关键信息。负载均衡器最终选择并返回的就是一个ServiceInstance对象。

#### 核心接口：ReactorServiceInstanceLoadBalancer

负载均衡策略的核心接口是 ReactorServiceInstanceLoadBalancer。

```
java

public interface ReactorServiceInstanceLoadBalancer extends ReactorLoadBalancer<ServiceInstance> {
    Mono<Response<ServiceInstance>> choose(Request request);
}
```

它的 choose 方法接收一个 Request 对象（包含了请求上下文），并返回一个 `Mono<Response<ServiceInstance>>`。

这意味着整个负载均衡过程是异步的、非阻塞的。choose 方法的内部实现，就是负载均衡算法的核心所在。

#### 默认实现：RoundRobinLoadBalancer

Spring Cloud LoadBalancer 的默认实现是 RoundRobinLoadBalancer，它通过一个原子计数器，在所有可用的服务实例中循环选择，实现了轮询策略。

我们的目标，就是通过自定义配置，替换掉这个默认的 RoundRobinLoadBalancer，插入我们自己实现的、更智能的负载均衡器。

#### 工作流程：一次完整的负载均衡之旅

当一个带有 @LoadBalanced 注解的 RestTemplate 或 WebClient 发起请求时，一次完整的负载均衡流程便开始了：

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

这个时序图清晰展示了Spring Cloud 客户端负载均衡的完整流程，核心是将客户端对 “服务名” 的请求，通过负载均衡机制转换为对具体 “服务实例 IP + 端口” 的请求。

整个流程以 “客户端发起请求” 为起点，以 “客户端接收最终响应” 为终点，共分为 5 个关键阶段，涉及 5 个核心组件的协同工作。

1、发起请求与拦截触发客户端（如使用 RestTemplate 或 WebClient）发起请求，请求 URL 中使用服务名而非具体 IP，请求 地址 例如 [http://ruoyi-system/user/profile/1。该请求会被负载均衡拦截器（LBInterceptor） 捕获，拦截器是实现客户端负载均衡的入口。](http://ruoyi-system/user/profile/1%E3%80%82%E8%AF%A5%E8%AF%B7%E6%B1%82%E4%BC%9A%E8%A2%AB%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E6%8B%A6%E6%88%AA%E5%99%A8%EF%BC%88LBInterceptor%EF%BC%89%C2%A0%E6%8D%95%E8%8E%B7%EF%BC%8C%E6%8B%A6%E6%88%AA%E5%99%A8%E6%98%AF%E5%AE%9E%E7%8E%B0%E5%AE%A2%E6%88%B7%E7%AB%AF%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E7%9A%84%E5%85%A5%E5%8F%A3%E3%80%82)

2、负载均衡器与实例获取拦截器调用负载均衡器（Balancer，如 ReactorServiceInstanceLoadBalancer） 的 choose(request) 方法，请求选择一个合适的服务实例。负载均衡器向服务实例列表供应商（Supplier） 发送 get(request) 请求，获取目标服务的所有可用实例。实例供应商向服务注册中心（Nacos） 发起查询，请求 “ruoyi-system” 微服务的所有健康实例（过滤掉下线或不健康的实例）。

3、实例筛选与算法执行Nacos 返回 “ruoyi-system” 的健康实例列表，例如 [ins1, ins2, ins3]。实例供应商将实例列表传递给负载均衡器。负载均衡器内部执行负载均衡算法（如轮询、随机、权重等），从实例列表中选定一个目标实例（例如 ins2）。

4、 URL 替换与实际请求负载均衡器将选定的实例信息返回给拦截器。拦截器执行关键操作：将请求 URL 中的服务名替换为实例的 IP 和端口。替换前：[http://ruoyi-system/user/profile/1替换后：http://192.168.1.102:9201/user/profile/1拦截器使用替换后的真实](http://ruoyi-system/user/profile/1%E6%9B%BF%E6%8D%A2%E5%90%8E%EF%BC%9Ahttp://192.168.1.102:9201/user/profile/1%E6%8B%A6%E6%88%AA%E5%99%A8%E4%BD%BF%E7%94%A8%E6%9B%BF%E6%8D%A2%E5%90%8E%E7%9A%84%E7%9C%9F%E5%AE%9E) URL，向目标服务实例发起 HTTP 请求。

5、 响应接收与返回目标服务实例处理请求后，将响应返回给客户端。拦截器将收到的响应透传给最初发起请求的客户端，整个负载均衡流程结束。

### 一个简单而实用的自定义负载均衡策略

在深入探讨复杂的灰度发布之前，我们先来分析 一个简单而实用的自定义负载均衡策略——本地优先。

#### 场景：通过调用本地服务提升性能

在一个大型微服务项目中，很多的服务部署在 同一个节点。假设一个 “订单服务”，而它依赖于“用户服务”和“商品服务”。在 rpc 时， 希望“订单服务”调用的 本地启动的“用户服务”， 而不是 其他节点的 “用户服务”和“商品服务”，以方便本地调试并发。

默认的轮询或随机策略无法满足这个需求，它们可能会将请求发送到开发环境的任何一个“用户服务”实例上，导致你的本地调试过程变得极其困难和不可控。

#### 实现：CustomSpringCloudLoadBalancer

为了解决这个问题，一个定制的 本地优先的 `CustomSpringCloudLoadBalancer ，它的核心逻辑非常清晰：

```
java

// org.dromara.common.loadbalance.core.CustomSpringCloudLoadBalancer.java
private Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances) {
    if (instances.isEmpty()) {
        // ...
        return new EmptyResponse();
    }
    // 1. 遍历所有实例
    for (ServiceInstance instance : instances) {
        // 2. 判断实例的IP是否是本机IP之一
        if (NetUtil.localIpv4s().contains(instance.getHost())) {
            // 3. 如果是, 立即返回该实例
            return new DefaultResponse(instance);
        }
    }
    // 4. 如果没有找到本机实例, 则退化为随机策略
    return new DefaultResponse(instances.get(ThreadLocalRandom.current().nextInt(instances.size())));
}
```

这个实现非常巧妙：

* (1) 它首先获取本地服务器的所有 IPv4 地址。
* (2) 然后遍历注册中心返回的服务实例列表。
* (3) 如果发现某个实例的 host（IP 地址）是本机 IP，就“插队”，直接选择这个实例。
* (4) 如果遍历完所有实例都没有找到本机 IP，说明本地没有启动该服务，此时策略自动“降级”，采用随机算法选择一个远程实例。

通过 CustomLoadBalanceAutoConfiguration将这个自定义负载均衡器设置为默认策略，`RuoYi-Cloud-Plus` 完美地解决了多团队协同开发时的服务调用问题，极大地提升了开发效率。

### 自定义 一个 动态灰度发布策略

现在，我们将基于 上面的本地优先负载均衡 代码，一步步构建支持动态权重调整的灰度发布策略。

#### 设计理念：Nacos 权重 + 版本元数据

我们的核心设计思想是：利用 Nacos 作为“指挥中心”

* (1) 服务版本定义：在服务的 `application.yml` 中定义版本号，并在注册到 Nacos 时，将其作为实例的元数据（metadata）

```
yaml

spring:
  cloud:
    nacos:
      discovery:
        metadata:
          version: v1.1.0
```

* (2) 灰度规则定义：在 Nacos 配置中心，为需要进行灰度发布的服务定义流量规则。

```
yaml

gray:
  loadbalancer:
    enabled: true
    # 灰度规则
    rules:
      ruoyi-system:
        # 灰度版本号
        version: v1.1.0
        # 流量权重
        weight: 20
```

* (3) 智能负载均衡器：创建一个新的负载均衡器 `GrayLoadBalancer`，它会同时读取 Nacos 注册中心的服务实例列表（及其元数据）和配置中心的灰度规则，然后按权重动态地将流量分配给“灰度版本实例”和“主版本实例”。

#### 核心实现：GrayLoadBalancer

我们创建的 GrayLoadBalancer 是整个灰度策略的核心。其 getInstanceResponse 方法的执行逻辑如下：

```
java

private Response<ServiceInstance> getInstanceResponse(List<ServiceInstance> instances) {
    // ... 省略非空判断 ...
    // 1. 从配置属性中获取当前服务的灰度规则
    GrayRule grayRule = grayLoadBalancerProperties.getRules().get(serviceId);
    String grayVersion = grayRule.getVersion();
    Integer grayWeight = grayRule.getWeight();
    // 2. 根据版本号元数据, 将实例分为灰度组和主版本组
    List<ServiceInstance> grayInstances = instances.stream()
        .filter(instance -> grayVersion.equals(instance.getMetadata().get("version")))
        .collect(Collectors.toList());
    List<ServiceInstance> normalInstances = instances.stream()
        .filter(instance -> !grayVersion.equals(instance.getMetadata().get("version")))
        .collect(Collectors.toList());
    // ... 省略其中一组为空的降级逻辑 ...
    // 3. 按权重进行流量分配
    int random = new Random().nextInt(100);
    if (random < grayWeight) {
        // 流量走向灰度实例
        // 在选定的灰度实例组中再进行一次随机, 避免所有灰度流量打到同一台机器
        return new DefaultResponse(grayInstances.get(new Random().nextInt(grayInstances.size())));
    } else {
        // 流量走向主版本实例
        // 同样, 在主版本实例组中进行随机, 保证流量均匀
        return new DefaultResponse(normalInstances.get(new Random().nextInt(normalInstances.size())));
    }
}
```

#### 自动装配：让策略 生效（并且动态生效）

为了让 GrayLoadBalancer 能够被 Spring Cloud 框架发现并使用，我们创建了 `GrayLoadBalancerAutoConfiguration` 。

```
java

@Configuration
// 1. 启用我们定义的灰度配置属性类
@EnableConfigurationProperties(GrayLoadBalancerProperties.class)
// 2. 只有在配置文件中 gray.loadbalancer.enabled = true 时, 该配置才会生效
@ConditionalOnProperty(value = "gray.loadbalancer.enabled", havingValue = "true")
public class GrayLoadBalancerAutoConfiguration {
    @Bean
    public ReactorLoadBalancer<ServiceInstance> grayLoadBalancer(
        Environment environment,
        LoadBalancerClientFactory loadBalancerClientFactory,
        GrayLoadBalancerProperties grayLoadBalancerProperties) {
        String name = environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME);
        // 3. 将我们的 GrayLoadBalancer 注入到 Spring 容器, 替换掉默认的负载均衡器
        return new GrayLoadBalancer(
            loadBalancerClientFactory.getLazyProvider(name, ServiceInstanceListSupplier.class),
            name,
            grayLoadBalancerProperties);
    }
}
```

通过 @ConditionalOnProperty 注解，我们实现了一个“开关”。只有当用户显式地在配置中开启灰度功能时，GrayLoadBalancer 才会覆盖掉默认的 CustomSpringCloudLoadBalancer 或 RoundRobinLoadBalancer，从而实现了对框架的无侵入式扩展。

### 实现动态灰度的实战演练

理论的价值在于指导实践。现在，让我们一步步完成一次完整的灰度发布流程。

#### 步骤一：准备灰度版本

假设我们正在对 ruoyi-system 服务进行升级。

* 修改代码：完成新功能的开发或 Bug 修复。
* 修改版本号: 在 ruoyi-system 模块的 application.yml 中，将元数据版本号修改为新版本，例如 v1.1.0。
* 打包: 单独打包 ruoyi-system 模块，生成 ruoyi-system.jar。

#### 步骤二：配置 Nacos 灰度规则

登录 Nacos 控制台，找到 ruoyi-system-dev.yml（或对应环境的配置），添加或修改灰度发布配置：

```
yaml

# 灰度发布配置
gray:
    loadbalancer:
        # 开启灰度功能
        enabled: true
        # 定义具体服务的规则
        rules:
            # 为 ruoyi-system 服务配置灰度规则
            ruoyi-system:
                # 灰度版本的版本号, 必须与jar包中定义的元数据一致
                version: v1.1.0
                # 分配给灰度版本的流量权重 (0-100), 这里设置为20%
                weight: 20
```

点击“发布”，Nacos 配置中心的这条规则将动态地被我们的 GrayLoadBalancer 感知到。

#### 步骤三：启动并验证流量

1、部署实例:

* 保持原有的 ruoyi-system 服务实例（假设版本为 v1.0.0）运行。
* 将打包好的新版本 ruoyi-system.jar (v1.1.0) 部署并启动。此时 Nacos 中应该能看到两个版本的 ruoyi-system 实例。

2、 验证流量:

为了方便观察， 可以在 ruoyi-system 的某个 Controller 接口中，返回当前实例的版本号。

3、然后使用一个简单的 Shell 脚本来模拟连续请求：

```
sh

#!/bin/bash
# 循环请求100次
for i in {1..100}; do
  # 使用 curl 请求网关的接口, -s 表示静默模式
  # jq 用于解析JSON并提取version字段
  curl -s http://localhost:8080/system/user/profile/1 | jq .data.version
done | \
# 统计各个版本出现的次数
sort | uniq -c | sort -nr
```

4、 观察结果:执行脚本后，你将看到类似下面的输出：

```
text

 81 "v1.0.0"
 19 "v1.1.0"
```

这个结果清晰地表明，在 100 次请求中，约有 80%的流量流向了主版本 (v1.0.0)，约有 20%的流量流向了我们新发布的灰度版本 (v1.1.0)。这证明我们的动态灰度发布策略已成功生效！

接下来，我们可以持续观察灰度版本的各项监控指标（如 CPU、内存、错误率等）。如果一切平稳，只需在 Nacos 控制台将weight的值从20逐步调整到50、80，最终调整到100。当权重为100时，所有流量都将进入新版本。此时，我们就可以将旧版本的服务实例安全下线，完成一次平滑、零中断、风险可控的线上发布。

### 总结与展望

智能负载均衡是微服务治理体系中至关重要的一环。我们实现的灰度发布策略，仅仅是冰山一角。更先进的负载均衡器，可以结合更丰富的维度进行决策，例如：

* 基于请求内容的路由：根据请求头（Header）、参数（Parameter）中的用户信息，将特定用户群体的请求转发到灰度实例。
* 基于性能指标的动态权重：实时采集服务实例的 CPU、内存、响应时间等指标，动态调整实例的权重，自动将流量从性能不佳的实例上移开。

希望本次对 一个自研 Spring Cloud LoadBalancer 灰度负载均衡组件 负载均衡策略的探索，能为你打开一扇通往高级微服务治理的大门，激发你对流量调度架构方案 更深层次的思考与实践。

插件设计 - 结合 Spring Cloud Nacos 实现动态灰度发布

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

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

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

## 本质

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

## 使用场景

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

思考哪些场景能更好的适用`责任链模式`？

我看过一些文章，描述的是通过不同的处理器去处理对象，每个处理器开头就是校验请求是否匹配我当前的业务，那为什么不直接用`适配器模式`呢？

其实在某些场景中，结合设计模式，只是`没有最好，只有更好`，主要还是看自己的内功掌握的怎么样，如何去定义一个场景更贴合哪种设计模式才是真理，拿我个人理解而言，我更多的会在某些串行逻辑执行或者串行校验的业务，才会使用此模式，例如：`业务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、稳定性保障系统相关的监控，降级，回滚，业务灰度⽅案等措施。

## 稳定性保障

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

## ⻛险点

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

## 项⽬计划

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

📌 使⽤⽅式

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

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

说到 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](https://blog.liushigong.cn/static/img/f3958c42bcf3202a0644b4c5148e6be8.image.webp)

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

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

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

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

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

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

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

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

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

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

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

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

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

### 阅读源码

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

![image.png](https://blog.liushigong.cn/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](https://blog.liushigong.cn/static/img/b95cd347a33a2b16c4f4204b3dfba52b.image.webp)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 总结

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

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

思考一下

根据上面的源码思路，如何实现动态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](https://blog.liushigong.cn/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 源码进行有条理的分析出来，才能更好的体现自己的深度。