微服务绕不过的坎-服务雪崩

引言

书接上篇 微服务外交官-Feign ，讲完了SpringCloud Alibaba 远程调用组件Feign之后，接下来讲微服务项目绕不开的问题：服务雪崩。

概念

微服务架构应用设计其目的之一是为了应对高并发环境，那问题来，高并发环境会带来啥问题，微服务架构设计时需要考虑啥预防性操作？

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题或者调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。 更糟糕的是：服务与服务之间是有依赖性，这就导致了故障传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应” 。正应了那就广告词：得了灰指甲，一个传染两

模拟场景

假设一个项目拆分以下几个服务：服务A~服务I

情景1: 微服务之间相互调用,关系复杂,正常情况如下图所示:

情景2：某个时刻，服务A挂了，服务B和服务C依然在调用服务A  

情景3:由于服务A挂了,导致服务C和服务B无法得到服务A的响应,这时候服务C和服务B由于大量线程积压,最终导致服务C和服务B挂掉.  

情景4: 相同道理,由于服务之间有关联，所以会导致整个调用链上的所有服务都挂掉.  

 这下好了，全家整整齐齐~

代码模拟

上面模拟微服务雪崩场景的过程，肯定有小伙伴抬杠，这些都是你YY的，唬我啊。那接下来使用代码模拟一下。

需求：设计2个接口，一个高频访问，然后再访问另外一个接口，观察响应
 

步骤1：在订单服务中新建SentinelController.java

@RestController
public class SentinelController {
    @RequestMapping("/sentinel1")
    public String sentinel1(){
        //模拟一次网络延时
        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "sentinel1";
    }
    @RequestMapping("/sentinel2")
    public String sentinel2(){
        return "测试高并发下的问题";
    }
}

步骤2：修改配置文件中tomcat的并发数

server:
  port: 8091
  tomcat:
    threads:
      max: 10 #tomcat的最大并发值修改为10,

springboot项目内嵌的tomcat理论是没有请求数限制的，在资源耗尽之前可以无休止开启线程处理请求，这里为了模拟资源极限，限制最大只能10个线程。另外保护你电脑避免蓝屏。

步骤3：接下来使用压测工具,对请求进行压力测试

下载地址Apache JMeter - Apache JMeter™

1>修改配置，并启动软件

进入bin目录,修改jmeter.properties文件中的语言支持为language=zh_CN，然后点击jmeter.bat

启动软件。

2>添加线程组

3>配置线程并发数

4>添加Http请求

 

 5>配置取样，并启动测试

 

上面操作意思是模拟50人不停给你项目发请求，访问/sentinel1接口 

6>访问 http://localhost:8091/sentinel2 观察结果

此时会发现, 由于/sentinel1方法进来大量的请求，项目资源有限，一时半会处理不过来，导致请求一直在囤积等待, 这就像一堆拿钱不干活的人，迟早耗死你。当sentinel2接口请求出现时，此时的资源全部被/sentinel1请求占据了，分给这边的资源基本没有，那就出现等待。如果资源耗尽，那大家一起挂了，这就是服务雪崩的雏形。

总结

服务器的雪崩效应其实就是由于某个微小的服务挂了,导致整一大片的服务都不可用。类似生活中的雪崩效应，由于落下的最后一片雪花引发了雪崩的情况。

雪崩发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个服务响应变慢，亦或是某台机器的资源耗尽等等，各式各样，千奇百怪。而我们又无法完全杜绝雪崩的发生，能做的只有提高服务容错率，保证在一个服务发生问题，不会影响到其它服务的正常运行。那该怎么提高容错率呢？请听下回分解。

 看文字不过瘾可以切换视频版：SpringCloud Alibaba 极简入门