Sentinel整理和代码剖析v1

写前打个鸡血:流水不争先,争的是滔滔不绝

为什么要开始整理和写东西?

维护了一段时间sentinel,平时在做其他事情的时间比较多,虽然做了一些改造,但是还有一些细节没来的看,周末有空整理整理实现逻辑和加深自己的一下理解

1. Sentinel是什么?

解释sentinel前,我们先说下hystrix,大家一定不会陌生,hystrix提供了容错和熔断机制,极大的提升了服务的可靠和可用性。sentinel是alibaba开源的,承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

对比下hystrix和sentinel的功能特性:


原图地址(https://github.com/alibaba/Sentinel/wiki/Guideline:-%E4%BB%8E-Hystrix-%E8%BF%81%E7%A7%BB%E5%88%B0-Sentinel#%E5%8A%9F%E8%83%BD%E5%AF%B9%E6%AF%94)

Sentinel优势:

1.支持更多的熔断降级策略

2.限流方面:支持单个接口限流,同时支持关联和整个链路限流

关联场景:对数据库同一个字段的读操作和写操作存在争抢,读的速度过高会影响写得速度,写的速度过高会影响读的速度。如果放任读写操作争抢资源,则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢,举例来说,read_db 和 write_db 这两个资源分别代表数据库读写,我们可以给 read_db 设置限流规则来达到写优先的目的:设置 strategy 为 RuleConstant.STRATEGY_RELATE 同时设置 refResource 为 write_db。这样当写库操作过于频繁时,读数据的请求会被限流。

链路场景:方法调用test1()->test2()->test3(),test3方法的链路头部节点为test1,所以当test1达到设定的test3设定的阈值后,请求将被限制

3.流量整形,支持预热和匀速排队模式。

预热模式:防止瞬间流量过大,直接把系统击垮,这边参考了google guava库中的RateLimiter的Warmup模式实现

匀速排队:常见的一种场景是队列消费数据,可能很长一段时间没有数据进来,或者在某个点进来一大批数据,但是如果数据超过qps会被限流,所以这边可以采用匀速排队模式进行处理

4.系统自适应保护:获取系统负载,cpu使用率等等

5.控制台:结合配置中心或者注册中心,实时更改配置

6.还有一点,hystrix官方已停止维护,不会升级和迭代

说了这么多,老套路还是直接上官方文档(https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D

2.话不多说,先看效果


流控规则


新增流控规则

目前支持:流控规则,降级规则,热点规则,系统规则和认证授权规则5种(下章会讲解具体的源码实现)。

实时监控和机器列表,生产上正式使用的时候都需要进行改造,实时监控默认从客户端拉取5分钟之内的指标集合,存储在内存中,默认没有实现持久化,不能查询历史指标

机器列表:客户端默认10s一次心跳上报,这个可以和公司内部的注册中心做个整合,不需要sentinel单独去上报。

3.配置的持久化

开源版本默认限流规则是存在本地内存中的,每次服务的重启规则将全部失效,所以生产环境去用时,必须先持久化配置规则。


动态规则持久化

原来的实现方式,sentinel Dashboard直接将规则推送给每一台机器,缺点:不能持久化和存在一致性问题

改造:中间加入配置中心,数据持久化和保证数据一致性,我们内部用的是Apollo config,当然zookeeper,nacos都是一个不错的选择,而且sentinel现在已经默认支持以上三种数据源的接入

dashboard配置------>config center---->客户端服务

总结:dashboard将数据持久化到配置中心,配置中心推送到客户端服务上

4.Sentinel源码剖析

我们先看个简单的demo:


demo

SphU.entry可以理解为获取一个令牌,如果可以拿到执行业务方法,拿不到直接抛出BlockException,可以自定义处理操作。

整体的流程:在方法执行前获取令牌--->拿到令牌执行业务逻辑--->方法执行后执行exit清理回收操作

面向切面编程,可进行统一封装处理,@SentinelResource就是对其封装处理,注意entry和exit必须成双成成对,

而且要遵循FILO先进后出,类似于stack,entry1->entry2->exit2->exit1

那么sentinel是如何实现以上5种规则的呢?

流控规则,降级规则,热点规则,系统规则和认证授权规则

Sentinel采用了职责链的设计模式,每一个模块负责各自的逻辑。职责链像质量检测一样,每一个部门只负责一个小块的检测,第一个部门检测自己模块的质量没有问题,就下发给下一个部门,去检查对应的部件,如果有一个部件不合格了,整个产品就会被认为问题产品,后续流程就不用执行了直接打回

目前1.8.0最新加载顺序做了调整:


Slot加载顺序

前面4个主要是负责统计数据和日志用的,为下面4个slot提供支持的,每个slot对应一个功能

AuthoritySlot:负责认证授权规则

SystemSlot:负责系统自适应保护规则

FlowSlot:负责限流规则保护

DegradeSlot:负责降级规则保护

ParamFlowSlot:参数限流,ParamFlowSlot 核心包core下面没有写,它是以extension的方式集成的,需要的话引入对应的jar即可

具体每个Slot的实现,将会专门写一个章节重点讲解

你可能感兴趣的:(Sentinel整理和代码剖析v1)