既是轮子项目，又有业务功能！服务请求流量切换利器：link-flow项目来袭！

link-flow 项目诞生原因

对于现在的Java后端面试情况来说，纯被八股文已经过时了，到目前已经发展成项目穿插了八股文来提问了，单纯的八股文厉害只能说明你的理论确实不错，但能把八股文和项目相结合，这种理论和实践相结合的方式，才是面试官最想要的！

所以这就要求项目要有亮点才行！对此我开发了高并发实战项目大麦，项目开源地址为：点击这里。也确实给小伙伴面试起到了非常大的帮助，有的人光是分布式锁这节，就让面试官的印象非常的深了！

对于目前的项目来说可以分为两大类：业务项目 和 轮子项目，大麦项目就属于是业务项目，围绕着用户购买演唱会业务，而解决的一些列高并发问题。

而轮子项目是指对于现在已有的框架自己来完成一个简易版的，也就是自己重新创造一个轮子。常见的轮子项目有：简易版Spring、简易版RPC。尤其是这个RPC轮子项目，太多太多人写这个了！当我看过的简历，但凡是轮子项目10个里面有8个都是这个！

但说实话，RPC轮子项目 这个很容易给自己挖坑，因为RPC内部的用到的网络技术其实很复杂，因为涉及到了网络通信，这就不得不提到另一个非常有名的框架：Netty。但在实习期间就能把Netty弄明白的，真的太困难了！而当面试时，面试官肯定会拿这个自己实现的RPC项目和Netty相比较，我就提几个最容易爱问的问题，看看有几个人能清楚的：

你自己实现的这个RPC和用到了Netty哪些方面？序列化是怎么处理？拆包粘包问题是怎么解决的？
为什么要使用Netty？它的优势在哪里？为什么不直接使用Java提供的NIO？Netty又是解决了Java的NIO中的哪些问题？
既然提到了NIO，那NIO中的轮询器是什么？要哪几种类型，分别起到了什么作用？你设计的RPC又是怎么用的？
GRPC清楚吗？它是协议是哪种？你设计的RPC和GRPC相比，相同的地方是哪里？不同的地方又是哪里？

不知道你能否抗住这些问题，不要觉得如果是面试实习工作这些问题不会被问，如果是面试大厂，面试官最爱问的就是这些了！网络部分本身就很复杂，很就让自己陷入被动！

而轮子项目对于面试也确实很受欢迎，简历如果能有一个业务项目，再有一个轮子项目是最好不过了！为此我设计出了业务和轮子相结合的项目：link-flow。既有着控制微服务流量的业务功能，又有着对微服务框架进行定制增强的轮子功能。而且不仅适用于实习，对于社招来说，也是能用到的！

link-flow 项目背景

建议在了解此项目功能前，先了解蓝绿/灰度/滚动发布的功能介绍：点击这里

其实实现蓝绿/灰度/滚动发布的关键点是要让 请求流量能够在对应的服务之间完成切换！

举一个例子：比如说用户调用到网关时，网关会指定一个版本，比如 version-2，接着就会让这个版本一直在请求头中传递下去，当后续调用到每一个服务时，都要判断只能版本是 version-2 的服务才可以被调用到！这样就可以保证整个链路调用的服务都是 version-2 版本的了！

alt

但这只能算是个雏形，离真正的实现还差的很远，要考虑的有问题有很多，比如：

如何要考虑在nginx网关还是业务网关配置路由参数？
具体要对微服务的哪个部分进行判断请求版本和服务版本的判断？
如果要对微服务实现判断过滤逻辑，要如何保证原有逻辑不被破坏？
在进行版本判断时，就简单的判断是否一致就可以了吗？需要有其他的额外处理吗？
如果是多线程下，包括：线程池、Hystrix、Reactor、这些情况下，如果让路由参数正常传递？
如果服务中的版本要改变，比如 version-2 变成了 version-3，如何快速就可以实现？
... ... ... ...

以上只是简单罗列了一些，实际要解决的问题要有很多很多。。。

link-flow 项目介绍

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

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

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

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

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

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

蓝绿发布业务结构

alt

灰度发布业务结构

alt

不同维度的详细解释

区域：

使用不同区域：例如多机房的情况下，来区分出不同机房下的服务，可以通过不同的区域来匹配到蓝绿发布。
降级区域：如果服务路由过程中没有找到相应区域的服务实例，会路由到配置的降级区域来做兜底。

组：

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

版本

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

组织架构设计

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

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

alt

项目亮点

由于要对微服务的服务调用时，来进行判断是否要调用实现过滤，所以要对原有的框架进行再次开发增强，比如 LoadBalancer、ServiceInstance、ReactorLoadBalancer。面试时不总说微服务就只是单纯调用个 Feign 就没了吗，这回就有了高级玩法，对原有的框架进行高级的定制！
在设计时，路由隔离的参数不仅可以通过请求链路传递，并且可以根据配置中心(Nacos、Apollo)来进行配置，并且做了兼容，实现相同操作可以在不同配置中心配置，体现了如何利用设计模式来进行不同的适配，以及模块之间要怎么来设计。
使用了 SpringBoot自动装配机制，以及 @AutoConfigureBefore 等高级用法来灵活的加载和控制。
使用了Spring的 监听事件机制，来和配置中心适配。
使用了Spring的 后置处理器 BeanPostProcessor，来实现深度装载定制功能。
多线程情况下的高级玩法，适配线程池、适配熔断、适配ThreadLocal传递、适配日志MDC传递、适配reactor模式等。
对微服务的框架有着更加高级的定制功能，包括注册中心、配置中心、负载均衡、熔断策略等，二次增强的深度开发，而不再是简单的引用个依赖，调用个api这么简单。
使用了大量的设计模式和设计原则来实现高内聚、低耦合。光设计模式就包括：工厂、模板、策略、装饰、命令、适配、观察者、迭代器 等多种。