Hystrix

Hystrix#

1. 服务雪崩#

服务雪崩的本质：线程没有及时回收。

不管是调用成功还是失败，只要线程可以及时回收，就可以解决服务雪崩

1.2 服务雪崩怎么解决#

1.2.1 修改调用的超时时长（不推荐）#

将服务间的调用超时时长改小，这样就可以让线程及时回收，保证服务可用

优点：非常简单，也可以有效的解决服务雪崩

缺点：不够灵活，有的服务需要更长的时间去处理（写库，整理数据）

1.2.2 设置拦截器#

2. Hystrix简介#

在分布式环境中，不可避免地会有许多服务依赖项中的某些失败。Hystrix是一个库，可通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体弹性。

总体来说 [Hystrix] 就是一个能进行熔断和降级的库，通过使用它能提高整个系统的弹性。

2.1 熔断#

熔断就是服务雪崩的一种有效解决方案。当指定时间窗内的请求失败率达到设定阈值时，系统将通过 断路器 直接将此请求链路断开。

其实这里所讲的熔断就是指的 [Hystrix]中的 断路器模式 ，你可以使用简单的 @[Hystrix]Command 注解来标注某个方法，这样 [Hystrix]就会使用 断路器 来“包装”这个方法，每当调用时间超过指定时间时(默认为1000ms)，断路器将会中断对这个方法的调用。

@HystrixCommand(
    commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1200")}
)
public List<Xxx> getXxxx() {
    // ...省略代码逻辑
}

2.2 降级#

降级是为了更好的用户体验，当一个方法调用异常时，通过执行另一种代码逻辑来给用户友好的回复。这也就对应着 [Hystrix]的 后备处理 模式。你可以通过设置 fallbackMethod 来给一个方法设置备用的代码逻辑。

你可以通过设置 fallbackMethod 来给一个方法设置备用的代码逻辑。比如这个时候有一个热点新闻出现了，我们会推荐给用户查看详情，然后用户会通过id去查询新闻的详情，但是因为这条新闻太火了(比如最近什么*易对吧)，大量用户同时访问可能会导致系统崩溃，那么我们就进行 服务降级 ，一些请求会做一些降级处理比如当前人数太多请稍后查看等等。

// 指定了后备方法调用
@HystrixCommand(fallbackMethod = "getHystrixNews")
@GetMapping("/get/news")
public News getNews(@PathVariable("id") int id) {
    // 调用新闻系统的获取新闻api 代码逻辑省略
}
//
public News getHystrixNews(@PathVariable("id") int id) {
    // 做服务降级
    // 返回当前人数太多，请稍后查看
}

2.3 在 OpenFeign 中使用 Hystrix（重点）#

在消费者端使用而不是生产端

配置文件

feign:
    hystrix:
        enabled: true  # 在cloud的F版以前 是默认开启的 但是因为后来有了其他的熔断组件

修改Fegin接口

/**
 * 这里需要指定熔断的类
 */
@FeignClient(value = "rent-car-service",fallback = CustomerRentFeignHystrix.class)
public interface CustomerRentFeign {

    @GetMapping("rent")
    String rent();


}

继承接口。实现备用方法

/**
 * 这里需要加入ioc容器
 */
@Component
public class CustomerRentFeignHystrix implements CustomerRentFeign {

    /**
     * 这个方法就是备选方案
     * @return
     */
    @Override
    public String rent() {
        return "我是备胎";
    }
}

2.4 Hystrix的常用配置#

hystrix:    #hystrix的全局控制
    command:
        default:    #default是全局控制，也可以换成单个方法控制，把default换成方法名即可
            circuitBreaker:
                enabled: true   #开启断路器
                requestVolumeThreshold: 3   #失败次数（阀值）  10次
                sleepWindowInMilliseconds: 20000    #窗口时间
                errorThresholdPercentage: 60    #失败率
            execution:
                isolation:
                    Strategy: thread  #隔离方式 thread线程隔离集合和semaphore信号量隔离级别
                    thread:
                        timeoutInMilliseconds: 3000 #调用超时时长
            fallback:
                isolation:
                    semaphore:
                        maxConcurrentRequests: 1000 #信号量隔离级别最大并发数

#隔离方式 两种隔离方式  thread线程池 按照group（10个线程）划分服务提供者，用户请求的线程和做远程的线程不一样
# 好处 当B服务调用失败了 或者请求B服务的量太大了 不会对C服务造成影响 用户访问比较大的情况下使用比较好  异步的方式
# 缺点 线程间切换开销大，对机器性能影响
# 应用场景 调用第三方服务 并发量大的情况下
# SEMAPHORE信号量隔离 每次请进来 有一个原子计数器 做请求次数的++  当请求完成以后 --
# 好处 对cpu开销小
# 缺点 并发请求不易太多 当请求过多 就会拒绝请求 做一个保护机制
# 场景 使用内部调用 ，并发小的情况下
# 源码入门  HystrixCommand  AbstractCommand HystrixThreadPool