熔断和降级（也叫服务降级），一般是通过组件实现的，而不是spring框架内。比如spring boot框架做增删改查，外加引入spring cloud框架的hystrix或spring cloud alibaba框架的sentinel做熔断和降级，当然还可以做限流。

熔断的本意是，当下对某个api接口发起的服务，错误率太高，或者耗时过长请求的比例过高，所以就认为该api接口当下负载过大，应当在之后的一段时间内，让该api停止对外服务。

和熔断相关的有如下的参数。

1 时间窗口，比如5秒。

2 最小访问量，比如100个。

3 错误率或者是慢请求的比例下限，比如是50%。

4 熔断后的等待时间，比如是2秒。

比如有个服务api是对外提供查询风控信息的，设置了上述熔断参数，遇到如下情况时会熔断。

1 时间窗口5秒内，至少收到100个请求。这个是先决条件，比如5秒内只收到99个请求，哪怕这99个请求全都失败（或返回过慢），也不会熔断。

2 如果5秒内收到100个请求后，再去看里面失效请求或慢查询请求的比例，如果高于50%，即该接口熔断2秒，这个过程中，发到该风控接口的请求全都立即返回失败。

3 在2秒以后，（hystrix或sentinel等）支持熔断的组件再去采样，如果依然是5秒内请求个数大于等于100，并且失败或慢查询的比例高于50%，继续熔断2秒。否则恢复正常。

为什么要引入熔断机制呢？因为请求api的线程，是需要耗费内存等资源的，比如请求风控api这个线程，持续了5秒，那么服务器在这5秒以内，就得耗费一定的资源维护这个线程。

对服务器来说，能容纳的请求线程个数是有上限的，具体要看服务器的配置，假设是1000个。如果不引入熔断机制，而并发量又高，一秒会新增1000个访问风控API接口的线程，那么每个线程都得被维持5秒，而且由于风控接口可能出现故障，不少线程（或者说大多数线程）又拿不到期望结果。这种情况下，与其线程在5秒后因失败而被终止，那么还不如立即启动熔断机制，让一些线程在发起请求后立即得到错误的结果。

否则的话，大量堆积的线程，就会耗尽服务器的内存等资源，甚至可能还耗尽数据库连接对象，最终导致部署在这台服务器上的所有服务都不可用。所以，熔断其实是种保护机制，尤其在高并发场景下，真得预先设置好熔断策略。

服务降级的本意是，在高并发等场景，一些用户请求难免会得不到预期的结果，这种情况下，应当针对这些请求快速返回，同时提供一个用户尚能接受的结果。

比如在某电商网站，有时候去搜索一个商品，期望的结果自然是返回搜索列表，但在某个时刻，正好服务器里并发量太高，或者因为种种原因，搜索商品的请求无法得到期望结果，这种情况下，较好的处理方法是，快速（而不是等待若干时间）返回一个“请稍后再试”的页面。

如果不引入服务降级，那么用户真可能会直接看到一个只有资深程序员才能看懂的异常提示，比如哪号内存出问题，或者xx组件的xx行出问题。与其这样，还不如返回个能让用户看得懂的界面。

在一些事件场景，熔断和服务降级一般是整合一起使用的，比如查询商品的接口方法出现熔断，需要等待2秒后再采样，在这2秒内，hystrix或sentinel等能实现服务降级功能的组件，会把请求抓发到“请稍后再试”的页面，从而实现服务降级。