3-0服务雪崩原因解决方式案例模拟组件介绍

1 服务雪崩简介

分布式系统中，由于网络或自身原因，无法保证服务100%可用，如果一个服务出了问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入（高并发），就会出现多条线程阻塞等待，进而导致服务瘫痪。
由于服务之间的依赖性，故障传播对整个微服务系统会造成灾难性的后果，这就是服务故障的雪崩效应。

注意1：服务熔断理解-https://zhuanlan.zhihu.com/p/59109569,在Hystrix中，对应配置如下

//滑动窗口的大小，默认为20
circuitBreaker.requestVolumeThreshold 
//过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟
circuitBreaker.sleepWindowInMilliseconds 
//错误率，默认50%
circuitBreaker.errorThresholdPercentage

注意2：服务雪崩的理解-https://zhuanlan.zhihu.com/p/69866628

雪崩原因：
    1.服务提供者不可用（硬件故障，程序bug，缓存击穿，用户或代码逻辑大量重试）
    2.服务调用者不可用（同步等待造成的资源耗尽）
解决方式：
    1.降级：超时降级、资源不足降级(限流降级) --> 应用埋点配置中心监测进行开关降级
    2.隔离：线程池或信号量隔离，不会影响其他服务调用
    3.熔断：达到错误率（阈值）触发降级
    4.缓存
    5.请求合并

2 服务雪崩模拟步骤

2.1 yaml配置文件，设置tomcat最大访问线程数的值为10

  # 测试高并发场景，服务雪崩的雏形
server
  tomcat:
    max-threads: 10

2.2 原有order方法return之前先休眠2000ms

        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

2.3 新增测试方法highConcurrency

    /**
     * 模拟服务雪崩的高并发测试方法
     */
    @RequestMapping("/order/highConcurrency")
    public String highConcurrency() {
        return "测试高并发";
    }

2.4 第一次访问highConcurrency看页面效果，通过jmeter工具设置循环100次1s请求20次原来的order方法，再请求highConcurrency方法看页面效果

3 服务容错组件简介

比较对象	hystrix	resilience4j	sentinel
简介	cloud提供的组件	官方推荐替代hystrix的组件	阿里组件
隔离策略	线程池隔离/信号量隔离	信号量隔离	信号量隔离（并发线程数限流）
熔断降级策略	基于异常比率	基于异常比率、响应时间	基于异常比率、响应时间、异常数
实时统计实现	滑动窗口基于RxJava	Ring Bit Buffer	滑动窗口LeapArray
动态规则配置	支持多种数据源	有限支持	支持多种数据源
扩展性	插件的形式	接口形式	多个扩展点
基于注解的支持	支持	支持	支持
限流	有限支持	rate limit	基于QPS，支持基于调用关系的限流
流量整形	不支持	简单的Rate Limited模式	支持预热模式、匀速器模式、预热排队模式
系统自适应保护	不支持	不支持	支持
整形	不支持	简单的Rate Limited模式	支持预热模式、匀速器模式、预热排队模式
系统自适应保护	不支持	不支持	支持
控制台	简单的监控查看	不提供控制台，可对接其他监控系统	提供开箱即用的控制台，可配置规则、查看秒级监控、机器发现等