SpringCloud微服务保护方案解读

​

目录

服务雪崩定义

问题的产生

示例

雪崩产生的几种场景

解决方案 

熔断模式

隔离模式（仓壁模式 ）

限流模式

超时处理

总结 

服务保护技术对比

服务雪崩定义

我们都知道在微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。这种在微服务调用链路中，因为某个服务不可用导致上游服务调用者不可用，最终扩大至整个服务集群产生不可用的问题称之为雪崩效应（一个不可用导致全部不可用）。

分布式系统都存在这样一个问题，由于网络的不稳定性，决定了任何一个服务的可用性都不是 100% 的。当网络不稳定的时候，作为服务的提供者，自身可能会被拖死，导致服务调用者阻塞，最终可能引发雪崩连锁效应。

问题的产生

示例

下面用一个例子来演示这个问题：现在有服务A，他的业务涉及到调用服务1，服务2，服务3。

​编辑

如果服务提供者服务1发生了故障，当前的应用的部分业务因为依赖于服务1，因此也会被阻塞。此时，其它不依赖于服务1的业务似乎不受影响。

​编辑

但是，依赖服务1的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

​编辑

由于服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。那么，依赖于当前服务的其它服务（服务2，服务3）随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了：

​编辑

服务调用者不可用的主要原因是当服务调用者使用同步调用时，会产大量的线程等待占用系统资源。一旦线程资源被耗尽，服务调用者提供的服务也将处于不可用状态，于是服务雪崩效应就产生了。 

雪崩产生的几种场景

• 流量激增：比如异常流量、用户重试导致系统负载升高；
• 缓存刷新：假设A为client端，B为Server端，假设A系统请求都流向B系统，请求超出了B系统的承载能力，就会造成B系统崩溃；
• 程序有Bug：代码循环调用的逻辑问题，资源未释放引起的内存泄漏等问题；
• 硬件故障：比如宕机，机房断电，光纤被挖断等。
• 数据库严重瓶颈，比如：长事务、sql超时等。
• 线程同步等待：系统间经常采用同步服务调用模式，核心服务和非核心服务共用一个线程池和消息队列。如果一个核心业务线程调用非核心线程，这个非核心线程交由第三方系统完成，当第三方系统本身出现问题，导致核心线程阻塞，一直处于等待状态，而进程间的调用是有超时限制的，最终这条线程将断掉，也可能引发雪崩；
   

解决方案 

一般情况对于服务依赖的保护主要有4种解决方案：

熔断模式

主要是参考电路熔断，如果一条线路电压过高，保险丝会熔断，防止火灾。放到我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。断路器会统计访问某个服务的请求数量，异常比例或异常数量，当发现访问服务C的请求异常比例过高时，认为服务C有导致雪崩的风险，会拦截访问服务C的一切请求，形成熔断。

​编辑

设置异常/失败/慢调用上限，当达到上限就断开调用，再来的请求都不让调用，隔断时间之后再尝试调用，如果服务还能运行再放行，否则继续拒绝。 

隔离模式（仓壁模式 ）

对系统请求按类型划分成一个个小岛的一样，当某个小岛被火少光了，不会影响到其他的小岛。例如：可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者公司最近推广的多中心。

我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

​编辑

限流模式

熔断模式和隔离模式都属于出错后的容错处理机制，而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。

 ​编辑

超时处理

设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。超时分两种，一种是请求的等待超时，一种是请求运行超时。

• 等待超时：在任务入队列时设置任务入队列时间，并判断队头的任务入队列时间是否大于超时时间，超过则丢弃任务。
• 运行超时：直接可使用线程池提供的get方法。

（1）线程池隔离模式：使用一个线程池来存储当前的请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）

（2）信号量隔离模式：使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃改类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）

总结 

限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

服务保护技术对比

在SpringCloud当中支持多种服务保护技术：

• Netfix Hystrix

• Sentinel

• Resilience4J

早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：

​