从0为你讲解，什么是服务降级？如何实现服务降级？

背景

在系统运行时，为了保证核心服务能正常提供服务，不至于因为一些非核心功能而阻塞服务，需要对服务进行分级。当非核心服务影响到核心服务时，能通过配置或者其他手段快速切断非核心服务从而保证核心服务能正常对用户提供服务。

如何切断非核心服务呢？常用的方法有限流、熔断、降级，市面上也有很多的组件能提供相应的功能，这些组件都提供了很多强大的功能，但引入这些开源组件的同时也会带来一些复杂的配置以及学习成本，另外公司微服务是dubbo构建的，引入spring-cloud的一些组件会比较复杂。

基于此，我们决定自研一个降级组件，集成到公司的各个服务里面，提供最基础的降级服务。

服务故障的场景：

服务故障分为接口级故障和系统级故障

系统级的故障：例如，机器宕机、机房故障、网络故障等问题，这些系统级的故障虽然影响很大，但发生概率较小。

接口级故障：在实际业务运行过程中，该故障影响可能没有系统级那么大，但发生的概率较高

接口级故障的典型表现就是系统并没有宕机，网络也没有中断，但业务却出现问题了。

例如，

业务响应缓慢、大量访问超时、大量访问出现异常

，这类问题的主要原因在于系统压力太大、负载太高，导致无法快速处理业务请求，由此引发更多的后续问题。

例如，最常见的数据库慢查询将数据库的服务器资源耗尽，导致读写超时，业务读写数据库时要么无法连接数据库、要么超时，最终用户看到的现象就是访问很慢，一会访问抛出异常，一会访问又是正常结果。接口故障如果处理不及时，严重的时候甚至会引起系统级故障。如数据库慢查询导致数据库cpu升高，查询的服务短时间内频繁fullgc，并因此形成连锁反应，牵一发而动全身，依赖该该服务的其他服务全都不可用，蝴蝶效应引起核心服务的不可用

故障应对策略

优先保证核心业务和优先保证绝大部分用户

降级

降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。**降级的核心思想就是丢车保帅，优先保证核心业务。**例如，对于教育类App学习主链路是核心服务，其他的各种礼品活动弹窗，老师点评服务等如果出问题后不应该影响主学习链路，这时可以停掉这些非核心服务。常见的实现降级的方式有：

• 系统后门（配置）降级

为每一个可降级服务提供一个业务开关配置，在业务出现故障后通过切换业务开关配置进行手动降级，但主要缺点是如果服务器数量多，需要一台一台去操作，效率比较低，这在故障处理争分夺秒的场景下是比较浪费时间的。

• 独立降级系统

为了解决系统后门降级方式的缺点，将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能，但引入独立系统运维，集成等复杂度会相应提高 Hystrix,sentinel等都有相应功能实现

熔断

熔断和降级是两个比较容易混淆的概念，因为单纯从名字上看好像都有禁止某个功能的意思，但其实内在含义是不同的，原因在于降级的目的是应对系统自身的故障，而熔断的目的是应对依赖的外部系统故障的情况。

假设一个这样的场景：A 服务的 X 功能依赖 B 服务的某个接口，当 B 服务的接口响应很慢的时候，A 服务的 X 功能响应肯定也会被拖慢，进一步导致 A 服务的线程都被卡在 X 功能处理上，此时 A 服务的其他功能都会被卡住或者响应非常慢。这时就需要熔断机制了，即：A 服务不再请求 B 服务的这个接口，A 服务内部只要发现是请求 B 服务的这个接口就立即返回错误，从而避免 A 服务整个被拖慢甚至拖死。

• 熔断机制实现的关键是需要有一个统一的 API 调用层

由 API 调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了。

• 熔断机制实现的另外一个关键是阈值的设计

例如 1 分钟内 30% 的请求响应时间超过 1 秒就熔断，这个策略中的“1 分钟”“30%”“1 秒”都对最终的熔断效果有影响。实践中一般都是先根据分析确定阈值，然后上线观察效果，再进行调优。

限流

降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。根据限流作用范围，可以分为单机限流和分布式限流&