Sentinel 的作用

  Sentinel 主要用来解决微服务架构中出现的一些可用性问题，从而实现系统的高可用。系统在运行过程中不可能不出现问题，我们需要做的是在系统出现问题的时候，通过容错机制来避免系统长时间处于不可用状态 (对于失败的请求可以通过定时任务做补偿)。

分布式微服务系统遇到的问题

服务可用性问题：

• 缺乏高可用防护 / 容错机制
• 缓存穿透
• 缓存雪崩：
• 服务雪崩：某个服务不可用，引起其它服务的不可用，最后造成整个服务调用链路不可用，从而导致整个微服务系统的服务雪崩。(因服务提供者的不可用，导致服务调用者的不可用，并将不可用逐渐放大的过程，被称为服务雪崩效应)
• 负载不均：由于对服务器的容量评估不准确，高估了服务器的性能，在负载均衡时，给某台服务器设置的权重过大，分配的流量过多，导致服务器挂掉。
• 服务器容量评估不准确
• 缺乏依赖隔离
• 缺乏容错机制
• 激增流量
• CPU / Load飙高
• 单点故障
• DB超时
• 未处理异常

导致服务不可用的原因：

硬件原因：

• 磁盘空间不足

• 内存不足

激增流量：

• 激增流量导致系统 CPU / Load飙高，无法正常处理请求。

• 激增流量打垮冷系统 (数据库未连接、缓存未预热)。

• 消息投递速度过快，导致消息堆积。

不稳定服务依赖：

• 慢 SQL 查询卡爆数据库连接池。

• 第三方服务不响应，线程池爆满。

• 业务调用持续出现异常，异常未得到处理。

服务雪崩示例图01

Sentinel - - > 容错机制

常见的容错机制

• 超时机制

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

• 服务限流

服务器每秒能承受的请求次数是有限的，如果某个服务的访问量达到它所能承受的临界值，就可能挤爆这台服务器，这就需要对其进行限流。

如下图：事先对服务器进行压力测试，得到其临界值，如500。然后提前设置每秒最大访问量为
500，当每秒请求的并发数为800时，其中300就会进行限流，返回“稍后重试”或者直拒绝处理。

QPS (Queries Per Second) 每秒请求数，就是说服务器在一秒的时间内处理了多少个请求。

• 隔离

a）根据线程数量进行隔离 ( 对每个服务限制一个可访问的线程数量 )：，用户请求不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池满了，就会进行降级处理 ( 返回当前服务不可用 )，用户的请求不会被阻塞，至少可以看到一个执行结果 ( 例如返回xxx服务不可用此类友好的提示信息，后续可以通过定时任务做补偿 )，而不是无休止的等待或者看到系统崩溃。

b）根据信号量进行隔离：

• 服务熔断

熔断概念最早出现电力中的保险丝，当电路电流异常就会将保险丝熔断，防止电路被烧毁。

服务熔断是指：远程服务不稳定 或者 网络抖动时，暂时关闭该服务。

当依赖的服务有大量超时请求时，再让新的请求去访问根本没有意义，只会平白消耗现有资源。比如我们设置的超时时间为1s，如果短时间内有大量请求在1s内得不到响应，就意味着这个服务出现了异常，此时就没有必要再让其他请求去访问这个依赖的服务了，这个时候应该使用断路器来避免资源浪费。

如下情况，当某个服务挂掉之后，就可能导致整个调用链路出现级联故障，进而引起整个调用链路的不可用，最后造成整个系统出现服务雪崩。这个时候可以在服务消费端设置服务熔断机制，当服务消费者调用服务提供者，服务提供者一直没有响应或者出现持续异常的时候，就可以针对这个服务提供者进行熔断 (也就是暂停对这个服务提供者的访问，等到这个服务提供者修复之后，再恢复正常使用，否则继续熔断)。

那么在服务熔断 至 服务修复期间，我们需要一个兜底的方案 ( 总不能什么都不做吧 ! )，通常是对服务进行降级。

• 服务降级

服务降级是指：在服务熔断后，服务修复期间，提供的兜底方案/备用方案。有服务熔断，必然要有服务降级。

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

参考：

一个http请求就是一个线程吗，java的服务是每收到一个请求就新开一个线程来处理吗

java的服务是每收到一个请求就新开一个线程来处理吗？tomcat呢？