服务降级：在高并发的情况下，防止用户一直等待，使用服务降级方式进行处理(返回友好的提示给客户端，fallback回调方法)。当服务不可用的时候(正在等待的时候、网络延迟、响应时间过长),客户端会处于一直等待的状态。显然一直等待是不合理的，所以我们应该给客户端返回一个友好的提示，使用fallback(回调方法)进行服务降级处理。
服务降级目的：为了提高用户体验(自定义消息返回给客户端)，防止服务雪崩效应。比如：连接超时、网络延迟、服务器响应时间过长等情况。
服务雪崩效应的产生原因：因为默认情况下，只有一个线程池处理所有的服务接口，所有的请求都会被一个线程池处理。如果大量的请求访问同一个接口，当达到tomcat默认极限(可以自己设置)，可能会导致其他服务接口无法访问。
我们常把“基础服务故障”导致的“级联故障”的现象称为雪崩效应。雪崩效应描述的是提供者不可用导致消费者不可用，并将不可用逐渐扩大的过程。
A做为服务提供者(基础服务)，B为A的消费者，C和D为是B的消费者。当A不可用引起了B不可用，并将不可用像滚雪球一样放大到C和D，雪崩效应就这样形成。
解决雪崩效应的方案：使用服务的隔离机制(线程池方式和信号量方式)。
服务隔离：每个服务接口之间互不影响，服务隔离有2种实现方式，线程池方式、信号量。
1.线程池方式：相当于每个接口(服务)都有自己独立的线程池，不同的线程池之间互不影响，能够实现服务接口隔离。缺点：CPU内存开销较大。
2.信号量方式：底层使用原子计数器(atomic)，针对于每个服务都设置自己的独立的限制阈值。比如设置每个服务接口最多同时访问的次数，如果超出缓存队列请求后，自己实现拒绝策略。
服务熔断：在高并发的情况下，如果达到一定的极限(可以自己设置阈值),如果流量超出了设置的阈值，然后拒绝访问，保护当前服务。当服务器达到最大的承受能力的之后，直接拒绝访问服务，然后调用降级方法，返回友好提示。
目的：为了防止服务宕机(保护服务)，会进行熔断处理。
产生的原因：服务请求过多，高并发情况下。可以设置阈值进行限制。超出的请求存放在缓存队列中，如果缓存队列中线程满的话，直接拒绝访问服务，访问不了服务(熔断)。
熔断和服务降级一起使用。
服务限流：
1.计算器方式(滑动计数器)：定义一个原子类，针对于某一个服务实现次数记录，一旦达到阈值之后，这时候可以直接走服务降级(返回一个友好提示给客户端)。
举个例子：限制每60秒内只能接受客户端10个请求，如果超过10个请求则直接拒绝访问服务。固定速率 10R/M。
滑动窗口计数器算法原理：创建6个独立的格子，每个格子都有自己独立的计数器。每个格子独立计数10秒。
2.令牌桶算法(Token)：令牌桶分为2个动作，动作1(固定速率往桶中存入令牌)、动作2(客户端如果想访问请求，先从桶中获取token)。guava 提供的RateLimiter类来进行限流处理。
网址：http://ifeve.com/guava-ratelimiter/
1.传统的方式整合RateLimiter 有很大的缺点：代码重复量特别大，而且本身不支持注解方式。
2.如果限流代码可以放在网关中，相当于针对所有的服务接口都实现限流(可以使用排除法进行排除不进行限流的方法)，维护性不是很强。
3.正常的互联网公司项目，不是所有的服务接口都需要实现限流方法的，一般只真针对于大流量接口。比如：秒杀抢购、12306抢票等。
4.可以手动封装一个RateLimiter类 注解来解决这个方法。
3. 漏桶算法
以固定速率从桶中流出水滴，以任意速率往桶中放入水滴，桶容量大小是不会发生改变的。
流入：以任意速率往桶中放入水滴。
流出：以固定速率从桶中流出水滴。
水滴：是唯一不重复的标识。
因为桶中的容量是固定的，如果流入水滴的速率>流出的水滴速率，桶中的水滴可能会溢出。那么溢出的水滴请求都是拒绝访问的，或者直接调用服务降级方法。前提是同一时刻。
限流的目的：为了保护服务，避免服务宕机。
令牌桶算法与漏桶算法区别：https://www.cnblogs.com/ming-blogs/p/10799709.html