# link-flow

**Repository Path**: sddrjack/link-flow

## Basic Information

- **Project Name**: link-flow
- **Description**: 在 link-flow 项目中提供了完整的蓝绿发布、灰度发布、滚动发布的落地实现方案。不仅解决了上述提到的所有问题并且还做了额外的扩展，支持了多个注册中心。支持多维度的路由隔离过滤策略维度，包括:区域、组、版本、标识等。还额外提供了发生服务故障时的降级兜底策略。并且这些路由的指定除了通过请求链路发送外，还可以通过在配置中心来设置，支持热部署，当修改参数后，会立即生效，无需重启。
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 7
- **Forks**: 1
- **Created**: 2025-03-28
- **Last Updated**: 2025-12-16

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

**link-flow** 项目中提供了完整的蓝绿发布、灰度发布、滚动发布的落地实现方案。不仅解决了上述提到的所有问题，并且还做了额外的扩展，支持了多个注册中心(Nacos、Eureka)。

支持多维度的路由隔离过滤策略维度，包括：**区域**、**组**、**版本**、**标识** 等。还额外提供了发生服务故障时的降级兜底策略。并且这些路由的指定除了通过 **请求链路** 发送外，还可以通过在 **配置中心** 来设置(Naocs、Apollo)，支持热部署，当修改参数后，会立即生效，无需重启。

**link-flow** 项目中除了提供上述提供的路由隔离过滤策略维度外，还设计了额外扩展，利用 **设计模式和Spring的加载机制**，还可以让使用人员扩展自己的路由隔离过滤策略，非常的方便。

一般来说对于这种链路传递的参数通常是放到 **ThreadLocal** 中，实现线程之间的隔离。但由于 **ThreadLocal** 本身的设计，在线程池使用下会有数据传递错乱的问题，网上有说可以使用阿里提供的 **TransmittableThreadLocal** 来解决，确实是可以，但都是最初级的用法。因为如果要使用 **Log4j** 或者 **LogBack** 的日志来输出路由隔离参数的话，需要借助 **MDC** 上下文，而这还是 **ThreadLocal** 结构，而且是源码中的！要解决 **MDC** 的数据传递错乱问题，初级的手段只能是重写一个日志中的源码来替换原有的。

这种方式过于生硬，如果后续进行日志升级的话，又要重新写一遍源码。侵入性极强！而在 **link-flow** 项目中，提供了高级的设计与使用，日志无需替换源码，随便升级。而且以后但凡是这种 **ThreadLocal** 多线程下传递的问题，都可以这么处理，对原有逻辑无侵入性！

以下是 **link-flow** 对于不同发布类型的设计结构：

### 蓝绿发布业务结构

![](https://multimedia-javaup.cn/link-flow/%E8%93%9D%E7%BB%BF%E6%9C%8D%E5%8A%A1png%E5%9B%BE%E7%89%87.PNG)

### 灰度发布业务结构

![](https://multimedia-javaup.cn/link-flow/%E7%81%B0%E5%BA%A6%E6%9C%8D%E5%8A%A1png%E5%9B%BE%E7%89%87.PNG)

## 不同维度的详细解释

#### 区域：

- 使用不同区域：例如多机房的情况下，来区分出不同机房下的服务，可以通过不同的区域来匹配到蓝绿发布。

- 降级区域：如果服务路由过程中没有找到相应区域的服务实例，会路由到配置的降级区域来做兜底。

#### 组：

- 使用不同组：来实现对服务进行逻辑上的分组，主要作用在同一个区域下的不同组的服务之间实现路由隔离。
- 不支持降级组的策略。

#### 版本

- 通过不同版本：来匹配到蓝绿发布。
- 降级版本：如果服务路由过程中没有找到相应版本的服务实例，会路由到配置的降级版本来做兜底。
- 版本权重：可以通过配置不同版本的调用权重，来匹配到灰度发布。

## 组织架构设计

针对于分布式和微服务的架构来说，服务的数量上千个都是很正常的，而对于这些服务的调用完成流量切换的功能，需要考虑的方面就很多了。

比如：**SpringBoot的自动装配控制bean**、**负载均衡的增强**、**多个注册中心的适配**、**多个配置中心的适配**、**多线程和Reactor模式的数据传递**、**不同维度路由参数的过滤**、**发生故障后的兜底处理** 等等，这些问题在项目中都有解决。

![](https://multimedia-javaup.cn/link-flow/%E6%9E%B6%E6%9E%84%E5%9B%BE.png)

## 项目亮点

- 由于要对微服务的服务调用时，来进行判断是否要调用实现过滤，所以要对原有的框架进行再次开发增强，比如 **LoadBalancer**、**ServiceInstance**、**ReactorLoadBalancer**。面试时不总说微服务就只是单纯调用个 Feign 就没了吗，这回就有了高级玩法，**对原有的框架进行高级的定制！**



- 在设计时，路由隔离的参数不仅可以通过请求链路传递，并且可以根据配置中心(Nacos、Apollo)来进行配置，并且做了兼容，实现相同操作可以在不同配置中心配置，体现了如何利用设计模式来进行不同的适配，以及模块之间要怎么来设计。



- 使用了 **SpringBoot自动装配机制**，以及 **@AutoConfigureBefore** 等高级用法来灵活的加载和控制。



- 使用了Spring的 **监听事件机制**，来和配置中心适配。



- 使用了Spring的 **后置处理器 BeanPostProcessor**，来实现深度装载定制功能。



- 多线程情况下的高级玩法，适配线程池、适配熔断、适配ThreadLocal传递、适配日志MDC传递、适配reactor模式等。



- 对微服务的框架有着**更加高级的定制功能**，包括注册中心、配置中心、负载均衡、熔断策略等，二次增强的深度开发，而不再是简单的引用个依赖，调用个api这么简单。



- 使用了大量的设计模式和设计原则来实现高内聚、低耦合。光设计模式就包括：**工厂**、**模板**、**策略**、**装饰**、**命令**、**适配**、**观察者**、**迭代器** 等多种。