springcloud_Hystrix(熔断器)
为什么需要 Hystrix?
在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用(RPC)。为了保证其高可用,单个服务又必须集群部署。由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务累计,导致服务瘫痪,甚至导致服务“雪崩”。为了解决这个问题,就出现断路器模型。
Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库, 它同样拥有保护系统的能力.什么是服务雪崩
分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应. 为了应对服务雪崩, 一种常见的做法是手动服务降级. 而Hystrix的出现,给我们提供了另一种选择.
服务雪崩应对策略
针对造成服务雪崩的不同原因, 可以使用不同的应对策略:
1. 流量控制
2. 改进缓存模式
3. 服务自动扩容
4. 服务调用者降级服务
流量控制 的具体措施包括:
· 网关限流
· 用户交互限流
· 关闭重试
服务雪崩解决办法
1.服务雪崩的原因
(1)某几个机器故障:例如机器的硬驱动引起的错误,或者一些特定的机器上出现一些的bug(如,内存中断或者死锁)。
(2)服务器负载发生变化:某些时候服务会因为用户行为造成请求无法及时处理从而导致雪崩,例如阿里的双十一活动,若没有提前增加机器预估流量则会造服务器压力会骤然增大二挂掉。
(3)人为因素:比如代码中的路径在某个时候出现bug
2.解决或缓解服务雪崩的方案
一般情况对于服务依赖的保护主要有3中解决方案:
(1)熔断模式:这种模式主要是参考电路熔断,如果一条线路电压过高,保险丝会熔断,防止火灾。放到我们的系统中,如果某个目标服务调用慢或者有大量超时,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
(2)隔离模式:这种模式就像对系统请求按类型划分成一个个小岛的一样,当某个小岛被火少光了,不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离,每种类型的请求互不影响,如果一种类型的请求线程资源耗尽,则对后续的该类型请求直接返回,不再调用后续资源。这种模式使用场景非常多,例如将一个服务拆开,对于重要的服务使用单独服务器来部署,再或者公司最近推广的多中心。
(3)限流模式:上述的熔断模式和隔离模式都属于出错后的容错处理机制,而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值,若高于设置的阈值则对该请求直接返回,不再调用后续资源。这种模式不能解决服务依赖的问题,只能解决系统整体资源分配问题,因为没有被限流的请求依然有可能造成雪崩效应。
3.熔断设计
在熔断的设计主要参考了hystrix的做法。其中最重要的是三个模块:熔断请求判断算法、熔断恢复机制、熔断报警
(1)熔断请求判断机制算法:使用无锁循环队列计数,每个熔断器默认维护10个bucket,每1秒一个bucket,每个blucket记录请求的成功、失败、超时、拒绝的状态,默认错误超过50%且10秒内超过20个请求进行中断拦截。
(2)熔断恢复:对于被熔断的请求,每隔5s允许部分请求通过,若请求都是健康的(RT<250ms)则对请求健康恢复。
(3)熔断报警:对于熔断的请求打日志,异常请求超过某些设定则报警
4.隔离设计
隔离的方式一般使用两种
(1)线程池隔离模式:使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)
(2)信号量隔离模式:使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服务)
5 超时机制设计
超时分两种,一种是请求的等待超时,一种是请求运行超时。
等待超时:在任务入队列时设置任务入队列时间,并判断队头的任务入队列时间是否大于超时时间,超过则丢弃任务。
运行超时:直接可使用线程池提供的get方法
什么是熔断机制
熔断机制,就是下游服务出现问题后,为保证整个系统正常运行下去,而提供一种降级服务的机制,通过返回缓存数据或者既定数据,避免出现系统整体雪崩效应。在springcloud中,该功能可通过配置的方式加入到项目中。
Hystrix作用
基于命令模式的请求:解耦了请求者和接受者,使得发送出去的命令可以排队、异步执行。
资源隔离:用ConcurrentHashMap绑定commandKey和线程池,当某个功能运行不稳定或有问题时,服务的其他部分不受影响。服务恢复比较快。
熔断和服务降级:用ConcurrentHashMap绑定commandKey和HystrixCircuitBreaker类(断路器类),统计每次请求的结果并记录,根据结果判断是否开启断路器,自定义异常返回结果实现熔断降级。
服务降级案例
一、创建服务注册中心项目spring_server
1 向pom文件导入节点
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.4.RELEASE</version>
</parent>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<dependencyManagement>
<dependencies>
<!--springCloud依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Greenwich.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
2 创建application.yml文件
##应用名称
spring:
application:
name: euraka-server
#声明当前 eurakaserver端口号
server:
port: 8888
#配置eureka
eureka:
client:
#代表自己是否注册到注册中心去
register-with-eureka: false
#表明自己是注册中心
fetch-registry: false
#配置地址
service-url:
defaultZone: http://localhost:8888/eureka
3 创建启动程序类
@SpringBootApplication
@EnableEurekaServer
public class StartEurekaService {
public static void main(String[] args) {
SpringApplication.run(StartEurekaService.class,args);
}
}
4 运行效果

二、创建项目 springcloud_eureka_member
1 创建service层接口
public interface MemberService {
public String getMember();
}
2 创建service层接口实现类
@RestController
public class MemberServiceImpl implements MemberService {
@RequestMapping("/getMember")
@Override
public String getMember() {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("member getMember方法");
return "member";
}
}
3 创建application.yml文件
##应用名称
spring:
application:
name: member-server
#声明当前 eurakaserver端口号
server:
port: 9001
#配置eureka
eureka:
client:
#配置地址
service-url:
defaultZone: http://localhost:8888/eureka
4 创建启动项目类
@SpringBootApplication
@EnableEurekaClient
public class StartProvider {
public static void main(String[] args) {
SpringApplication.run(StartProvider.class,args);
}
}
5 运行效果



三、创建项目springcloud_eureka_order
1 创建service层接口
@FeignClient("member-server")
public interface OrderService {
@RequestMapping("/member")
public String getOrder();
}
2 创建service层接口实现类
@RestController
public class OrderServiceImpl implements OrderService {
@RequestMapping("/getOrder")
@Override
public String getOrder() {
System.out.println("===============订单工程OrderService接口================");
return "orders";
}
}
3 创建 Controller层
@RestController
public class OrderConroller {
@Resource
private MemberService memberService;
@RequestMapping("/getOrderByMember")
public String getOrderByMember(){
return memberService.getMember();
}
@RequestMapping("/orderinfo")
public String getOne(){
return "orderinfo";
}
}
4 创建application.yml文件
##应用名称
spring:
application:
name: order-server
main:
allow bean definition overriding: true
#声明当前 eurakaserver端口号
server:
port: 9002
#配置eureka
eureka:
client:
#配置地址
service-url:
defaultZone: http://localhost:8888/eureka
5 创建启动程序类
@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
public class StartProvider {
public static void main(String[] args) {
SpringApplication.run(StartProvider.class, args);
}
}
6 启动测试工具

6 运行效果

我们在springcloud_eureka_member中利用线程模拟了雪崩场景,如果当我们请求一个地址时大于一秒没有请求出来就代表请求失败,我们使用测试工具实现
在 同一时间用3000个线程访问同一个地址时,另一个地址会等待一直转圈,直到访问另一个地址的线程有空闲线程再来请求这个地址,我们将使用服务降级来解决
所谓的降级指的是当服务的提供方不可使用的时候,程序不会出现异常,而会出现本地的操作调
7 在springclou_eureka_order中application.yml添加节点
##配置ribbon读取时间
ribbon:
ReadTimeout: 15000
ConnectTimeout: 15000
##开启断路器
feign:
hystrix:
enabled: true
##因为我们在members服务中线程休眠3s,服务调用默认超过1s当做调用失败,那么就会执行服务降级的类,我们可以配置服务响应时间
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 4000
8 在springclou_eureka_order中创建MemberService
/**
* fallback服务降级执行得本地类
*/
@FeignClient(value = "member-server",fallback = MemberServiceFallBack.class)
public interface MemberService {
/**
* 获取会员信息
* @return
*/
@RequestMapping("/getMember")
public String getMember();
}
9 创建MemberServiceFallBack实现MemberService
/**
* 本地服务
*/
@Component
public class MemberServiceFallBack implements MemberService {
@Override
public String getMember() {
return "服务降级";
}
}
10 开启测试工具运行效果
当请求地址没有反应会直接请求本地方法

为什么需要 Hystrix?
在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用(RPC)。为了保证其高可用,单个服务又必须集群部署。由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务累计,导致服务瘫痪,甚至导致服务“雪崩”。为了解决这个问题,就出现断路器模型。
Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库, 它同样拥有保护系统的能力.什么是服务雪崩
分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应. 为了应对服务雪崩, 一种常见的做法是手动服务降级. 而Hystrix的出现,给我们提供了另一种选择.
服务雪崩应对策略
针对造成服务雪崩的不同原因, 可以使用不同的应对策略:
1. 流量控制
2. 改进缓存模式
3. 服务自动扩容
4. 服务调用者降级服务
流量控制 的具体措施包括:
· 网关限流
· 用户交互限流
· 关闭重试
服务雪崩解决办法
1.服务雪崩的原因
(1)某几个机器故障:例如机器的硬驱动引起的错误,或者一些特定的机器上出现一些的bug(如,内存中断或者死锁)。
(2)服务器负载发生变化:某些时候服务会因为用户行为造成请求无法及时处理从而导致雪崩,例如阿里的双十一活动,若没有提前增加机器预估流量则会造服务器压力会骤然增大二挂掉。
(3)人为因素:比如代码中的路径在某个时候出现bug
2.解决或缓解服务雪崩的方案
一般情况对于服务依赖的保护主要有3中解决方案:
(1)熔断模式:这种模式主要是参考电路熔断,如果一条线路电压过高,保险丝会熔断,防止火灾。放到我们的系统中,如果某个目标服务调用慢或者有大量超时,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
(2)隔离模式:这种模式就像对系统请求按类型划分成一个个小岛的一样,当某个小岛被火少光了,不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离,每种类型的请求互不影响,如果一种类型的请求线程资源耗尽,则对后续的该类型请求直接返回,不再调用后续资源。这种模式使用场景非常多,例如将一个服务拆开,对于重要的服务使用单独服务器来部署,再或者公司最近推广的多中心。
(3)限流模式:上述的熔断模式和隔离模式都属于出错后的容错处理机制,而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值,若高于设置的阈值则对该请求直接返回,不再调用后续资源。这种模式不能解决服务依赖的问题,只能解决系统整体资源分配问题,因为没有被限流的请求依然有可能造成雪崩效应。
3.熔断设计
在熔断的设计主要参考了hystrix的做法。其中最重要的是三个模块:熔断请求判断算法、熔断恢复机制、熔断报警
(1)熔断请求判断机制算法:使用无锁循环队列计数,每个熔断器默认维护10个bucket,每1秒一个bucket,每个blucket记录请求的成功、失败、超时、拒绝的状态,默认错误超过50%且10秒内超过20个请求进行中断拦截。
(2)熔断恢复:对于被熔断的请求,每隔5s允许部分请求通过,若请求都是健康的(RT<250ms)则对请求健康恢复。
(3)熔断报警:对于熔断的请求打日志,异常请求超过某些设定则报警
4.隔离设计
隔离的方式一般使用两种
(1)线程池隔离模式:使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)
(2)信号量隔离模式:使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服务)
5 超时机制设计
超时分两种,一种是请求的等待超时,一种是请求运行超时。
等待超时:在任务入队列时设置任务入队列时间,并判断队头的任务入队列时间是否大于超时时间,超过则丢弃任务。
运行超时:直接可使用线程池提供的get方法
什么是熔断机制
熔断机制,就是下游服务出现问题后,为保证整个系统正常运行下去,而提供一种降级服务的机制,通过返回缓存数据或者既定数据,避免出现系统整体雪崩效应。在springcloud中,该功能可通过配置的方式加入到项目中。
Hystrix作用
1.断路器机制
断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2.Fallback
Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.
3.资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.
springcloud_Hystrix(熔断器)的更多相关文章
- 熔断器设计模式<转>
熔断器设计模式 如果大家有印象的话,尤其是夏天,如果家里用电负载过大,比如开了很多家用电器,就会”自动跳闸”,此时电路就会断开.在以前更古老的一种方式是”保险丝”,当负载过大,或者电路发生故障或异常时 ...
- 设计模式--状态模式(分布式中间件熔断器Java实现)
最近在做分布式服务熔断,因为要实现一个熔断器状态机,所以想到状态模式.状态模式是当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类.状态模式主要解决的是当控制一个对象状态的条件表达 ...
- springcloud(四):熔断器Hystrix
说起springcloud熔断让我想起了去年股市中的熔断,多次痛的领悟,随意实施的熔断对整个系统的影响是灾难性的,好了接下来我们还是说正事. 熔断器 雪崩效应 在微服务架构中通常会有多个服务层调用,基 ...
- springCloud四:熔断器ribbon--Hystrix
注:前文概念部分摘抄自博客园 纯洁的微笑 熔断器 雪崩效应 在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应.服务雪崩 ...
- springcloud之hystrix熔断器-Finchley.SR2版
本篇和大家分享的是springcloud-hystrix熔断器,其主要功能是对某模块调用失败做断路和降级,简单点就当某个模块程序出问题了并达到某阈值就限制后面请求,并降级的方式提供一个默认返回数据.最 ...
- go笔记-熔断器
参考: https://studygolang.com/articles/13254 区别:(限速器 VS 熔断器) 限速器(limiter)可以限制接口自身被调的频率 熔断器可监控所调用的服务的失败 ...
- SpringCloud(4)熔断器 Hystrix
在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用.为了保证其高可用,单个服务 ...
- SpringCloud学习笔记:熔断器Hystrix(5)
1. Hystrix简介 在分布式系统中,服务与服务之间相互依赖,一种不可避免的情况是某些服务会出现故障,导致依赖于它们的其他服务出现远程调度的线程阻塞. Hystrix提供熔断器功能,能够阻止分布式 ...
- spring cloud(四)熔断器Hystrix
熔断器 雪崩效应 在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应.服务雪崩效应是一种因“服务提供者”的不可用导致“服务 ...
随机推荐
- SpringBoot扩展点之二:ApplicationRunner和CommandLineRunner的扩展
CommandLineRunner并不是Spring框架原有的概念,它属于SpringBoot应用特定的回调扩展接口: public interface CommandLineRunner { /** ...
- java小程序---简陋版多人聊天室
功能需求: 1 每运行一次主函数,创建一个客户端聊天界面; 2 客户端界面分三块,公屏(显示所有客户端发送的信息),私屏(用于输入个人想要发送的信息),发送按钮(点击一次,将客户端信息发送到服务端) ...
- vivado sdx 綜合報錯ERROR: [SdsCompiler 83-5019] Exiting sds++ : Error when calling 'aarch64-linux-gnu-g++ -c
ERROR: [SdsCompiler 83-5019] Exiting sds++ : Error when calling 'aarch64-linux-gnu-g++ -c 主函數 添加 頭文件 ...
- C# - List.Sort()自定义排序方法
本文通过示例介绍了C#中典型容器List.Sort()的自定义排序方法,进而引出了C#中自定义排序的核心接口及方法 项目地址:自定义Sort方法 - SouthBegonia's Github Lis ...
- C# GDI graphics.DrawImage 的参数问题
graphics.DrawImage(imageSource, new System.Drawing.Point[] { ,), , ), , ), } ); graphics.DrawImage(i ...
- RabbitMQ学习之RPC(6)
在第二个教程中,我们了解到如何在多个worker中使用Work Queues分发费时的任务. 但是,如果我们需要在远程运行一个函数并且等待结果该怎么办呢?这个时候,我们需要另外一个模式了.这种模式通常 ...
- Java自学-接口与继承 对象转型
Java中的对象转型 示例 1 : 明确引用类型与对象类型的概念 首先,明确引用类型与对象类型的概念 在这个例子里,有一个对象 new ADHero(), 同时也有一个引用ad 对象是有类型的, 是A ...
- 26、router.beforeEach路由拦截
为了防止用户未登录直接修改路径来访问页面,解决办法: 在main.js文件中加入以下代码: // 路由拦截 router.beforeEach((to, from, next) => { if ...
- 11、多行文本最后一行显示省略号并截取文本字数(vue)
1.首先通过css实现多行文本显示省略号: { height: 45px; display: -webkit-box; -webkit-box-orient: vertical; -webkit-li ...
- FreePascal - CodeTyphon 和 Lazarus, 如何像Delphi一样有代码之间的连线?
CodeTyphon 6.9 默认CodeTyphon没有开启代码之间连线功能,一直不知道如何调出来,在使用CodeTyphon 和 Lazarus 很渴望也能像Delphi那样有这种功能,实际上它们 ...