在我们日常生活中,经常会在淘宝、天猫、京东、拼多多等平台上参与商品的秒杀、抢购以及一些优惠活动,也会在节假日使用12306 手机APP抢火车票、高铁票,甚至有时候还要帮助同事、朋友为他们家小孩拉投票、刷票,这些场景都无一例外的会引起服务器流量的暴涨,导致网页无法显示、APP反应慢、功能无法正常运转,甚至会引起整个网站的崩溃。
我们如何在这些业务流量变化无常的情况下,保证各种业务安全运营,系统在任何情况下都不会崩溃呢?我们可以在系统负载过高时,采用限流、降级和熔断,三种措施来保护系统,由此一些流量控制中间件诞生。例如Sentinel。
Sentinel (分布式系统的流量防卫兵) 是阿里开源的一套用于服务容错的综合性解决方案。它以流量为切入点, 从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性。
Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景, 例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
Sentinel核心分为两个部分:
Sentinel 提供一个轻量级的控制台, 它提供机器发现、单机资源实时监控以及规则管理等功能,其控制台安装步骤如下:
第一步:打开sentinel下载网址
sentinel官网链接
第二步:下载Jar包(可以存储到一个sentinel目录),如图所示:
第三步:启动sentient
在sentinel对应目录,打开命令行(cmd),启动运行sentinel
java -Dserver.port=8180 -Dcsp.sentinel.dashboard.server=localhost:8180 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.2.jar
注意这里默认占用端口号8180,sentinel-dashboard-1.8.2.jar取决你下载的版本,我这里是1.8.2
检测启动过程,如图所示:
启动成功
在IDEA中点击如下位置
点击+,选择脚本文件
取名,选择脚本路径,输入脚本选项
注意,这里最后不仅要写包名,还要写文件所在文件夹的位置
启动效果如下:
第一步:假如Sentinel启动ok,通过浏览器进行访问测试,如图所示:
第二步:登陆sentinel,默认用户和密码都是sentinel,登陆成功以后的界面如图所示:
我们系统中的数据库连接池,线程池,nginx的瞬时并发,MQ消息等在使用时都会跟定一个限定的值,这本身就是一种限流的设计。限流的目的防止恶意请求流量、恶意攻击,或者防止流量超过系统峰值。
第一步:Sentinel 应用于服务消费方(Consumer),在消费方添加依赖如下:
<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
第二步:打开服务消费方配置文件application.yml,添加sentinel配置,代码如下:
第三步:启动服务提供者,服务消费者,然后在浏览器访问消费者url,如图所示:
第四步:刷新sentinel 控制台,检测服务列表,如图所示:
Sentinel的控制台其实就是一个SpringBoot编写的程序,我们需要将我们的服务注册到控制台上,即在微服务中指定控制台的地址,并且还要在消费端开启一个与sentinel控制台传递数据端的端口,控制台可以通过此端口调用微服务中的监控程序来获取各种信息。
我们设置一下指定接口的流控(流量控制),QPS(每秒请求次数)单机阈值为1,代表每秒请求不能超出1次,要不然就做限流处理,处理方式直接调用失败。
第一步:选择要限流的链路,如图所示:
第二步:设置限流策略,如图所示:
第三步:反复刷新访问消费端端服务,检测是否有限流信息输出,如图所示:
当每秒刷新次数大于单机阈值(这里是1),出现如下结果
Sentinel的流控模式代表的流控的方式,默认【直接】,还有关联,链路。
Sentinel默认的流控处理就是【直接->快速失败】
当关联的资源达到阈值,就限流自己。例如设置了关联资源为/ur2时,假如关联资源/url2的qps阀值超过1时,就限流/url1接口(是不是感觉很霸道,关联资源达到阀值,是本资源接口被限流了)。这种关联模式有什么应用场景呢?我们举个例子,订单服务中会有2个重要的接口,一个是读取订单信息接口,一个是写入订单信息接口。在高并发业务场景中,两个接口都会占用资源,如果读取接口访问过大,就会影响写入接口的性能。业务中如果我们希望写入订单比较重要,要优先考虑写入订单接口。那就可以利用关联模式;在关联资源上面设置写入接口,资源名设置读取接口就行了;这样就起到了优先写入,一旦写入请求多,就限制读的请求。例如:
运行结果:
为了演示效果,我们疯狂刷新doRestEcho3网址,然后在一秒内迅速刷新doRestEcho1网址,速度一定要快,不然看不到
说明doRestEcho1被限流了
链路模式只记录指定链路入口的流量。也就是当多个服务对指定资源调用时,假如流量超出了指定阈值,则进行限流。被调用的方法用@SentinelResource进行注解,然后分别用不同业务方法对此业务进行调用,假如A业务设置了链路模式的限流,在B业务中是不受影响的。例如现在设计一个业务对象,代码如下(为了简单,可以直接写在启动类内部):
@Service public class ConsumerService { /** * @SentinelResource描述方法会作为一个限流链路中的叶子节点,这里后面可以输入值,作为显示名称 * @return */ @SentinelResource public String doGetResource() { //这里后续可以写对数据库资源的访问 return "Get resource"; } }
接下来我们在/consumer/doRestEcho1对应的方法中对ConsumerService中的doGetResource方法进行调用(应用consumerService对象之前,要先在doRestEcho01方法所在的类中进行consumerService值的注入)。例如:
其路由规则配置如下:
这里sentinel_spring_web_context是入口
运行结果:
快速刷新页面,即每秒刷新次数大于单机阈值
后台显示:
说明,流控模式为链路模式时,假如是sentinel 1.7.2以后版本,Sentinel Web过滤器默认会聚合所有URL的入口为sentinel_spring_web_context,因此单独对指定链路限流会不生效,需要在application.yml添加如下语句来关闭URL PATH聚合,例如:
没添加前,再访问doRestEcho2
添加后
当一个资源被两个网址使用
这里两个网址都使用了doGetResource()资源,这里我们需要对doRestEcho1这个网址使用这个资源进行限制
运行结果,
当快速刷新这个网址时
可见成功限流
对doRestEcho2不会用任何影响
默认是快速失败
流量达到指定阀值,直接返回报异常。(类似路前方坍塌,后面设定路标,让后面的车辆返回)
WarmUp也叫预热,根据codeFactor(默认3)的值,(阀值/codeFactor)为初始阈值,经过预热时长,才到达设置的QPS的阈值,假如单机阈值为100,系统初始化的阈为 100/3 ,即阈值为33,然后过了10秒,阈值才恢复到100。这个预热的应用场景,如:秒杀系统在开启的瞬间,会有很多流量上来,很有可能把系统打死,预热方式就是把为了保护系统,可慢慢的把流量放进来,慢慢的把阈值增长到设置的阈值。
从字面上面就能够猜到,匀速排队,让请求以均匀的速度通过,阈值类型必须设成QPS,否则无效。比如有时候系统在某一个时刻会出现大流量,之后流量就恢复稳定,可以采用这种排队模式,大流量来时可以让流量请求先排队,等恢复了在慢慢进行处理。
除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。由于调用关系的复杂性,如果调用链路中的某个资源不稳定,最终会导致请求发生堆积。
Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时(例如调用超时或异常比例升高),对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联错误。当资源被降级后,在接下来的降级时间窗口之内,对该资源的调用都自动熔断(默认行为是抛出 DegradeException)。
有的公司两者一个意思,而有的公司还是会对两者进行区分
**降级:**当当前的服务出现异常或者超时时,将当前的服务关闭
熔断: a-b-c 三个服务器进行连接,当b出现超时或者异常时,a服务则会将b关闭,优先将资源给需要的。
修改ConumserController 类中的doRestEcho01方法,假如没有创建即可,基于此方法演示慢调用过程下的限流,代码如下:
//构建一个线程安全并且可实现根据点击自增自减操作的整数对象 private AtomicLong aLong = new AtomicLong(1); //http://ip:port/consumer/doResultEcho1 @GetMapping("/consumer/doRestEcho1") public String doRestEcho1() throws InterruptedException { long num = aLong.getAndIncrement(); if (num % 2 == 0) { //系统设计时会认为响应设计超过200毫秒为慢调用 Thread.sleep(200); //模拟耗时操作 } //直接通过业务方法访问相关资源(现在不需要关心什么返回值) consumerService.doGetResource(); System.out.println("==doResultEcho1()=="); //提供零服务提供方API(http://ip:port/path) //1.定义要调用的API String url = "http://localhost:8082/provider/echo/" + appName; //2.谁去访问这个API //restTemplate; return restTemplate.getForObject(url,String.class); //封装 //1)狭义:属性私有化,方法能公开则公开 //2)广义:一个系统由哪些服务构成,一个服务由哪些模块构成,一个模块由哪些对象构成,一个对象由哪些属性和方法构成 }
第一步:服务启动后,选择要降级的链路,如图所示:
第二步:选择要降级的链路,如图所示:
这里表示熔断策略为慢调用比例,表示链路请求数超过3时,假如平均响应时间假如超过200毫秒的有30%,则对请求进行熔断,熔断时长为5秒钟,5秒以后恢复正常。
第三步:对指定链路进行刷新,多次访问测试,假如出现了降级熔断,会出现如下结果:
过5s后在刷新才可以正常显示
我们也可以进行断点调试,在DefaultBlockExceptionHandler中的handle方法内部加断点,分析异常类型,假如异常类型为DegradeException则为降级熔断。
系统提供了默认的异常处理机制,假如默认处理机制不满足我们需求,我们可以自己进行定义。定义方式上可以直接或间接实现BlockExceptionHandler接口,并将对象交给spring管理。
/**自定义限流异常处理对象 * 为什么要自己定义? * 默认的异常处理不能满足我们的要求*/ @Component public class ServiceBlockExceptionHandler implements BlockExceptionHandler { /**一旦服务被限流或降级了,sentinel系统底层提供的拦截器会 * 调用此方法对异常进行处理*/ @Override public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, BlockException e) throws Exception { //方案1:异常继续抛出 //throw e; //方案2:对异常内容进行处理(例如返回给客户端一个可以看得懂的信息) //思考: //1)向客户端输出数据(写数据)用什么?输出流对象 //2)如何获取输出流对象?(标准JAVAEE规范中,要借助HttpServletResponse) //3)当向客户端输出数据时,除了业务响应数据外,还要干什么? //设置响应数据的编码 httpServletResponse.setCharacterEncoding("utf-8"); //告诉浏览器服务端向它响应的数据类型,以及以什么编码进行显示 //httpServletResponse.setContentType("text/html;charset=utf-8"); httpServletResponse.setContentType("application/json;charset=utf-8"); //响应业务数据 PrintWriter out = httpServletResponse.getWriter(); Map<String,Object> map = new HashMap<>(); map.put("status",429); if (e instanceof DegradeException) { //DegradeException降级(熔断)异常 //out.println("<h2>服务暂时不可用</h2>"); map.put("message","服务暂时不可用"); } else { //out.println("<h2>访问太频繁,稍等片刻再访问</h2>"); map.put("message","访问太频繁,稍等片刻再访问"); } String jsonStr = new ObjectMapper().writeValueAsString(map); //转化为json字符串 out.println(jsonStr); out.flush();//所有字符流都要刷新 } }
显示结果:
Sentinel熔断降级支持慢调用比例、异常比例、异常数三种策略。
慢调用指耗时大于阈值RT(Response Time)的请求称为慢调用,阈值RT由用户设置。其属性具体含义说明如下:
慢调用逻辑中的状态分析如下:
当资源的每秒请求数大于等于最小请求数,并且异常总数占通过量的比例超过比例阈值时,资源进入降级状态。其属性说明如下:
异常比例中的状态分析如下:
当资源近1分钟的异常数目超过阈值(异常数)之后会进行服务降级。注意,由于统计时间窗口是分钟级别的,若熔断时长小于60s,则结束熔断状态后仍可能再次进入熔断状态。其属性说明如下:
何为热点?热点即经常访问的数据。比如:
第一步:定义热点业务代码,如图所示:
//http://localhost:8090/consumer/findById?id=10 @SentinelResource(value = "res") @GetMapping("/consumer/findById") public String doFindById(Integer id,String name) { return "Resource id is " + id; }
第二步:服务启动后,选择要限流的热点链路,如图所示
第三步:设置要限流的热点,如图所示:
热点规则的限流模式只有QPS模式(这才叫热点)。参数索引为@SentinelResource注解的方法参数下标,0代表第一个参数(id),1代表第二个参数(name)。单机阈值以及统计窗口时长表示在此窗口时间超过阈值就限流。表示两秒中只允许出现1次。
第四步:多次访问热点参数方法,前端会出现如下界面,如图所示:
然后,在后台出现如下异常表示限流成功。
而第二个参数没有限制,所以无论怎么刷新,都不会被限流
其中,热点参数其实说白了就是特殊的流控,流控设置是针对整个请求的;但是热点参数他可以设置到具体哪个参数,甚至参数针对的值,这样更灵活的进行流控管理。
一般应用在某些特殊资源的特殊处理,如:某些商品流量大,其他商品流量很正常,就可以利用热点参数限流的方案。
配置参数例外项,如图所示
这里表示参数值为5时阈值为100,其它参数值阈值为1,例如当我们访问http://ip:port/consumer/doRestEcho1?id=5时的限流阈值为100。
访问id=5时,2s内允许100次,所以我们手动刷新测试的话不会限流
如果为其他任然会限流
系统在生产环境运行过程中,我们经常需要监控服务器的状态,看服务器CPU、内存、IO等的使用率;主要目的就是保证服务器正常的运行,不能被某些应用搞崩溃了;而且在保证稳定的前提下,保持系统的最大吞吐量。
长期以来,系统自适应保护的思路是根据硬指标,即系统的负载 (load1) 来做系统过载保护。当系统负载高于某个阈值,就禁止或者减少流量的进入;当 load 开始好转,则恢复流量的进入。
Sentinel的系统保护规则是从应用级别的入口流量进行控制,从单台机器的总体 Load、RT、入口 QPS 、线程数和CPU使用率五个维度监控应用数据,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。如图所示:
其中,
系统对所有服务都生效
很多时候,我们需要根据调用方来限制资源是否通过,这时候可以使用 Sentinel 的黑白名单控制的功能。黑白名单根据资源的请求来源(origin)限制资源是否通过,若配置白名单则只有请求来源位于白名单内时才可通过;若配置黑名单则请求来源位于黑名单时不通过,其余的请求通过。例如微信中的黑名单。
sentinel可以基于黑白名单方式进行授权规则设计,如图所示:
黑白名单规则(AuthorityRule)非常简单,主要有以下配置项:
/** * 定义一个请求源解析对象,基于此对象对请求中指定数据进行解析 * 然后Sentinel底层会对此接口方法的返回值基于规则的定义进行 */ @Component public class DefaultRequestOriginParser implements RequestOriginParser { //解析请求源数据 @Override public String parseOrigin(HttpServletRequest request) { //获取请求参数数据,参数名可以自己写 http://ip:port/path?orgin=aap1 return request.getParameter("origin"); } }//授权规则中的黑白名单的值,来自此方法的返回值
第二步:定义流控规则,如图所示:
第三步:执行资源访问,检测授权规则应用,当我们配置的流控应用值为app1时,假如规则为黑名单,则基于http://ip:port/path?origin=app1的请求不可以通过,会出现如下结果:
同样app2也不行
不在黑名单的app3就可以
第四步:设计过程分析,如图所示:
同样,黑名单也可以是ip地址,请求头等
ip地址:
/** * 定义一个请求源解析对象,基于此对象对请求中指定数据进行解析 * 然后Sentinel底层会对此接口方法的返回值基于规则的定义进行 */ @Component public class DefaultRequestOriginParser implements RequestOriginParser { //解析请求源数据 @Override public String parseOrigin(HttpServletRequest request) { //获取请求参数数据,参数名可以自己写 //获取访问请求中的ip地址,基于ip地址进行黑白名单设计 String ip = request.getRemoteAddr(); System.out.println("ip:" + ip); return ip; } }//授权规则中的黑白名单的值,来自此方法的返回值
这里localhost是0:0:0:0:0:0:0:1
请求头
/** * 定义一个请求源解析对象,基于此对象对请求中指定数据进行解析 * 然后Sentinel底层会对此接口方法的返回值基于规则的定义进行 */ @Component public class DefaultRequestOriginParser implements RequestOriginParser { //解析请求源数据 @Override public String parseOrigin(HttpServletRequest request) { //获取请求参数数据,参数名可以自己写 //获取请求头中的数据,基于请求头中token值进行限流设计 String token = request.getHeader("token"); return token; } }//授权规则中的黑白名单的值,来自此方法的返回值
由于无法在浏览器中直接指定请求头,所以使用小工具
mg不在黑名单内
总之,Sentinel可为秒杀、抢购、抢票、拉票等高并发应用,提供API接口层面的流量限制,让突然暴涨而来的流量用户访问受到统一的管控,使用合理的流量放行规则使得用户都能正常得到服务。