降级
降级也就是服务降级，当我们的服务器压力剧增为了保证核心功能的可用性 ，而选择性的降低一些功能的可用性，或者直接关闭该功能。这就是典型的丢车保帅了。
一般而言都会建立一个独立的降级系统，可以灵活且批量的配置服务器的降级功能。当然也有用代码自动降级的，例如接口超时降级、失败重试多次降级等。具体失败几次，超时设置多久，由业务等其他因素决定。
熔断
降级一般而言指的是我们自身的系统出现了故障而降级。
而熔断一般是指依赖的外部接口出现故障的情况断绝和外部接口的关系。
例如你的A服务里面的一个功能依赖B服务，这时候B服务出问题了，返回的很慢。这种情况可能会因为这么一个功能而拖慢了A服务里面的所有功能，因此我们这时候就需要熔断！即当发现A要调用这B时就直接返回错误(或者返回默认值等等)，就不去请求B了。
那什么时候熔断合适呢？也就是到达哪个阈值进行熔断，5分钟内50%的请求都超过1秒？还是啥？参考降级。
限流
上面说的两个算是请求过来我们都受理了，这个限流就更狠了，直接跟请求说对不起再见！也就是系统规定了多少承受能力，只允许这么些请求能过来，其他的请求就说再见了。
在我看来，限流的本质是实现系统保护，最终选择什么样的算法，一方面取决于统计的精准度，另一方面考虑限流维度和场景的需求。
限流算法有以下几种：
1、计数器限流，一般用在单一维度的访问频率限制上，比如短信验证码每隔60s只能发送一次
2、滑动窗口限流，本质上也是一种计数器，只是通过以时间为维度的可滑动窗口设计，来减少了临界值带来的并发超过阈值的问题。
每次进行数据统计的时候，只需要统计这个窗口内每个时间刻度的访问量就可以了。
Spring Cloud里面的熔断框架Hystrix ， 以及Spring Cloud Alibaba里面的Sentinel都采用了滑动窗口来做数据统计。
3、漏桶算法，它是一种恒定速率的限流算法，不管请求量是多少，服务端的处理效率是恒定的。基于MQ来实现的生产者消费者模型，其实算是一种漏桶限流算法。
4、令牌桶算法，相对漏桶算法来说，它可以处理突发流量的问题。
它的核心思想是，令牌桶以恒定速率去生成令牌保存到令牌桶里面，桶的大小是固定的，令牌桶满了以后就不再生成令牌。
每个客户端请求进来的时候，必须要从令牌桶获得一个令牌才能访问，否则排队等待。
在流量低峰的时候，令牌桶会出现堆积，因此当出现瞬时高峰的时候，有足够多的令牌可以获取，因此令牌桶能够允许瞬时流量的处理。
网关层面的限流、或者接口调用的限流，都可以使用令牌桶算法，像Google的Guava，和Redisson的限流，都用到了令牌桶算法
