1、Sentinel概述

sentinel它承接了阿里巴巴近十年的双十一大促流量的核心场景。主要用于关注我们的服务高可用场景。sentinel主要是用来解决微服务架构当中出现的可用性问题
在系统日常当中会出现哪些可用性问题？‘
服务器挂掉的原因？
比如说硬件问题，比如说内存不够，或磁盘空间不足都会导致服务器直接停掉，挂机。这属于运维人员关注的问题，也是可控性问题。
我们主要关注系统在运行期间会不会出现这种内存溢出（OM）,出现OM问题，会导致服务器直接挂机。还有比如说第3方服务或者db是不是挂掉了，或者请求第3方服务或db迟迟得不到响应，那么所有请求系统的线程进行堆积，从而得不到响应，进而导致线程池爆满，从而打垮服务器。
总结下来，就是出现了激增流量，在一瞬间，这种泄洪般的流量突然涌入进来系统当中，可能会直接导致cpu load飙高，那么服务器会直接扛不住，就会直接挂掉。那怕你服务器性能再好，有可能抗住了，但是还是会有很多请求，由于缓存没有预热或者数据库连接池来不及创建，这时候都会把这些请求直接打到数据库上面，从而使数据库服务器直接挂掉，那么一旦数据库服务器直接挂掉，那么所有请求当前系统的用户肯定会迟迟得不到响应，所有的请求线程都会堆积到系统这里，得不到响应，从而导致线程池打满，从而拖垮服务器；
还有比如说：被其他服务器拖垮，如请求一些慢SQL导致db超时，或者请求第3方的服务出现卡顿或者说网络不稳定，或者说第3方服务本身有些问题也会使我们请求得不到响应，进而使我们所有线程都堆积到系统当中，导致服务器被拖垮。
还有些像异常没有处理，久而久之，也会造成很多不可用性影响。当出现异常，代码会出现中断，本该正常执行的代码，比如：内存需要释放，需要去清空一些对象，这个时候由于异常没有得到正常的处理，久而久之肯定会导致内存溢出；
还有缓存击穿，缓存穿透，负载不均，容量评估不准确，单点故障等等
说白了，就是系统缺乏高可用防护以及容错机制，尤其是针对流量的防护
一个系统没流量，就什么事都没有，就不用考虑这高可用防护以及容错机制
在运维卷中，在一年中系统宕机时间，通常做到4个9就已经very good，做到5个9，很难很难。
哪怕你做好了防护，系统也不可能不出现问题，但是一旦出现问题，你得有容错机制，不要让服务在很长时间处于不可用状态，尽量减少服务不可用时间。

服务雪崩

在微服务架构中，如果有一个服务挂掉，你没有对它进行容错机制处理的话，有可能就会造成整个系统一个服务雪崩的问题。
因为sentinel它主要就是用来解决这种服务雪崩问题的。
在我们的微服务架构中，我们会拆开很多的一个一个的服务，服务之间他们会进行交叉调用，在这个调用过程当中，它们肯定会有一些共享的服务。就比方说，这个电商系统，它里面有秒杀商品，有商品详情，有购物车。那么它们可能都会请求库存，都会可能请求商品服务，这些都是共享服务。
这个时候，如果说我某一个调用链路之下，某一个服务挂掉了，会出现什么情况？
就比如说，这个秒杀商品，突然秒杀开始，涌入了大量的请求，那么我们的积分服务由于它的服务器性能比较差，它服务直接挂掉了，一旦积分服务挂掉，后续所有用户请求进来，请求到商品的时候，是不是到请求到积分的时候，但由于积分服务挂掉了，你得不到响应，你就会很抓狂，你就会一直去点抢购按钮，你重复的去请求，从而加剧流量的增加，使本来不好的服务器性能雪上加霜，从而积分服务垮掉，从而所有请求又堆积在商品服务这里，导致商品服务挂掉，商品服务挂掉，所有的请求积压在订单服务，然后订单服务挂掉，从而导致整个调用链路的所有服务挂掉，那么整条链路都挂掉后，因为里面有些共享服务，如：商品服务，一旦其他请求进入，也会导致我们整个功能都不可用。这就是所谓的服务雪崩。
所以说，你没有一个容错机制，就一个小小的积分服务，它出错了，都会导致我们整个系统的雪崩。其实积分服务微不足道，那怕积分服务确实挂掉了，我们能够对它进行容错机制的处理的话，那整个下单还是可以正常使用。大不了后续给你做补偿。
容错机制，提高服务高可用性

解决方案

系统在日常运行过程当中，会出现很多的不稳定的因素，从而导致系统发生故障，甚至会导致服务的级联调用故障，进而导致整个微服务架构系统所有服务都处于一个不可用雪崩的服务状态，针对这样的场景，我们怎么保证系统处于一个稳定性，以及在不稳定的场景下，怎么能够拥有个自愈，可恢复的能力。
针对这连个问题，可以采用常见的容错机制处理

常见的容错机制处理

超时机制

在不做任何处理的情况下，服务提供者不可用会导致消费者请求线程强制等待，而造成系统资源耗尽。加入超时机制， 一旦超时，就释放资源。由于释放资源速度较快，一定程度上可以抑制资源耗尽的问题。

商品服务调用积分服务，由于积分服务挂掉了，迟迟得不到响应，导致所有线程堆积在商品服务，从而拖垮商品服务，对商品服务设置请求超时时间，比如说超时时间为2秒，在这2秒内，商品服务没有得到响应的话，会给用户返回个降级的方法。当然，在这2秒内，如果并发量还是很大的话，还是有可能会挤爆我们的线程池，在这里可以引用服务限流机制。

服务限流

如果某一个服务它的访问量达到了它所承受的临界值的时候，肯定要为它进行个限流。比如说，我们会提前为这个服务进行压测，得到一个临界值，比如说QPS（每秒的访问量）是500，那我们可以针对它进行限流，限流500，一旦QPS访问800进来，300肯定进行限流，只有500才能进去服务器，从而有效的保护了服务器。300限流出去的流量，可以针对它进行降级，比如说，我返回个当前用户请求过多，请稍后再试！

隔离

隔离其实跟限流非常相似，只不过是限流是根据流量来进行限制，而隔离它可以根据线程数量或信号量来进行限制。
那如果是根据线程数来进行隔离的话，我们可以为每个服务给它限制个可访问的线程数量，比方说，上面的秒杀商品，它有100的线程数量，因为积分它所能承受的最大的线程池数量可能是20个，导致它挂掉了，那我们就可以为每个服务给它设置个线程隔离，比如说，积分20个线程，商品30个线程，订单20个线程，剩余给库存，这样就可以有效的隔离每一个线程数量，比如说这个积分挂掉了，它所能影响的只能是这20个线程，超出这20个线程以外的线程，我们可以为他进行降级，比如说返回“当前积分不可用”，此时商品可以正常的响应，后续可以为积分做补偿，这样有效的防止了所有的线程堆积在一个服务上面，超过了我这个临界范围，我都让你堵塞或降级，从而有效的解决所有线程堆积在一个服务拖垮服务的问题。
还有个信号隔离，信号隔离它跟流量限制是差不多的

服务熔断

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用

当我们一个服务出现挂掉的情况，有可能导致我们整个调用链路出现级联故障，进而造成整个系统的服务雪崩，这个时候，我可以在我的服务消费方设置个熔断机制，当我去调用一个服务提供者，持续没有响应或者持续异常的时候，我们就可以对这个服务进行熔断，这里的熔断就是对它进行停止访问，熔断之后，我们通常会设置一个阈值，比方说给你10分钟去修复，10分钟后我给你恢复正常使用，没有修复好我继续熔断。在这个熔断期间，我们肯定要有个兜底方案，我们通常会进行降级。就是服务挂掉了，不可能直接给客户返回个异常，什么是降级呢？

1. 开启熔断
   在固定时间窗口内，接口调用超时比率达到一个阈值，会开启熔断。
   
   进入熔断状态后，后续对该服务接口的调用不再经过网络，直接执行本地的默认方法，达到服务降级的效果。

2. 熔断恢复
   熔断不可能是永久的。
   
   当经过了规定时间之后，服务将从熔断状态回复过来，再次接受调用方的远程调用。

可以看：https://blog.csdn.net/qq_24047659/article/details/87953643

服务降级

有服务熔断，必然要有服务降级。 所谓降级，就是当某个服务熔断之后，服务将不再被调用，此时客户端可以自己准备一个本地的fallback（回退）回调， 返回一个缺省值。 例如：(备用接口/缓存/mock数据) 。这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当 然这也要看适合的业务场景。