深入理解Sentinel

随着微服务的流行，很多公司也在逐渐的将单体架构项目重构为微服务项目，单体架构微服务化后也将面临更多的挑战。服务的调用错综复杂，如何保护自身不被其它服务打垮也是项目微服务化后重点需要考虑的问题。

笔者想跟大家分享笔者经历的一次服务雪崩事故，分析导致此次服务雪崩事故的原因。或许大多数读者都有过这样的经历，这是项目给我们上的一次非常宝贵的实战课程。

上一篇笔者跟大家分享了一个真实的服务雪崩的故事，也分析了造成服务雪崩的真正原因，那么，如何才能避免服务雪崩的出现呢？

为什么选择Sentinel？选择Sentinel与Hystrix通常第一步都是通过对比两者优缺点，Sentinel与Hystrix的对比结果是作为我们选择Sentinel还是Hystrix的直观参考。

Sentinel是基于滑动窗口实现的实时指标数据统计，要深入理解Sentinel的限流实现原理，首先我们得要了解其指标数据统计的实现，例如，如何统计QPS。

了解Sentinel的一些概念：资源、规则、降级，资源是 Sentinel 的关键概念，Sentinel围绕资源设定规则，降级则是拒绝掉超阈值的流量。

上一篇我们简单了解了ProcessorSlot，并且将Sentinel提供的所有ProcessorSlot分成两类，一类是辅助完成资源指标数据统计的ProcessorSlot，一类是实现降级功能的ProcessorSlot。

SPI全称是Service Provider Interface，直译就是服务提供者接口，是一种服务发现机制，是Java的一个内置标准，允许不同的开发者去实现某个特定的服务。

了解节点选择器NodeSelectorSlot、ClusterNode构造器ClusterBuilderSlot。NodeSelectorSlot负责为资源的首次访问创建DefaultNode，以及维护Context.curNode和调用树。

StatisticSlot才是实现资源各项指标数据统计的ProcessorSlot，它与NodeSelectorSlot、ClusterBuilderSlot组成了资源指标数据统计流水线，分工明确。

从这篇开始，我们学习Sentinel提供的几个实现降级功能的ProcessorSlot，这些ProcessorSlot检查实时指标数据是否达到规则所配置的阈值，当达到阈值时，或抛出Block异常或采取流量效果控制策略处理超阈值的流量。

QPS限流的默认算法是通过判断当前时间窗口（1秒）的pass（被放行的请求数量）指标数据判断，如果pass总数已经大于等于限流的QPS阈值，则直接拒绝当前请求，每通过一个请求当前时间窗口的pass指标计数加1。

冷启动并非只在应用重启时需要，在一段时间没有访问的情况下，连接池存在大量过期连接需要待下次使用才移除掉并创建新的连接、一些热点数据缓存过期需要重新查数据库写入缓存等，这些场景下也需要冷启动。

Sentinel支持对同一个资源配置多个相同类型或不同类型的规则，在配置了限流规则的基础上，我们还可以为同一资源配置熔断降级规则。当接口的QPS未达限流阈值却已经有很多请求超时的情况下，就可能达到熔断降级规则的阈值从而触发熔断，这就能很好的保护服务自身。

黑白名单过滤功能更像是一种授权机制，它简单的将权限分为有权限和无权限两种情况，如果支持冲突，可使用优先级策略解决冲突问题。

开关降级在我们公司的电商项目中是每个微服务都必须支持的一项功能，主要用于活动期间、每日流量高峰期间、主播带货期间关闭一些无关紧要功能，降低数据库的压力。

经过前面的学习，我们知道，为资源配置各种规则可使用Sentinel提供的各种规则对应的loadRules API，但这种以编码的方式配置规则很难实现动态修改。

为了节省这些步骤，Sentinel提供了对主流框架的适配，如适配Spring MVC、Webflux、Dubbo、Api Gateway等框架。

由于请求倾斜的存在，分发到集群中每个节点上的流量不可能均匀，所以单机限流无法实现精确的限制整个集群的整体流量，导致总流量没有到达阈值的情况下一些机器就开始限流。

集群限流，我们可以结合令牌桶算法去思考，服务端负责生产令牌，客户端向服务端申请令牌，客户端只有申请到令牌时才能将请求放行，否则拒绝请求。

本篇我们回顾Sentinel的源码，看看Sentinel在性能方面所做出的努力，最后使用JMH做个简单的基准测试，看看Sentinel表现如何，在此之前也会详细介绍JMH的使用。

从官方文档来看，该版本的最大亮点是对熔断降级功能进行了重构。旧版本的熔断降级功能对慢调用并不友好，而新版本改善了这个问题。