Sentinel是SpringCloudAlibaba提供的用来做服务保护的框架,而服务保护的常见手段就是限流和熔断降级。在大型分布式系统里面,由于微服务众多,所以服务之间的稳定性需要做特别关注,Sentinel的核心包就提供了从多个维度去保护服务稳定的策略,而且这些保护策略都可以连接上Sentinel的控制台,在可视化界面进行配置,我们把这些保护策略可以称为规则,配置的这些保护规则也可以存储到Zookeeper、Nacos等等具有配置中心功能的中间件中,而且Sentinel还配置了多种微服务架构,比如SpringCloud、Dubbo等,如下图所示:
我们可以看一下Sentinel的工作原理,加上分布式系统中有很多微服务,每个微服务中都有很多资源需要我们进行保护,什么是资源呢,其实万物皆可为资源,它可以是一个HTTP请求,也可以是一个远程调用,或者是一段业务逻辑代码,也可以是访问数据库的一些方法,每个应用都有非常多的资源,我们只需要引入Sentinel客户端,这些客户端就可以连上Sentinel的控制台,在Sentinel控制台里面可以对每一种资源的规则进行定义,比如限流规则,熔断降级规则,黑白名单等等,当然这些规则一般由运维人员进行定义,定义的这些规则可以存储到Nacos、Zookeeper等这些配置中心,当然存在内存也没问题,只不过重启就失效了,而且如果这些规则发生了变更,Sentinel控制台还可以实时把这些规则推送给每个微服务,这样我们每次访问资源的时候,Sentinel客户端就会来检测每种资源的规则,然后判断是不是违背这些规则,如果没有违背则放行,如果违背就拒绝服务,通过这种手段来保护系统的稳定性,架构原理图如下:
在这个图里面和我们编码相关的就两个,一个是资源,一个是规则。
而使用Sentinel想要定义一个资源也非常简单:
定义好了资源,就需要在Sentinel的控制台来定义保护这些资源的规则,Sentinel提供了上面的规则,第一种流量控制,就是我们常说的限流,比如请求量一大,如果我们把所有请求都接收过来在后台进行处理,有可能导致这个微服务所在的机器资源耗尽,所以可以对请求进行限流,比如每秒只允许通过100个请求,超出的请求全部拒绝掉,这样的话,即使上万并发,后台也只处理100个,不至于后台崩了。第二种规则叫熔断降级,这就是防服务雪崩的,而且在OpenFeign的时候也演示了一旦远程调用失败去走兜底数据。第三种规则叫系统保护,可以根据当前机器是CPU负载、内存使用率,看到CPU太忙了,可以限制请求流量进入。第四种规则叫来源访问控制,只允许哪些上游来访问下游资源。第五种规则叫定义热点参数,这个后面细说。
总之一句话,想要使用Sentinel,你要想清楚要保护哪些资源,这些资源怎么找到,是通过自动适配发现的还是通过编程定义的还是声明式的。有了这些资源后,再定义各种保护规则,当这两个定义好后,Sentinel就可以进行工作了。
它的工作原理是,用户去来访问一个资源,比如访问一个HTTP请求,假设就是创建订单,而这些资源我们给它定义了一个规则,每次访问的时候Sentinel就会检查这些规则,假设我们定义一个流量控制规则,每秒只能通过一个请求,对于这个规则的检查就会出现两种情况,是否违法了这些规则,如果没有违法这次请求就放行,如果违反了这些规则,Sentinel就会抛出异常,对于这个异常我们就要进行针对性的处理,这就要看我们有没有编写兜底处理的方法,如果没有就抛出错误,如果编写了兜底处理,比如OpenFeign的fallback兜底回调,就会返回兜底数据。详细流程如下图:
通过这个原理图我们知道,在Sentinel的使用中我们关注三点,第一点怎么定义一个资源,第二点定义资源的保护规则,第三点一旦违反了规则,怎么处理异常。
整合-基础场景
先做第一步,启动一个Sentinel Dashboard控制台,方便我们在控制台定义控制资源的一些规则,在官网下载sentinel-dashboard-1.8.8.jar ,然后启动 sentinel-dashboard:
启动后访问:
默认账号和密码都是sentinel。
因为还没有任何微服务接入sentinel,所以在控制台里面没有显示任何数据,接入后就会有所有的微服务列表。
第二步,给微服务整个sentinel场景,并配置链接上sentinel控制台,那这个应用的所有资源,通过注解或代码埋点的这些资源,都可以在控制台定义它们的规则。
我们之前在学习OpenFeign的时候,由于已经整合了sentinel,只不过当时sentinel依赖只放到了order里面,由于每个微服务都需要被保护起来,所以我们直接在services里面统一引入sentinel依赖。引入好依赖,这样每个微服务都需要配置连接上sentinel控制台,我们在order配置文件中配置连接sentinel的地址:
由于sentinel默认用的是懒加载机制,整合之后,只有我们访问了请求,控制台才能显示出应用的信息,所以为了方便起见,可以让它提前加载,在sentinel配置中把eager设置为true,就可以项目一启动,自动连上sentinel控制台:
spring:cloud:openfeign:client:config:default:logger-level: fullconnect-timeout: 1000read-timeout: 2000service-product:logger-level: fullconnect-timeout: 3000read-timeout: 5000sentinel:transport:dashboard: localhost:8080eager: true
# response-interceptor:
# com.example.order.interceptor.XTokenRequestInterceptor
# retryer: feign.retryer.Defaultfeign:sentinel:enabled: true
每个服务都配置好即可。
然后我们启动订单和商品两个微服务。首先看它们能不能连上sentinel控制台,将自己的应用信息正确显示,启动后刷新控制台:
这样在这个控制台里面就可以配置很多的规则,但是这些规则都是对资源配置的,那什么是资源呢?我们一起来看看它的默认行为,它把系统所有web接口都认为的资源,包括openfeign的远程调用也认为的一个资源,或者我们用注解和编程的方式都可以定义资源,那么接下来就以创建订单为例,由于创建订单是一个web请求,所以谁来发送web请求,会走创建订单服务,创建订单服务里面又会远程调用查询商品,假设认为创建订单这个方法是一个资源,我将来想保护它,对它进行一些流控等一些设置,那么可以用最简单的方式,使用一个注解叫@SentinelResource(value = “createOrder”)
重新启动订单服务,然后发送一个创建订单的请求:
在sentinel控制台有个簇点链路就会看到这个调用过程:
首先我们发送了一个create请求,它认为create是一个资源,create里面又调用了createOrder,它认为这个也是一个资源,这个资源是我们通过注解定义的,而create请求是sentinel自动勘测的一个web接口,而在createOrder里面又调用了商品的接口,也是可以被控制的资源。只要有了这些资源,我们可以对任意资源进行控制各种规则,我们先来测试流控:
点击新增后就可以在流控规则中看到了:
我们先测试一下,如果刷慢一点,每秒访问一个,发现都正常:
如果我刷新快一点,就返回一个默认错误:
异常处理-web接口
从上面可以看到sentinel每秒只会放行1个请求,放行的请求才会执行目标方法的创建订单,而被阻塞的请求,目标方法是不会被执行的,这样就不会占用系统资源,即使高并发的请求,只有少量的目标方法执行,那就不会导致服务雪崩的问题,但是现在还有一个问题,如果一旦请求被限制后,返回的是默认sentinel错误提示页,而我们一般大型的系统都是前后分离的,后台微服务要给前端返回json数据,这就牵扯到sentinel的异常处理机制,在sentinel里面异常处理是一个比较复杂的流程,
如果我们想要改掉默认的web页面显示的异常信息,就要自定义一个BlockExceptionHandler,我们先来解决web接口的异常处理方式。我们自己写一个BlockExceptionHandler,只要把它放到容器中就可以生效:
我们先在model模块中自定义一个通用的返回对象R:
package com.example.common;import lombok.Data;@Data
public class R {private Integer code;private String msg;private Object data;public static R ok() {R r = new R();r.setCode(200);return r;}public static R ok(String msg, Object data) {R r = new R();r.setCode(200);r.setMsg(msg);r.setData(data);return r;}public static R error() {R r = new R();r.setCode(500);return r;}public static R error(Integer code, String msg) {R r = new R();r.setCode(