当Spring Cloud Alibaba Sentinel碰上Spring Cloud Sleuth会擦出怎样的火花

当Spring Cloud Alibaba Sentinel碰上Spring Cloud Sleuth会擦出怎样的火花

前言
今年主要会做一个比较完整的微服务项目开源出来。目前已经开始了，刚兴趣的先Star一个吧。

项目：https://github.com/yinjihuan/kitty-cloud

基础框架：https://github.com/yinjihuan/kitty

在做的过程中遇到一个问题那就是标题所说的两个框架碰撞了火花。都是S开头的谁都不服谁。

问题描述
既然使用了Sentinel来限流，那么干脆熔断也直接用Sentinel好了，所以就没使用Hystrix了。

Sentinel对Feign做了适配，使用的时候只需要引入spring-cloud-starter-alibaba-sentinel，如下：

<groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>

然后在配置文件打开 Sentinel 对 Feign 的支持：feign.sentinel.enabled=true就可以了。

一开始都很正常，平平淡淡的小日子过得也挺舒坦。

突然有一天，来了一位同姓但不同名的哥们，它叫Sleuth。

Sleuth文档：https://cloud.spring.io/spring-cloud-static/Greenwich.SR5/single/spring-cloud.html#_spring_cloud_sleuth

Spring Cloud Sleuth为Spring Cloud实现了分布式追踪解决方案。可以配合Zipkin或者Jaeger使用。

自从Sleuth来了之后，Sentinel Feign 的日子就不好过了，莫名其妙熔断回退失效了。

问题排查
Sentinel 对 Feign 的适配入口在SentinelFeignAutoConfiguration中。

主要是构建了Feign 的 Builder类，只要这个类被自动配置了，那么Sentinel 对 Feign 的支持也会生效。突然不生效了，那么肯定是这里有问题。

于是开启debug模式，发现启动的时候这里没有执行。feign.sentinel.enabled已经配置了，剩下就只有@ConditionalOnMissingBean的问题了。

@ConditionalOnMissingBean的作用是如果容器中已经有Builder那么这里就不会执行。

接下来就要看Sleuth的代码了，之所以能马上知道是Sleuth影响了，是因为一开始都是正常的，加了Sleuth后就出问题了。

在Sleuth中Feign相关的配置是在TraceFeignClientAutoConfiguration中。

可以看到，Sleuth中对Feign Builder也有配置，一种是如果开启了Hystrix就用SleuthHystrixFeignBuilder，如果没有开启就用SleuthFeignBuilder。

在这里打个断点，启动时直接就进来了，这边执行完后Builder对象就有了，所以Sentinel中的自然就不会执行了。

解决方案
发生冲突的根本原因在于两个框架都要对Feign进行扩展，Sentinel扩展是为了再调用的时候可以实现限流熔断等功能。Sleuth扩展是为了使用Feign调用接口的时候可以传递链路跟踪的信息。

要想解决这个问题，要么妥协只用一个框架，这样是最简单的。

要么看看Sleuth后面会不会支持Sentinel，目前可以看到已经支持了Hystrix。

最后一种就是自己改源码，将Sentinel融入到Sleuth中。

SleuthFeignBuilder 中只是对Client做了包装。

SentinelFeign 中只是对Builder做了增强。

所以我们只要把两者结合起来就可以了。

PS：没Star的现在接着Star吧！
项目：https://github.com/yinjihuan/kitty-cloud

基础框架：https://github.com/yinjihuan/kitty

原文地址https://www.cnblogs.com/yinjihuan/p/12730654.html