什么是服务熔断或服务降级

1、服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护；服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始） 2、服务降级是在服务器压力陡增的情况下，利用有限资源，根据当前业务情况，关闭某些服务接口或者页面，以此释放服务器资源以保证核心任务的正常运行。 流量控制本质上是减小访问量，而服务处理能力不变；而服务降级本质上是降低了部分服务的处理能力，增强另一部分服务处理能力，而访问量不变。 3、什么是服务降级？当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作；服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用， 4、服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级：是利用有限资源，保障系统核心功能高可用、有损的架构方法。有限资源；核心高可用；有损；架构方法。 有限资源（边际效用递减法则：单位资源投入对可用性的效用是不断递减的）。核心（功能/服务等级：核心高可用，级别越低，可用性要求越低）。有损（降级与故障切换的关系：降级是有损的故障切换）。架构方法（降级需要预先分析、设计，有实施方法论）； 5、服务熔断和电路熔断是一个道理，如果一条线路电压过高，保险丝会熔断，防止出现火灾，但是过后重启仍然是可用的；而服务熔断则是对于目标服务的请求和调用大量超时或失败，这时应该熔断该服务的所有调用，并且对于后续调用应直接返回，从而快速释放资源，确保在目标服务不可用的这段时间内，所有对它的调用都是立即返回，不会阻塞的。再等到目标服务好转后进行接口恢复。 服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行；对于复杂系统而言，会有很多的微服务通过 rpc 调用，从而产生一个业务需要一条很长的调用链，其中任何一环故障了都会导致整个调用链失败或超时而导致业务服务不可用或阻塞。这种情况下，可以暂时去掉调用链中故障的服务来进行降级，其中降级策略又有很多种，比如限流，接口拒绝等，这里就挑个简单的来举栗；

服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。比如电商平台，在针对618、双11等高峰情形下采用部分服务不出现或者延时出现的情形。

二、实现方式

我在spring Cloud项目中,使用了两种方式处理降级操作。

（1）使用feign组件完成降级操作，到内容提供者无法提供服务时， 消费者会调用降级操作，返回服务不可用等信息，或者返回提前准备好的静态页面。 调用的降级处理方法如下：

1@Component

2public class FeignClientFallbackFactory implements FallbackFactory<SchedualServiceHi> { 

3    //    打印日志

4    private static final Logger print = LoggerFactory.getLogger(FeignClientFallbackFactory.class) 

5    //降级处理方式 

6    @Override 

7    public SchedualServiceHi create(Throwable throwable) {

8        return new SchedualServiceHi() { 

9            @Override

10            public String mm(@RequestParam("uname") String uname, @RequestParam("upwd") String upwd) {

11                print.info("fallbackreason was:", throwable)

12                return "服务报错了"

13            }

14        }

15    }

16}

（2）也可以使用zuul网关，在spring Cloud自定义一个类实现ZuulFallbackProvider接口，当出现问题，无法正常调用时 ，为服务提供回退响应。

1@Component

2public class MyfaultFallback implements FallbackProvider { 

3    @Override 

4    public String getRoute() {

5//        表示为哪个服务提供回退，此处表示所有微服务。

6        return "*" 

7    } 

8 

9    @Override

10    public ClientHttpResponse fallbackResponse(String route, Throwable cause) {11        return new ClientHttpResponse() {

12            @Override

13            public HttpStatus getStatusCode() throws IOException {

14//                fallback返回的状态码

15                return HttpStatus.OK

16            }

17

18            @Override

19            public int getRawStatusCode() throws IOException {

20                //数字类型的状态码，本例返回的是200

21                return this.getStatusCode().value()

22            }

23

24            @Override

25            public String getStatusText() throws IOException {

26                //状态文本27                return "OK"

28            }

29

30            @Override

31            public void close() {

32

33            }

34

35            @Override

36            public InputStream getBody() throws IOException {

37//                响应体38                return new ByteArrayInputStream("用户微服务不可用，请稍候再试".getBytes())

39            }

40

41            @Override

42            public HttpHeaders getHeaders() {

43                HttpHeaders headers = new HttpHeaders()

44                headers.setContentType(MediaType.APPLICATION_JSON)

45                MediaType mt = new MediaType("application",

46                        "json", Charset.forName("UTF-8"))

47                headers.setContentType(mt)

48                return headers

49            }

50        }

51    }

52}

三、效果展示

当我们访问zuul网关时，服务提供者没有开启，访问不到，就会进行降级处理，显示下面内容。

原文链接：https://zhuanlan.zhihu.com/p/69635613

    目前APP业务中启用的定时任务已达到400+，目前管理比较混乱，很多任务运行时占用服务器资源巨大，其中不乏一些非紧急的任务，平时并不会有太大影响，但是当流量高峰来临时，这些定时任务可能会成为压死骆驼的最后一根稻草。为了避免出现这样的问题，我们通常会在高流量来之前去调整一些定时任务的执行间隔时间或者暂停一些不影响服务的定时任务。这样做的弊端是工作量很大，同时难免会有遗漏。由此衍生除了对任务分级的诉求。对任务分级后，高峰流量时，可视情况降级相关等级的定时任务。

        PS：设计核心流程的任务等，如支付回调

        PS：任务中设计到事务等

    基于gocron的任务节点做任务分级，不同级别的任务对应不同的gocron节点。如下图：

    把三级任务放在三级节点上跑，如下图：

    以此类推，不同级别的任务跑在对应级别的节点上。

    当流量高峰来临时，我们想通过停掉所有三级任务来实现快速降级，而这个操作仅仅需要关闭对应节点的连接即可。如下图

PS：这个操作同时会停止所有正在运行的任务

举个例子：目前我的三级任务节点上运行了一个同步数据的任务（预计5分钟左右能执行完），当我把三级任务节点关闭时，这个任务会直接失败，在节点对应的机器上我们可以看到所有进程也被直接kill掉了，即使我的任务是多进程在跑，相应的子进程也会被kill掉。如下：

当前正在服务的三级节点-asgard三级定时任务

当前正在节点-asgard三级定时任务上运行的任务-商品数据整合同步搜索个推库

节点服务器上正在运行的进程

这时候我们关闭asgard三级定时任务这个节点

可以看到任务直接执行失败了

同时，节点服务器上的进程也被kill掉了

    由于二级任务可能涉及到事务等操作，非万分紧急情况下不能直接终止，以免导致脏数据的产生。对于这种任务的降级我们不能直接通过节点的方式停止任务。可以通过关闭任务的方式停止。如下：

PS：关闭任务的操作会等当前的任务执行完成再关闭，不会对当前任务产生任何影响

举个例子：

还拿asgard三级定时任务这个节点来看，目前这个节点在链接状态

这个节点下跑了一个任务

同样的，节点服务器上有对应的进程在跑着

这时候，我们关闭这个任务

我们可以看到，关闭这个任务，不会影响正在执行的任务

节点对应的服务器上的任务也正常在跑

PS：这个关闭任务对应的是，完成当前任务后不再执行新的任务。

    1、基于gocron的任务节点对任务做分级处理

    2、一、二、三级任务的划分

    3、服务降级的两种方式：关闭节点&关闭任务

---