SpringCloud Hystrix熔断

56 阅读 0 评论 37 点赞

我是靠谱客的博主忧伤面包，最近开发中收集的这篇文章主要介绍SpringCloud Hystrix熔断，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1、熔断的必要性

java中每次http请求都会开启一个新线程，当他的下游服务挂了，这个线程就会阻塞，阻塞到请求timeout。当遇到高并发，这些阻塞的线程会占用大量的资源，最终导致这个服务也挂掉。随着时间推移，最终导致跟这些服务有关联的服务都会挂掉。这也叫“雪崩效应”。

2、Hystrix原理

一、断路器
断路器总共三个状态：关闭、开启、半开
关闭：一开始是关闭状态，所有请求都可以通过；
开启：当错误请求到达一定阈值，会从关闭状态变为开启状态，直接让所有请求短路，返回失败响应；
半开：一段时间后，会从开启状态变为半开状态，这时，如果下个请求成功则变为关闭状态，若失败则变为开启状态；
1、hystrix.command.default.circuitBreaker.requestVolumeThreshold（当在配置时间窗口内达到此数量的失败后，进行短路。默认20个）简言之，10s内请求失败数量达到20个，断路器就会变成打开状态。
2、hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds（短路多久以后开始尝试是否恢复，默认5s）
3、hystrix.command.default.circuitBreaker.errorThresholdPercentage（出错百分比阈值，当达到此阈值后，开始短路。默认50%）
二、资源隔离
资源隔离分为两种：线程池隔离、信号量隔离
线程池隔离：不同服务的执行使用不同的线程池，同时将用户请求的线程与具体业务执行的线程分开（用户请求的线程池为web容器的线程池，即tomcat容器提供的线程池），业务执行的线程池可以控制在指定的大小范围内。一个服务的线程池全部占用阻塞了，也不会影响其他服务的线程池的使用，从而达到隔离的效果。
缺点：增加了计算的开销，每个业务请求在执行的时候，会涉及请求排队、线程调度、上下文切换等处理。
信号量隔离：用户请求线程和业务执行线程是同一线程，通过设置信号量的大小限制用户请求对业务的并发访问量，从而达到限流的保护效果。
缺点：信号量隔离只是起了个限制作用，它的保护能力有限：如果下游服务有问题，长时间不返回结果。本身信号量隔离对这个单个请求是起不到任何作用的。它只能限制这样的请求太多了就拒绝，不让整个服务挂。
差别：相对于线程池隔离更加轻量级，对计算的开销较小
execution.isolation.strategy：设置服务隔离策略。THREAD为线程池隔离，SEMAPHORE为信号量隔离。默认为THREAD。
execution.isolation.thread.timeoutInMilliseconds：用来设置线程池隔离和信号量隔离两种策略的超时时间，单位为毫秒，默认值为1000ms。
execution.isolation.semaphore.maxConcurrentRequests：设置使用信号量隔离时最的信号量大小。当请求达到或超过时，就会被降级处理，默认值为10。
execution.timeout.enabled：是否开启业务服务超时处理，默认为true。
execution.isolation.thread.interruptOnTimeout：当业务超时时是否中断线程，默认值为true。
execution.isolation.thread.interruptOnCancel：取消时是否中断服务的执行，默认值为false。