高并发之服务降级和服务熔断

服务降级：

服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此环节服务器的压力，以保证核心任务的进行。

同时保证部分甚至大部分任务客户能得到正确的相应。也就是当前的请求处理不了了或者出错了，给一个默认的返回。

服务熔断：在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。相应的，服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。

降级分类

降级按照是否自动化可分为：自动开关降级和人工开关降级。

降级按照功能可分为：读服务降级、写服务降级。

降级按照处于的系统层次可分为：多级降级。

自动降级分类

（1）、超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况

（2）、失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况

（3）、故障降级：比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）

（4）、限流降级

当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

服务熔断和服务降级比较：

两者其实从有些角度看是有一定的类似性的：

1. 目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
2. 最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
3. 粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
4. 自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；

而两者的区别也是明显的：

1. 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
2. 管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
3. 实现方式不太一样

服务降级要考虑的问题：

1.核心和非核心服务

2.是否支持降级，降级策略

3.业务放通的场景，策略

Hystrix，该库旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包（request collapsing，即自动批处理，译者注），以及监控和配置等功能。

服务降级、熔断、限流的区别

降级

系统将某些不重要的业务或接口的功能降低，可以只提供部分功能，也可以完全停到所有所有不重要的功能。降级的思想是丢车保帅。

常见降级方式：

• 系统后门降级：系统预留后门用于降级，比如提供一个降级URL，访问URL时就执行降级指令。缺点：如果服务器数量多，需要一台一台去操作，效率低。
• 独立系统降级：将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能。

熔断

降级是应对系统自身的故障，而熔断的目的是应对外部系统的故障。比如A服务的X功能依赖B服务的某个接口，当B服务接口响应很慢时，A服务X功能的响应也会被拖慢，进一步导致了A服务的线程都卡在了X功能上，A服务的其它功能也会卡主或拖慢。此时就需要熔断机制，即A服务不在请求B这个接口，A服务内部发现B接口就直接返回错误，从而避免整个A服务被拖慢。

• 实现思路：需要系统有一个统一的API调用层，由API来进行采样或者统计。

限流

限流：只允许系统能够承受的访问量进来，超出的会被丢弃。降级从系统功能优先级角度考虑如何应对故障，而限流则从用户访问压力的角度来考虑如何应对故障。

常见限流方式

• 基于请求限流：指从外部请求的角度考虑限流。
• 基于资源限流：指从系统内部考虑，找到影响性能的关键资源，对其使用上限限制。

案例

如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等核心功能，你会如何设计接口级的故障应对手段？

思路：

• 降级（丢车保帅）：在秒杀时，通过服务降级把注册、修改个人信息等非核心功能关闭掉。
• 熔断：支付依赖第三方服务，要设置熔断策略，熔断后要给出友好提示，比如10分钟后再来支付。
• 限流：抢购下单接口采用限流方式，如抢购1000件商品，则设置2000大小的队列，请求超过2000后直接拒绝掉。

服务的熔断和降级的区别

熔断：

举个例子解释，生活中每家每户都在用电，小明家的电线由于故障致使了小明家停电了。而小李、小张家的电是正常使用的。电力公司没有由于小明家有故障线路而停掉其余人家的电，同时小明家没有使用有故障的电路的电。这时即为熔断。熔断的目的是当A服务模块中的某块程序出现故障后为了避免影响其余客户端的请求而作出的及时回应。架构

降级：

举个例子解释，咱们去银行排队办理业务，大部分的银行分为普通窗口、特殊窗口（VIP窗口，老年窗口）。某一天银行大厅排普通窗口的人巨多。这时特殊窗口贴出告示说某时刻以后再开放。那么这时特殊窗口的工做人员就能够空出来去帮其余窗口办理业务，提升办事效率，已达到解决普通窗口排队的人过的目的。这时即为降级，降级的目的是为了解决总体项目的压力，而牺牲掉某一服务模块而采起的措施。微服务

以上为了加深理解分别举了个例子。有不妥的地方欢迎留言指出。下面是前边的总结：

二者其实从有些角度看是有必定的相似性的：

1. 目的很一致，都是从可用性可靠性着想，为防止系统的总体缓慢甚至崩溃，采用的技术手段；
2. 最终表现相似，对于二者来讲，最终让用户体验到的是某些功能暂时不可达或不可用；
3. 粒度通常都是服务级别，固然，业界也有很多更细粒度的作法，好比作到数据持久层（容许查询，不容许增删改）；
4. 自治性要求很高，熔断模式通常都是服务基于策略的自动触发，降级虽然说可人工干预，但在微服务架构下，彻底靠人显然不可能，开关预置、配置中心都是必要手段；

而二者的区别也是明显的：

1. 触发缘由不太同样，服务熔断通常是某个服务（下游服务）故障引发，而服务降级通常是从总体负荷考虑；
2. 管理目标的层次不太同样，熔断实际上是一个框架级的处理，每一个微服务都须要（无层级之分），而降级通常须要对业务有层级之分（好比降级通常是从最外围服务开始）