服务雪崩效应

什么是雪崩效应?

默认情况下Tomcat只有一个线程池去处理的客户端发送的所有服务请求,这样的话在高并发下情况下,如果客户端所有请求堆积到同一个服务接口上,就会产生Tomcat的所有线程去处理该服务接口,可能会导致其他服务接口无法访问,可能会导致其他服务接口接口访问的时候,产生延迟和等待.

Tomcat有个线程池,每个一个线程去处理客户端发送每次请求.

假设Tomcat最大请求数是20客户客户端发送100请求,看下图这样会发生什么呢?

这样的话,由于大量的请求发送给orderToUserInfo.然而这个方法会执行效率比较慢.在当访问getOrderInfo方法时,该线程会出现延迟和等待.

怎么解决?

在微服务架构中,我们把每个业务都拆成了单个服务模块,然后当有业务需求时,服务间可互相调用,但是出现服务不可用的情况,这个时候就可以使用Hystrix服务保护框架;

基于Hystrix解决服务雪崩效应方法与原理

1.服务降级

在高并发情况下,防止客户一直等待.使用服务降级方式,

就是当出现这种情况,可以返回一个友好的提示直接给客户端,不会去处理请求,调用fallBack方法.目的是为了用户体验

2.服务熔断

服务熔断是为了保护服务.在高并发情况下.如果请求达到了一定的极限,这个极限可以自己设置.如果流量超出了设置的阈值,自动开启保护服务功能,使用服务降级方式返回一个友好的提示.熔断机制和服务降级一起使用.

3.服务隔离

服务隔离又分为种类隔离和用户隔离.

3.1 种类隔离

种类隔离要从两个维度来说,即服务提供方和服务调用方.

图中可以很简单的看出,从服务提供方而言.就是每一个服务对应一个数据库,给一个服务器部署.,这样某个服务出现了故障,就不会互相影响,达到一种物理层面的隔离

那么从服务调用方的角度说,我们只需要服务降级与服务熔断即可.

3.2用户隔离.

用户隔离就是按照不同的分组形成不同的服务实例,这样,某个服务宕机,只影响对应分组的用户,而不是全部用户.简单来说就是使用多租户的方式.

有三种方式:

  一,每个租户有独立的服务和独立的数据库

当用户请求的时候会经过网关,网关可根据用户唯一标识符,如id 识别对应的服务实例.进行转发.

  二,每个租户有共享的服务和独立的数据库

用户请求的时候经过网关,网关将数据转发给用户服务.服务确定该操作哪一个数据库.

怎么确定呢?这个是属于ORM框架,动态选择数据源的问题.

1.hibernate方式:hibernate支持多租户架构,使用hibernate.muitiTenancy的配置.一个DATABASE对应一个租户

2.mybatis方式:需要扩展AbstractRoutingDataSource抽象类实现多数据源切换.还有一种是mybatis plus实现切换.

  三,每个租户有共享的服务和共享的数据库

这种就是比较好理解的,在服务传给数据库中加一个筛选,该标识为哪个租户就是哪个租户.

1.hibernate方式:是利用hibernate filter 配置,可以自动过滤数据

2.mybatis方式:自定义Interceptor,可以拦截要执行的sql,动态拼接租户条件.

 

总结:

服务雪崩的一个问题可以延伸到多个方面,我们需要融合各个方面的技术攻破技术难关.