Hystrix官宣,停更进维

https://github.com/Netflix/Hystrix

1610803432597.png

概述

分布式面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免地失败。

1610803432656.png

图中的请求需要调用A,P,H,I四个服务,如果一切顺利则没有什么问题,关键是如果I服务超时会出现什么情况呢?

服务雪崩

  多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。
  如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”

  对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是,这些应用程序还可能导致服务之间的延迟增加,备份队列线程和其他系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。

所以,

  通常当你发现一个模块下的某个实例失败后,这时候这个模块依然还会接收流量,然后这个有问题的模块还调用了其他的模块,这样就会发生级联故障,或者叫雪崩。

Hystrix是什么

  Hystrix是一个用于处理分布式系统的延迟容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。

  “断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。

Hystrix能干嘛

  • 服务降级
  • 服务熔断
  • 接近实时的监控

Hystrix重要概念

服务降级(fallback)

对方系统不可用了,你需要给我一个兜底的解决方法

比如:服务器忙,请稍后再试,不让客户端等待并立刻返回一个友好提示, fallback

哪些情况会发生降级:

  • 程序运行异常
  • 超时
  • 服务降级触发服务熔断
  • 线程池/信号量打满也会导致服务降级

服务熔断(break)

类比保险丝达到最大服务访问后,直接拒绝访问,拉闸限电,然后调用服务降级的方法并返回友好提示

就是保险丝:服务的降级->进而熔断->恢复调用链路

服务限流(flowlimit)

秒杀高并发等操作,严禁一窝蜂的过来拥挤,大家排队,一秒钟N个,有序进行

Hystrix案例

支付微服务搭建

建module

创建工程cloud-provider-hystrix-payment8090

改pom

  1. <dependencies>
  2. <dependency>
  3. <groupId>com.sgy.cloud2020</groupId>
  4. <artifactId>cloud-provider</artifactId>
  5. <version>${project.version}</version>
  6. </dependency>
  7. <!--eureka client-->
  8. <dependency>
  9. <groupId>org.springframework.cloud</groupId>
  10. <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
  11. </dependency>
  12. <dependency>
  13. <groupId>org.projectlombok</groupId>
  14. <artifactId>lombok</artifactId>
  15. <scope>provided</scope>
  16. </dependency>
  17. </dependencies>
  18. </project>

启动类

/**
 * Created by AaronShen on 2020/6/1
 */
@SpringBootApplication
@EnableEurekaClient
public class PaymentHystrixMain8090 {
    public static void main(String[] args) {
        SpringApplication.run(PaymentHystrixMain8090.class,args);
    }
}

配置文件application.yml

server:
  port: 8090

spring:
  application:
    name: cloud-payment-server
  datasource:
    username: blog
    password: 123456
    url: jdbc:mysql://192.168.200.10:3306/cloud?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8&serverTimezone=GMT%2B8
    driver-class-name: com.mysql.cj.jdbc.Driver
    # 使用我们自己的druid数据源
    type: com.alibaba.druid.pool.DruidDataSource

    initialSize: 10 #初始化连接个数
    minIdle: 5    #最小连接个数
    maxActive: 500 #最大连接个数
    maxWait: 60000 #最大等待时间
    timeBetweenEvictionRunsMillis: 60000
    minEvictableIdleTimeMillis: 300000
    validationQuery: SELECT 1 FROM DUAL
    testWhileIdle: true
    testOnBorrow: false
    testOnReturn: false
    poolPreparedStatements: true
    #   配置监控统计拦截的filters,去掉后监控界面sql无法统计,'wall'用于防火墙
    filters: stat,wall,log4j
    maxPoolPreparedStatementPerConnectionSize: 20
    useGlobalDataSourceStat: true
    connectionProperties: druid.stat.mergeSql=true;druid.stat.slowSqlMillis=500

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
#      defaultZone: http://eureka7002.com:7002/eureka,http://eureka7001.com:7001/eureka/ #集群版
      defaultZone: http://eureka7001.com:7001/eureka/
  instance:
    instance-id: payment8090
    prefer-ip-address: true #访问路径可以显示ip地址
    # Eureka客户端向服务端发送心跳的时间间隔,单位为秒(默认是30秒)
    lease-renewal-interval-in-seconds: 1
    #Eureka服务端在收到最后一次心跳后等待时间上限,单位为秒(默认是90秒),超时将剔除服务
    lease-expiration-duration-in-seconds: 2

mybatis:
  # config-location和configuration不能同时配置,否则会抛出异常
  # 一般只配置configuration即可,会自动找到mybatis全局配置文件
  #  config-location: classpath:mybatis/mybatis-config.xml
  mapper-locations: classpath:mapper/*Mapper.xml
  # 对应实体类的路径,只能指定具体的包,多个配置可以使用英文逗号隔开
  type-aliases-package: com.sgy.payment
  configuration:
    # Mybatis SQL语句控制台打印
    #    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    # 开启驼峰命名规则
    # 在数据库中字段可以采用驼峰命名规则,mybatis会把 下划线去掉并把下划线后面的首字母认为是大写
    map-underscore-to-camel-case: true

logging:
  level:
    # 注意注意注意 一定要修改成自己的包名
    com.sgy: debug
  file:
    path: log/
    name: log/com.sgy.payment-dev.log
    clean-history-on-start: true
  pattern:
    console: "%d{yyyy-MM-dd} [%thread] %-5level %logger{50} ===> %msg%n"
    file: "%d{yyyy-MM-dd} === [%thread] === %-5level === %logger{50} ===> %msg%n"

编写service

接口

/**
 * Created by AaronShen on 2020/6/1
 */
public interface PaymentService extends BaseDaoService<Payment,String> {
    /**
     * 返回成功结果
     */
    String paymentInfoOk(Integer id);

    /**
     * 模拟复杂业务
     */
    String paymentInfoTimeOut(Integer id);
}

实现

/**
 * Created by AaronShen on 2020/6/1
 */
@Service
public class PaymentServiceImpl extends BaseDaoServiceImpl<Payment,String, PaymentDao>
        implements PaymentService {
    /**
     * 返回成功结果
     *
     * @param id
     */
    @Override
    public String paymentInfoOk(Integer id) {
        String result = "当前线程:" + Thread.currentThread().getName() +
                "\t" + "paymentInfoOk(id)" + "\t" + id;
        return result;
    }

    /**
     * 模拟复杂业务
     *
     * @param id
     */
    @Override
    public String paymentInfoTimeOut(Integer id) {
        try {
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        String result = "当前线程:" + Thread.currentThread().getName() +
                "\t" + "paymentInfoError(id)" + "\t" + id +
                "\t" + "耗时(秒):5";
        return result;
    }
}

编写controller

/**
 * Created by AaronShen on 2020/6/1
 */
@RestController
@Slf4j
public class PaymentController {
    @Resource
    PaymentService paymentService;

    /**
     * 返回成功结果
     */
    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfoOk(@PathVariable(value="id") Integer id) {
        String result = paymentService.paymentInfoOk(id);
        log.info("*****result = " + result);
        return result;
    }

    /**
     * 模拟复杂业务
     */
    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfoTimeOut(@PathVariable(value="id") Integer id) {
        String result = paymentService.paymentInfoTimeOut(id);
        log.info("*****result = " + result);
        return result;
    }
}

测试

1610803432681.png

1610803432715.png

接下来的测试

以上述为根基平台:正确->错误->降级熔断->恢复

高并发测试(支付服务)

上述情况在非高并发情况下,还能勉强满足

Jmeter压力测试

  开启Jmeter,来20000个并发压死8090,20000个请求去访问http://127.0.0.1:8090/payment/hystrix/timeout/123/

1610803432746.png

1610803432770.png

创建发出http请求

1610803432798.png

压测结论

  • 访问两个接口,都会转圈圈
  • 为什么会卡死
    • tomcat的默认的工作线程数被打满了,没有多余的线程来分解压力和处理
  • 上面还是服务提供者8001自己测试,假如此时外部的消费者80也来访问,那消费者只能干等,最终导致消费端80不满意,服务端8001直接被拖死

订单微服务调用支付微服务出现卡顿

创建cloud-consumer-feign-hystrix-order80

改pom

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>cloud2020</artifactId>
        <groupId>com.sgy.cloud2020</groupId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>

    <artifactId>cloud-consumer-feign-hystrix-order80</artifactId>

    <dependencies>
        <dependency>
            <groupId>com.sgy.cloud2020</groupId>
            <artifactId>cloud-consumer</artifactId>
            <version>${project.version}</version>
        </dependency>
        <!-- openFeign -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>

        <!--eureka client-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

        <!-- 添加健康监控依赖 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <scope>provided</scope>
        </dependency>
    </dependencies>
</project>

改yml

server:
  port: 80
eureka:
  client:
    register-with-eureka: false
    service-url:
#      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka
      defaultZone: http://eureka7001.com:7001/eureka
# 设置feign客户端超时时间(OpenFeign默认支持Ribbon)
ribbon:
  ReadTimeout: 10000           # 建立连接所用时间,适用于网络状况正常的情况下,两端连接所用的时间
  ConnectTimeout: 10000        # 建立连接后,从服务器读取到的可用资源所用的时间

logging:
  level:
    com.sgy.springcloud.service.PaymentFeignService: debug   # feign日志以什么级别监控哪个接口

启动类

@SpringBootApplication
@EnableFeignClients
public class OrderHystrixMain80 {
    public static void main(String[] args) {
        SpringApplication.run(OrderHystrixMain80.class,args);
    }
}

业务类

  1. 创建服务接口
@Service
@FeignClient(value = "CLOUD-PAYMENT-SERVER")
public interface OrderService {

    @GetMapping("/payment/hystrix/ok/{id}")
    String paymentInfoOk(@PathVariable(value="id") Integer id);

    @GetMapping("/payment/hystrix/timeout/{id}")
    String paymentInfoTimeOut(@PathVariable(value="id") Integer id);
}
  1. 创建控制层
@RestController
@Slf4j
public class OrderController {
    @Resource
    OrderService orderService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String orderInfoOk(@PathVariable(value="id") Integer id) {
        String result = orderService.paymentInfoOk(id);
        return result;
    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    public String orderInfoTimeOut(@PathVariable(value="id") Integer id) {
        String result = orderService.paymentInfoTimeOut(id);
        return result;
    }
}

正常测试

使用浏览器访问 http://127.0.0.1/consumer/payment/hystrix/ok/123

1610803432826.png

高并发测试

  • 2W个并发压测8090
  • 消费端80微服务再去访问正常的Ok微服务8001地址
  • 消费者80
    • 要么转圈圈
    • 要么消费端报超时错误

消费者80访问问题原因分析

8090同一层次的其它接口服务被困死,因为 tomcat线程池里面的工作线程已经被挤占完毕

80此时调用8090,客户端访问响应缓慢,转圈圈

上述结论

  • 正因为有上述故障或不佳表现才有我们的降级/容错/限流等技术诞生

降级容错解决的维度要求

  1. 超时导致服务器变慢(转圈圈)
    超时不再等待
  2. 出错(宕机或程序运行出错)
    出错要有兜底
  3. 解决
    1. 对方服务(8090)超时了,调用者(80)不能直卡死等待,必须有服务降级
    2. 对方服务(8090)宕机了,调用者(80)不能一直卡死等待,必须有服务降级
    3. 对方服务(8090)OK,调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者,自己处理降级

支付服务—服务降级

支付服务搭建

依赖

Spring cloud中整合Hystrix时,无法识别@HystrixCommand标签,项目的Hystrix依赖为: 千万别引入错了

<!--引入Hystrix依赖:-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
    <version>1.4.7.RELEASE</version>
</dependency>

业务类启用

@HystrixCommand报异常后如何处理

  • 80fallback

主启动类

在主启动类上添加@EnableCircuitBreaker

降级配置

在服务上使用@HystrixCommand注解

8090先从自身找问题

设置自身调用超时时间的峰值,峰值内可以正常运行,超过了需要有兜底的方法处理,作为服务降级fallback

  • 8001fallback

@HystrixCommand报异常后如何处理

  一旦调用服务方法失败并抛出了错误信息后,会自动调用@HystrixCommand标注号的fallbackMethod调用类中的指定方法

超时异常,服务降级

设置超时时间后,如果当前线程执行时间超过预定的时间就会报超时异常,并且进行服务降级

/**
 * 模拟复杂业务
 * 3000表示当前线程超过3s后调用fallbackMethod中指定的方法
 * @param id
 */
@HystrixCommand(fallbackMethod = "paymentInfoTimeOutHandle",commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
})
@Override
public String paymentInfoTimeOut(Integer id) {
    try {
        TimeUnit.SECONDS.sleep(5);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    String result = "当前线程:" + Thread.currentThread().getName() +
            "\t" + "paymentInfoTimeOut(id)" + "\t" + id +
            "\t" + "耗时(秒):5";
    return result;
}

private String paymentInfoTimeOutHandle(Integer id) {
    String result = "当前线程:" + Thread.currentThread().getName() +
            "\t" + "8090系统繁忙或者运行报错,请稍后再试试!!!" +
            "\t" + "服务降级";
    return result;
}

计算异常,也会导致服务降级

/**
 * 模拟复杂业务
 * 3000表示当前线程超过3s后调用fallbackMethod中指定的方法
 * @param id
 */
@HystrixCommand(fallbackMethod = "paymentInfoTimeOutHandle",commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
})
@Override
public String paymentInfoTimeOut(Integer id) {
    int i = 10 / 0 ;
    String result = "当前线程:" + Thread.currentThread().getName() +
            "\t" + "paymentInfoTimeOut(id)" + "\t" + id ;
    return result;
}

private String paymentInfoTimeOutHandle(Integer id) {
    String result = "当前线程:" + Thread.currentThread().getName() +
            "\t" + "8090系统繁忙或者运行报错,请稍后再试试!!!" +
            "\t" + "服务降级";
    return result;
}

订单服务降级

消费者端设置服务降级超时处理

  比如消费者方法a,要求执行的时间必须小于3s否则进行服务降级,如果在整个执行过程中,时间大于3s就进行服务降级,其实就是提供者端执行的时间大于3s了,消费者认为服务端不行了,我赶紧自己做个服务降级,给用户反馈,别让用户等的太久。

搭建消费者

依赖

<!--引入Hystrix依赖:-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

yml

feign:
  hystrix:
    enabled: true

主启动类

添加@EnableHystrix注解

业务代码

@GetMapping("/consumer/payment/hystrix/timeout/{id}")
@HystrixCommand(fallbackMethod = "paymentInfoTimeOutHandle",commandProperties = {
        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
})
public String orderInfoTimeOut(@PathVariable(value="id") Integer id) {
    String result = orderService.paymentInfoTimeOut(id);
    return result;
}

private String paymentInfoTimeOutHandle(Integer id) {
    String result = "当前线程:" + Thread.currentThread().getName() +
            "\t" + "我是消费者80,对方支付系统繁忙请10秒后再试试或者自己运行出错请检查自己!!!" +
            "\t" + "服务降级";
    return result;
}

注意事项

我们自己配置过的热部署方式对java代码的改动明显,但对@HystrixCommand内属性的修改建议重启微服务

服务降级之全局服务降级

DefaultProperties

目前问题

每个业务方法对应一个兜底方法,代码膨胀

统一和自定义的分开

解决问题

每个方法配置一个???膨胀

@DefaultProperties(defaultFallback = "paymentGlobalFallback")

  除了特别重要的核心业务有专属降级方法外,其他普通的可以通过@DefaultProperties(defaultFallback = "paymentGlobalFallback")统一跳转到统一处理结果页面

通用的和独享的各种分开,避免了代码膨胀,合理减少了代码量

@RestController
@Slf4j
@DefaultProperties(defaultFallback = "paymentGlobalFallback")
public class OrderController {
    @Resource
    OrderService orderService;

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
//    @HystrixCommand(fallbackMethod = "paymentInfoTimeOutHandle",commandProperties = {
//            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
//    })
    @HystrixCommand
    public String orderInfoTimeOut(@PathVariable(value="id") Integer id) {
        String result = orderService.paymentInfoTimeOut(id);
        return result;
    }

    private String paymentInfoTimeOutHandle(Integer id) {
        String result = "当前线程:" + Thread.currentThread().getName() +
                "\t" + "我是消费者80,对方支付系统繁忙请10秒后再试试或者自己运行出错请检查自己!!!" +
                "\t" + "服务降级";
        return result;
    }

    // 下面是全局的fallback
    public String paymentGlobalFallback() {
       return "消费者Global Fallback异常";
    }

}

  如果只添加@HystrixCommand注解,并没有指定具体的服务降级方法,则找全局@DefaultProperties中指定的方法,如果什么也没有加,就没有服务降级(就近原则,@HystrixCommand中指定服务降级方法就不调用全局的服务降级方法)

和业务逻辑混在一起???混乱

服务降级,客户端去调用服务端,碰上服务端宕机或者关机

  本次案例服务降级处理是在客户端80实现的,与服务端8090没有关系,只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦

未来我们要面对的异常:运行异常,超时异常,宕机

  创建一个OrderFallbackService,实现OrderService,然后添加@FeignClient(value = "CLOUD-PAYMENT-SERVER",fallback = OrderFallbackService.class)

1610803432870.png

宕机或者http访问超时都会导致调用上图所指向的方法,如果出现Htstrix超时或者方法出现运行异常都会导致服务降级

控制层代码

1610803432915.png

服务层代码

1610803432915.png

测试一下:

  • 启动注册中心
  • 启动支付服务
  • 启动订单消费者

  此时服务单provider已经宕机了,但是我们做了服务降级处理,让客户端在服务端不可用时候也会获得提示信息,而不会挂起耗时服务器