Sentinel 的作用
??Sentinel 主要用来解决微服务架构中出现的一些可用性问题，从而实现系统的高可用。系统在运行过程中不可能不出现问题，我们需要做的是在系统出现问题的时候，通过容错机制来避免系统长时间处于不可用状态 (对于失败的请求可以通过定时任务做补偿)。
分布式微服务系统遇到的问题
服务可用性问题：
- 缺乏高可用防护 / 容错机制
- 缓存穿透
- 缓存雪崩：
- 服务雪崩：某个服务不可用，引起其它服务的不可用，最后造成整个服务调用链路不可用，从而导致整个微服务系统的服务雪崩。(因服务提供者的不可用，导致服务调用者的不可用，并将不可用逐渐放大的过程，被称为服务雪崩效应)
- 负载不均：由于对服务器的容量评估不准确，高估了服务器的性能，在负载均衡时，给某台服务器设置的权重过大，分配的流量过多，导致服务器挂掉。
- 服务器容量评估不准确
- 缺乏依赖隔离
- 缺乏容错机制
- 激增流量
- CPU / Load飙高
- 单点故障
- DB超时
- 未处理异常
导致服务不可用的原因：
硬件原因：
-
磁盘空间不足
-
内存不足
激增流量：
-
激增流量导致系统 CPU / Load飙高，无法正常处理请求。
-
激增流量打垮冷系统 (数据库未连接、缓存未预热)。
-
消息投递速度过快，导致消息堆积。
不稳定服务依赖：
-
慢 SQL 查询卡爆数据库连接池。
-
第三方服务不响应，线程池爆满。
-
业务调用持续出现异常，异常未得到处理。
Sentinel - - > 容错机制
常见的容错机制
- 超时机制
在不做任何处理的情况下，服务提供者不可用，会导致消费者请求线程强制等待，造成系统资源耗尽。加入超时机制，一旦超时 (返回请求超时，请稍后重试)，就释放资源。由于释放资源速度较快，一定程度上可以抑制资源耗尽的问题。
- 服务限流
服务器每秒能承受的请求次数是有限的，如果某个服务的访问量达到它所能承受的临界值，就可能挤爆这台服务器，这就需要对其进行限流。
如下图：事先对服务器进行压力测试，得到其临界值，如500。然后提前设置每秒最大访问量为
500，当每秒请求的并发数为800时，其中300就会进行限流，返回“稍后重试”或者直拒绝处理。
QPS (Queries Per Second) 每秒请求数，就是说服务器在一秒的时间内处理了多少个请求。
- 隔离
a）根据线程数量进行隔离 ( 对每个服务限制一个可访问的线程数量 )：，用户请求不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池满了，就会进行降级处理 ( 返回当前服务不可用 )，用户的请求不会被阻塞，至少可以看到一个执行结果 ( 例如返回xxx服务不可用此类友好的提示信息，后续可以通过定时任务做补偿 )，而不是无休止的等待或者看到系统崩溃。
b）根据信号量进行隔离：
- 服务熔断
熔断概念最早出现电力中的保险丝，当电路电流异常就会将保险丝熔断，防止电路被烧毁。
服务熔断是指：远程服务不稳定 或者 网络抖动时，暂时关闭该服务。
当依赖的服务有大量超时请求时，再让新的请求去访问根本没有意义，只会平白消耗现有资源。比如我们设置的超时时间为1s，如果短时间内有大量请求在1s内得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他请求去访问这个依赖的服务了，这个时候应该使用断路器来避免资源浪费。
如下情况，当某个服务挂掉之后，就可能导致整个调用链路出现级联故障，进而引起整个调用链路的不可用，最后造成整个系统出现服务雪崩。这个时候可以在服务消费端设置服务熔断机制，当服务消费者调用服务提供者，服务提供者一直没有响应或者出现持续异常的时候，就可以针对这个服务提供者进行熔断 (也就是暂停对这个服务提供者的访问，等到这个服务提供者修复之后，再恢复正常使用，否则继续熔断)。
那么在服务熔断 至 服务修复期间，我们需要一个兜底的方案 ( 总不能什么都不做吧 ! )，通常是对服务进行降级。
- 服务降级
服务降级是指：在服务熔断后，服务修复期间，提供的兜底方案/备用方案。有服务熔断，必然要有服务降级。
所谓降级，就是当某个服务熔断后，服务将不再被调用，此时客户端可以自己准备一个fallback(回退)回调，返回一个缺省值。例如：(备用接口 / 缓存 / mock数据)。这样做，虽然服务水平下降，但好歹还是可用的，比直接挂掉要强，当然这也要看具体的业务场景。