限流和降级(下) | 如何打造平台稳定性能力(二)

摘要: 上一期我们谈到了阿里巴巴早期是通过通过在 Nginx 上实现的扩展组件TMD(taobao missile defense淘宝×××防御系统)实现了接入层限流的主要工作,TMD系统可通过域名类限流、cookie限流、黑名单以及一些安全策略等很好的实现了在接入层的限流措施。

上一期我们谈到了阿里巴巴早期是通过通过在 Nginx 上实现的扩展组件TMD(taobao missile defense淘宝×××防御系统)实现了接入层限流的主要工作,TMD系统可通过域名类限流、cookie限流、黑名单以及一些安全策略等很好的实现了在接入层的限流措施。

但对于服务层,TMD就无能为力了。对于实现服务的限流控制,传统的实现方式通常用spring的AOP机制,对需要限流的接口定义一个advice拦截器,但这套方案在实际应用场景中还是会发现不少问题。

一、Sentinel 简介
第二期我们将分享到阿里巴巴是如何解决服务层限流时遇到的问题的。在今年7月底的Aliware Open Sourec深圳站的活动上,阿里巴巴宣布开源面向分布式服务架构的轻量级限流降级框架 Sentinel。Sentinel正如它英文的意思“哨兵”一样,为整个服务化体系的稳定运行行使着警戒任务,是对资源调用的控制平台,主要涵盖了授权、限流、降级、调用统计监控四大功能。

授权:通过配置白名单和黑名单的方式分布式系统的接口和方法进行调用权限的控制;
限流:对特定资源进行调用的保护,防止资源的过度使用;
降级:判断依赖的资源的响应情况,但依赖的资源响应时间过长时进行自动降级,并且在指定的时间后自动恢复调用;
监控:提供了全面的运行状态监控,实时监控资源的调用情况,如QPS、响应时间、限流降级等信息;
Sentinel 平台有两个基础概念,资源和策略,对特定的资源采取不同的控制策略,起到保障应用稳定性的作用。Sentinel 提供了多个默认切入点,比如服务调用时,数据库、缓存等资源访问时,覆盖了大部分应用场景,保证对应用的低侵入性,同时也支持硬编码或者自定义AOP的方式来支持特定的使用需求。

二、Sentinel 限流的实现原理
Sentinel 平台架构图如下,需要通过Sentinel 实现限流功能的应用中都嵌入Sentinel 客户端,通过Sentinel 客户端中提供对服务调用和各资源访问缺省实现的切入点,使得应用完全不需要对实现限流的服务或资源进行单独的AOP配置和实现,同时不仅可以限制自己的应用调用别的应用,也可以限制别的应用调用我的应用。通过这些资源埋点实时计算当前服务的QPS,也可通过现有的监控系统获取到应用所在服务器的相关系统监控指标,用于限流规则配置中的阀值比对。

?Sentinel 平台架构示意图

Sentinel控制台会从客户端拉取资源实时的运行监控数据如QPS、响应时间等,并展示在控制台的监控面板上。控制台给运维人员提供了针对服务、缓存、数据库等资源访问设置各种限流规则,并将设置好的规则发送到规则配置中心后,再有服务器将规则推送到相关的Sentinel客户端,让设置的规则最终在应用运行状态是时快速生效。

三、Sentinel 降级的实现原理
Sentinel平台除了限流的核心功能外,还提供了降级的功能。我们知道,在服务调用链上,存在服务间的强弱依赖,即有些业务请求处理过程中,有些服务是否正常被调研或成功处理了服务请求,对于整个业务请求不会产生决定性的影响,比如交易链路中快递优惠这个服务,这类服务调用链中就会标记为弱依赖的服务。

设想一下,如果在双11活动启动后,大量的用户订单请求涌入平台,此时发现平台的整体水位已经像平台最大处理能力的水位逼近时,除了限流可以起到第一层的保护作用外,我们还可以将那些之前标记为弱依赖的服务平滑下线,也就是让订单创建的处理流程中去掉那些弱依赖的服务调用,达到将节省出的系统资源更好地服务于核心服务的运行;又或者在大促时,某核心服务依赖某一个非核心的服务,但发现因为这个非核心服务的处理性能和服务响应时间较长,导致了当前核心服务的处理出现了瓶颈,这时为了保证核心服务的正常处理,就需要在核心服务业务逻辑中对于那个非核心服务的调用暂时停止。这样类似的场景就称为服务降级,即从服务调用者的角度,对所依赖的下游服务采取停止调用的措施,以保证当前服务的处理效率。

要实现服务降级,需要在应用或服务实现中,首先留下可供服务降级进行服务是否调用切换的逻辑。一般在代码中采用static值的方式,作为业务逻辑分支的判断条件,通过对这些static值的修改,实现服务调用逻辑的变化。同样可以通过Sentinel控制台提供的降级规则的配置功能,当对某个服务的方法响应时间一旦超过阀值后,就意味着调用的这个服务已经出现了处理性能的问题,则会自动切换到降级模式,降级持续的时间可自定义设置。

四、Sentinel 限流的实现原理
总结来说,Sentinel平台所提供的限流和降级功能,是今天阿里巴巴集团如此庞大、复杂的服务化平台稳定运行的关键,不管是在双11这样的大促活动中,还是几乎每天都有基于服务化体系构建起来的新兴业务上线,整个服务化平台能够稳定运行直观重要。从技术角度来说,企业如果要构建自身的服务化平台,如何保障平台稳定性运行的重要能力是服务化平台建设中一定要考虑的问题。

限流和降级是从服务自身做好保护的角度来避免平台级的故障。在分布式服务环境下, 我们不可忽略的一个问题是最大程度的增加机器的利用率,通常会采用超配的方式,但这个过程中往往会出现超配服务器上的应用对资源进行争抢,使得个别或局部应用出现服务响应慢甚至挂起,从而给整个业务链路带来更大的风险的情况。此时,流量调度的角色是至关重要的。下一期我们将从流量调度的角度看看如何提升平台的稳定性。

原文链接

本文为云栖社区原创内容,未经允许不得转载。

原文地址:http://blog.51cto.com/13952056/2169580

时间: 2024-10-06 20:51:14

限流和降级(下) | 如何打造平台稳定性能力(二)的相关文章

熔断,限流,降级

https://www.cnblogs.com/raoshaoquan/articles/6636067.html https://www.cnblogs.com/DengGao/p/rateLimit.html https://blog.csdn.net/aa1215018028/article/details/81700796 https://www.jianshu.com/p/3463571febc2 https://www.jianshu.com/p/33f394c0ee2d https

Dubbo学习系列之十(Sentinel之限流与降级)

各位看官,先提个问题,如果让你设计一套秒杀系统,核心要点是啥???我认为有三点:缓存.限流和分离.想当年12306大面积崩溃,还有如今的微博整体宕机情况,感觉就是限流降级没做好,"用有限的资源响应过量请求"——这就是限流降级的核心.限流降级组件,当今开源界应该是Hystrix最为出名,这也得益于SpringCloud的流行,当然,挑战者总是有的,于是Sentinel横空出世,正因实际生产使用中似乎并不多见,所以才有必要拿来一用,不然就脱离了此系列文章的主旨了,就是要见些不一样的风景!

Hystrix分布式系统限流、降级、熔断框架(二)

三.Hystrix容错 ???????Hystrix的容错主要是通过添加容许延迟和容错方法,帮助控制这些分布式服务之间的交互. 还通过隔离服务之间的访问点,阻止它们之间的级联故障以及提供回退选项来实现这一点,从而提高系统的整体弹性.Hystrix主要提供了以下几种容错方法: 资源隔离 熔断 降级 1.资源隔离-线程池 2.资源隔离-信号量 线程池和信号量隔离比较 ? 线程切换 支持异步 支持超时 支持熔断 限流 开销 信号量 否 否 否 是 是 小 线程池 是 是 是 是 是 大 ???????

SpringCloud微服务:Sentinel哨兵组件,管理服务限流和降级

源码地址:GitHub·点这里||GitEE·点这里 一.基本简介 1.概念描述 Sentinel 以流量为切入点,从流量控制.熔断降级.系统负载保护等多个维度保护服务的稳定性.包括核心的独立类库,监控台,丰富的使用场景验证.(这似乎是阿里开源组件的一贯作风,极其有特点,且特点很规律) 基本特性图: 补刀一句:这种图很多人可能不在意,但是一般官方给这个图就是该中间件的基本使用思路,与核心功能点. 2.基础性概念 资源管理 资源是Sentinel组件中的核心概念之一.应用服务器上脚本,静态页面,A

鹰眼跟踪、限流降级,EDAS的微服务解决之道

本文主要从服务化的起源开始讲起,围绕EDAS介绍这些年来,随着阿里庞大的电商技术平台流量和并发不断攀升过程中,中间件的微服务技术面临的一系列挑战及解决方法.同时,也会向读者介绍历次双十一背后,EDAS服务化技术的演进历程. 服务化的起源 微服务的解决之道 海量微服务的挑战 关于作者 以下为精彩内容整理: 服务化的起源 阿里巴巴前期技术现状 当时阿里巴巴技术团队规模有500人左右,整个技术网站使用单一War应用,基于传统应用开发架构,业务每年翻倍增长. 我们面临着非常多的问题: 上百人维护一个核心

微服务架构下的分布式限流方案思考

1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要.缓存.降级和限流是保护微服务系统运行稳定性的三大利器.缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源.数据库的写操作.频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流. 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS

这个注解一次搞定限流与熔断降级:@SentinelResource

在之前的<使用Sentinel实现接口限流>一文中,我们仅依靠引入Spring Cloud Alibaba对Sentinel的整合封装spring-cloud-starter-alibaba-sentinel,就完成了对所有Spring MVC接口的限流控制.然而,在实际应用过程中,我们可能需要限流的层面不仅限于接口.可能对于某个方法的调用限流,对于某个外部资源的调用限流等都希望做到控制.呢么,这个时候我们就不得不手工定义需要限流的资源点,并配置相关的限流策略等内容了. 今天这篇我们就来一起学

高并发场景下的限流策略

高并发场景下的限流策略: 在开发高并发系统时,有很多手段来保护系统:缓存.降级.限流. 当访问量快速增长.服务可能会出现一些问题(响应超时),或者会存在非核心服务影响到核心流程的性能时, 仍然需要保证服务的可用性,即便是有损服务.所以意味着我们在设计服务的时候,需要一些手段或者关键数据进行自动降级,或者配置人工降级的开关. 缓存的目的是提升系统访问速度和增大系统处理的容量,可以说是抗高并发流量的银弹:降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉某些功能,等高峰或者问题解决后再打开:

「技术干货」Pontus-用友云限流服务

在我们讨论系统稳定性的时候,其实核心的关键词就是容量规划,如何做好业务容量与系统性能的评估,是保障系统稳定性的关键.对于系统性能的评估,需要我们具备自动化工具来对系统进行性能压测,探测系统在实际业务场景下的基线数据,这是我们进行系统资源配置的基础,也是在应对流量增长时进行弹性扩容的依据.在我们做好容量规划的前提下,在实际业务场景下,我们还是不可避免的会面对不确定的系统压力,在面对突发不确定流量的情况下,我们最担心的就是系统的"雪崩".就像突然爆发的车流让道路交通瘫痪一样,我们的系统在突