服务熔断与降级
在开始本篇的话题之前,我们先看两个现实中的真实案例:
在某个小乡镇的某个银行柜台,只有一个窗口办理业务,后边很多人在排队,业务办理很慢,突然间办理业务的电脑坏了、或者说工作人员午休或下班了,后边排队等待办理业务的并不知道前边什么情况,可能会继续排队。
小明家开了两个门店,一个卖衣服,一个卖副食类,都有员工若干,年底了小明进了很多礼盒,并且销售量很可观,这时候小明把卖衣服的门店关掉,并且把里边的工作人员调到副食门店卖礼盒。
背景分析
对于上述两个案例,我们可以结合到软件开发场景中,做一下简要的分析:
1:银行排队办业务
对于案例一中的银行排队办业务场景,我们可以把窗口及工作人员抽象成服务提供者,而后边排队的人是一个个消费者请求,服务突然中断或者崩溃,正在排队等待的请求并没有感知,导致请求继续等待并且不释放资源。
对于这场景下,总结出大概一下几个问题:
服务端出现故障后没有及时反馈给监控或者消费端,当然如果机器直接挂掉的话是无法上报给消费端。
对于服务端的突然崩溃,消费端没有一种充当监控的角色,对于发现的故障进行服务熔断和隔离以及上报。
排队的人对应是消费端请求,而排队的人各种各样,请求也是五花八门,可能来自多个不同的应用,那么对于服务崩溃需要各个消费端自己做服务熔断和隔离。
2:年货礼盒活动
而对于案例二中的礼盒互动,我们可以理解成电商平台同一个应用下的两个服务,A服务在大促期间有个服务流量会暴涨,另外一个B服务可能没什么量或者非核心业务,那么为了保证A服务的稳定性,大促期间会主动降级B服务,将应用的核心资源都用来支持A服务。
通过案例二场景,我们有几个点需要明确一下:
在同一时刻,如果核心链路需要大量资源支撑,那么会放弃非核心链路,简单来说就是关停。
同一个应用中,每个服务是平等的,请求过来后都会创建线程,开辟内存空间,占用带宽,那么高并发场景下,这些资源对核心业务尤其重要。
接下来我们将详细介绍本篇的主题 服务熔断与降级。
概念
服务熔断
这一概念来源于电子工程中的断路器(Circuit Breaker)。在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用性,
可以暂时切断对下游服务的调用。
一般是指软件系统中,由于某些原因使得服务出现了过载现象,为防止造成整个系统故障,从而采用的一种保护措施,所以很多地方把熔断亦称为过载保护。
很多时候刚开始可能只是系统出现了局部的、小规模的故障,然而由于种种原因,故障影响的范围越来越大,最终导致了全局性的后果。其实是一种丢车保帅的做法。
服务降级
什么是服务降级?当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或高效运作。举个例子,在天猫双十一期间,由于交易量剧增,为了保证系统稳定性,会把一些非核心功能降级,比如统计、绩效等。
服务熔断和服务降级异同
相似性
差异性
目标
服务熔断和降级的目的都是为了保护应用,使应用不会因为外界突发流量或者下游依赖不稳定导致当前应用崩溃,主要是提供一种优雅的容错隔离机制。
实现原理分析
1:服务熔断
正常情况下的服务:
某一服务出现异常,拖垮整个服务链路,消耗整个线程队列,造成服务不可用,资源耗尽:
形成过程:
服务提供者不可用
重试加大流量压力
服务调用者不可用
实现原理
消费者不直接调用服务提供方,中间加一层隔离层,隔离层可引入框架也可自己实现。
对于超时、崩溃或者报错的服务调用,通过隔离层做频次记录,根据制定的策略进行故障隔离,比如超时超过10次以上就熔断服务,抑或者对于熔断的服务指定时间后尝试再次访问等等。
简单来说,服务熔断的原理就是 调用隔离->监控->熔断。
2:服务降级
而服务降级的实现原理和思想相对熔断要简单一些,只需要在突发流量时间点之前把非核心业务关停。
正常情况下核心服务与非核心服务关系如下:
而流量突发情况下,核心服务与非核心服务关系会变成这样:
会把非核心服务B关停降级,将资源集中到服务A处理业务。
实现原理:
在服务调用成增加降级开关,如果开关是关闭的,那么就终止本次调用,需要注意的是在集群环境要支持同一控制。
一般预案平台是大公司才会有,比如阿里集团很多BU会在双十一前通过预案平台降级非核心链路服务。
常见解决方案
1:hystrix
Netflix Hystrix是SOA/微服务架构中提供服务隔离、熔断、降级机制的工具/框架。Netflix Hystrix是断路器的一种实现,用于高微服务架构的可用性,是防止服务出现雪崩的利器。目前Hystrix已经停止更新。
2:Sentinel
Sentinel 是阿里巴巴开源的一款断路器实现,目前在Spring Cloud的孵化器项目Spring Cloud Alibaba中,预计Spring Cloud H系列中可以孵化完成。尽管Sentinel尚未在Spring Cloud项目中孵化完成,但Sentinel本身在阿里内部已经被大规模采用,非常稳定。因此可以作为一个较好的替代品。
3:Resilience4J
Resilicence4J 在2018年7月进入大家视野,非常轻量、简单,并且文档非常清晰、丰富。未来发展前景比较好,也是Hystrix官方推荐的替代产品。
不仅如此,Resilicence4j还原生支持Spring Boot 1.x/2.x,而且监控也不像Hystrix一样弄Dashboard/Hystrix等一堆轮子,而是支持和Micrometer(Pivotal开源的监控门面,Spring Boot 2.x中的Actuator就是基于Micrometer的)、prometheus(开源监控系统,来自谷歌的论文)、以及Dropwizard metrics(Spring Boot曾经的模仿对象,类似于Spring Boot)进行整合。
4:自己实现
如果公司或者团队有精力和能力,可以在开源的基础上实现一套对自己业务定制的熔断降级框架。
本文分享自 PersistentCoder 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!