微服务系统保障选择Hystrix还是Sentinel？

Hystrix

在spring cloud系统中，随着业务量的增加，默认选用Hystrix作为系统的熔断降级方案。由于，系统中使用security jwt方式做权限认证，服务之间feign使用RequestTemplate在header中传递token。开启Hystrix后，由于默认的隔离机制是线程池，在调用下游服务时，会重新创建线程，RequestContextHolder通过ThreadLocal无法获取token。如何让token传递到下游服务呢？

1. 可以使用hystrix信号量的机制进行服务的容错，该种方式超时控制会失效，如果下游服务超时或者崩溃，过多的请求访问都会阻塞，造成服务雪崩。一般都不推荐该种方式。
2. 扩展Hystrix在创建新的线程时，把当前线程上下文存储的数据设置到新的线程。可以参考开启hystrix：feign.hystrix.enabled=true时， RequestContextHolder.getRequestAttributes()为空。

以上两种方式都感觉不是很完美，于是，决定使用Sentinel进行替换。

Sentinel

Sentinel也能实现服务的熔断和降级。能够对并发线程数和超时时间进行控制，在功能上实现Hystrix一致的效果。

Sentinel对于资源的熔断和降级操作是通过定义拦截器，采用责任链的模式实现。Sentinel 的核心骨架，将不同的 Slot 按照顺序串在一起（责任链模式），从而将不同的功能（限流、降级、系统保护）组合在一起。slot chain 其实可以分为两部分：统计数据构建部分（statistic）和判断部分（rule checking）。

Hystrix 的资源模型设计上采用了命令模式，将对外部资源的调用和 fallback 逻辑封装成一个命令对象（HystrixCommand / HystrixObservableCommand）。其隔离策略采用线程池隔离（Bulkhead Pattern）和信号量隔离。其不足之处如下：

1. 线程池隔离策略，过多的线程池会非常影响性能，增加了线程切换的成本，此外，使用线程池上下文的场景也会失效。
2. 信号量隔离，通过并发数来控制服务请求，但是，无法设置超时时间，容易造成服务的雪崩。

Sentinel官网关于Hystrix的详细对比可以参考，Sentinel 与 Hystrix 的对比。

Sentinel的优势：

1. 限流，Sentinel可以以不同的运行指标（如 QPS、并发调用数、系统负载等）为基准，对资源调用进行流量控制，还可以对热点数据，黑白名单进行控制。Hystrix没有限流策略，如果在微服务中使用限流策略，需要引用开源的限流算法，例如漏桶算法，令牌桶算法。
2. 使用简单，使用 Sentinel 来进行资源保护，主要分为几个步骤:1:定义资源，2:定义规则，3：检验规则是否生效。对大部分的主流框架，例如 Web Servlet、Dubbo、Spring Cloud、gRPC、Spring WebFlux、Reactor 等都做了适配，只需要引入对应的依赖即可方便地整合 Sentinel。Sentinel 的理念是开发者只需要关注资源的定义，当资源定义成功后可以动态增加各种流控降级规则。