Spring Cloud Hystrix 断路器

简介: 在微服务架构中,我们将系统拆分成了若干弱小的单元,单元与单元之间通过HTTP或者TCP等方式相互访问,各单元的应用间通过服务注册与订阅的方式相互依赖。由于每个单元都在不同的进程中运行,依赖远程调用的方式执行,这样就可能引起因为网速变慢或者网络故障导致请求变慢或超时,若此时调用方的请求在不断增加,最后就会因等待出现故障的依赖方响应形成任务积压,最终导致自身服务的瘫痪。

Spring Cloud Hystrix 服务容错保护一、Hystrix 是什么 雪崩效应 雪崩效应产生场景 常见解决方案二、Hystrix断路器搭建三、断路器优化

一、Hystrix 是什么

在微服务架构中,我们将系统拆分成了若干弱小的单元,单元与单元之间通过HTTP或者TCP等方式相互访问,各单元的应用间通过服务注册与订阅的方式相互依赖。由于每个单元都在不同的进程中运行,依赖远程调用的方式执行,这样就可能引起因为网速变慢或者网络故障导致请求变慢或超时,若此时调用方的请求在不断增加,最后就会因等待出现故障的依赖方响应形成任务积压,最终导致自身服务的瘫痪。

Hystrix 是Netflix 中的一个组件库,它隔离了服务之间的访问点,阻止了故障节点之间可能会引起的雪崩效应,并提供了后备选项。

在微服务架构中,存在着许多的服务单元,若单一节点的故障,就很容易因为依赖关系而引发故障的蔓延,最终导致整个生态系统的瘫痪。为了解决这样的问题,产生了断路器等一系列的保护机制措施。

分布式架构中,断路器模式的作用也是类似的,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个错误响应,而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放,避免了故障在分布式系统中的蔓延。

雪崩效应

雪崩效应就像是水滴石穿,蝴蝶效应一样,是指微小的事物随着时间的推移,会变得越来越巨大,从而对整个环境造成影响的现象。例如:在生态系统中,某一类物种的灭绝可能对整个生态系统造成不了太大的损失,但是这类物种的灭绝可能会引发其他物种的死亡,其他物种的灭绝又会影响另外一种物种的灭亡,就像雪球越滚越大,最终会导致整个生态系统的崩溃。

21.jpg


如上图所示:A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者。A不可用引起了B的不可用,并将不可用像滚雪球一样放大到C和D时,雪崩效应就形成了。

雪崩效应产生场景

  • 流量激增: 比如异常流量,用户重试导致系统负载升高;

  • 缓存刷新: 假设A为client端,B为Server端,假设A系统请求都流向B系统,请求超出了B系统的承载能力,就会造成B系统崩溃
  • 连接未释放: 代码循环调用的逻辑问题,资源未释放引起的内存泄漏等问题;
  • 硬件故障: 比如宕机,机房断电等
  • 线程同步等待: 系统间经常采用同步服务调用模式,核心服务和非核心服务共用一个线程池和消息队列。如果一个核心业务线程调用非核心业务线程,这个非核心线程交由第三方系统完成,当第三方系统本身出现问题,导致核心线程阻塞,一直处于等待状态,而进程间的调用是有超时限制的,最终这条线程将断掉,也可能引发雪崩;

常见解决方案

针对上述的雪崩问题,每一条都有一个自己的解决方案,但是任何一个解决方案能够应对所有场景

  • 针对流量激增,采用自动扩容以应对流量激增,或者在负载均衡器上安装限流模块
  • 针对缓存刷新,参考Cache应用的服务过载案例研究
  • 针对硬件故障,采用多机房灾备,跨机房路由
  • 针对同步等待,采用线程隔离,熔断器等机制
    通过实践发现,线程同步等待是最常见引发的雪崩效应的场景。

二、Hystrix断路器搭建

在开始使用Spring Cloud Hystrix断路器之前,我们先用之前实现的一些内容作为基础,构建一个如下图所示的服务调用关系:

22.jpg


如图所示,上面需要的角色有三个,服务有四个

  • ribbon-connsumer: ribbon消费者,消费server-provider提供的服务
  • server-provider: 服务提供者,提供服务供消费者消费(有点像父母默默的付出一样),启动两个实例,还记得怎么启动吗?—server.port 启动
  • eureka-server: eureka注册中心,提供最基本的订阅发布功能。消费者和服务提供者都需要往注册中心注册自己

依次启动上面的四个服务,发现注册中心已经成功注册了四个服务(包括自己)

23.jpg


  • 调用http://localhost:9000/ribbon-consumer 发现能够通过Ribbon进行远端调用


  • 在未加入断路器之前,关闭ribbon-consumer 的连接,再次调用http://localhost:9000/ribbon-consumer,发现服务无法提供(使用Postman 测试)

24.jpg

下面开始引入Hystrix

  • 在ribbon-consumer 工程的pom.xml的dependency节点下引入spring-cloud-starter-hystrix依赖
  • 在ribbon-consumer 工程的主加载类中添加@EnableCircuitBreaker开启断路器的功能

注意:这里也可以使用@SpringCloudApplication注解来修饰应用主类,具体定义如下

@Target(ElementType.TYPE)
  @Retention(RetentionPolicy.RUNTIME)
  @Documented
  @Inherited
  @SpringBootApplication
  @EnableDiscoveryClient
  @EnableCircuitBreaker
  public @interface SpringCloudApplication {}

SpringCloudApplication 注解上有@EnableCircuitBreaker 注解,用来开启断路器的功能,其他主要注解是@SpringBootApplication ,这个注解是SpringBoot的启动类注解, @EnableDiscoveryClient该注解可以发现Eureka注册中心

  • 改造消费方式,新增HystrixService类,并且注入RestTemplate实例,然后,将在RibbonController中对RestTemplate 的使用迁移到hystrixService方法中,最后,在hystrixService上添加@HystrixCommand注解来指定回掉方法。


// HystrixService

@Service
public class HystrixService {
@Resource
RestTemplate restTemplate;
// 指定回掉方法是下面的hystrixCallback
@HystrixCommand(fallbackMethod = "hystrixCallBack")
public String hystrixService(){
return restTemplate.getForEntity("http://server-provider/hystrix";,String.class).getBody();
}
public String hystrixCallBack(){
return "error";
}
}


  • 服务提供者的业务非常简单,具体代码如下



@RequestMapping(value = "/hystrix", method = RequestMethod.GET)
public String hystrix(){
return "hystrix";
}


  • 下面来验证一下通过断路器的回掉实现,重启之前关闭的8081端口,恢复成为四个服务的状态,并确保http://localhost:9000/ribbon-consumer/ 能够提供服务,并且以轮询的方式循环访问8081 和 8082 端口的服务。此时断开8081端口,发现页面上展示的不再是 hystrix ,而是"error",而另一个服务是正常能够打印。

三、断路器优化

经过以上服务的搭建,相信你已经能够搭建出来最基本的Hystrix熔断器,并且实现了服务熔断机制,下面就来对断路器做一下简单的优化,来模拟服务阻塞(长时间未响应)的情况。

优化server-provider代码如下:

@RequestMapping(value = "/hystrix", method = RequestMethod.GET)
public String hystrix() throws InterruptedException {
ServiceInstance serviceInstance = discoveryClient.getLocalServiceInstance();
// 让线程等待几秒钟
int sleepTime = new Random().nextInt(3000);
Thread.sleep(sleepTime);
System.out.println("weak up!!!");
log.info("sleepTime = " + sleepTime);
return "hystrix";
}

依次启动所有的服务,在主页上访问 http://localhost:9000/ribbon-consumer ,多次刷新主页,发现error 和 hystrix 是交替出现的,这是为何?

因为hystrix断路器的默认超时时间是2000毫秒,所以这里采用了0 - 3000 的随机数,也就是访问请求在 0 -2000 毫秒内是不超时的,不会触发断路器,而> 2000 毫秒是超市的,默认会触发断路器。

            </div>
目录
相关文章
|
3月前
|
Java UED 开发者
Spring Boot 降级功能的神秘面纱:Hystrix 与 Resilience4j 究竟藏着怎样的秘密?
【8月更文挑战第29天】在分布式系统中,服务稳定性至关重要。为应对故障,Spring Boot 提供了 Hystrix 和 Resilience4j 两种降级工具。Hystrix 作为 Netflix 的容错框架,通过隔离依赖、控制并发及降级机制增强系统稳定性;Resilience4j 则是一个轻量级库,提供丰富的降级策略。两者均可有效提升系统可靠性,具体选择取决于需求与场景。在面对服务故障时,合理运用这些工具能确保系统基本功能正常运作,优化用户体验。以上简介包括了两个工具的简单示例代码,帮助开发者更好地理解和应用。
61 0
|
4月前
|
设计模式 监控 Java
解析Spring Cloud中的断路器模式原理
解析Spring Cloud中的断路器模式原理
|
2月前
|
XML 监控 Java
Spring Cloud全解析:熔断之Hystrix简介
Hystrix 是由 Netflix 开源的延迟和容错库,用于提高分布式系统的弹性。它通过断路器模式、资源隔离、服务降级及限流等机制防止服务雪崩。Hystrix 基于命令模式,通过 `HystrixCommand` 封装对外部依赖的调用逻辑。断路器能在依赖服务故障时快速返回备选响应,避免长时间等待。此外,Hystrix 还提供了监控功能,能够实时监控运行指标和配置变化。依赖管理方面,可通过 `@EnableHystrix` 启用 Hystrix 支持,并配置全局或局部的降级策略。结合 Feign 可实现客户端的服务降级。
153 23
|
2月前
|
Java 对象存储 开发者
故障隔离与容错处理:Hystrix在Spring Cloud和Netflix OSS中的应用
故障隔离与容错处理:Hystrix在Spring Cloud和Netflix OSS中的应用
51 3
|
2月前
|
Java 微服务 Spring
微服务(九)-Hystrix(断路器)
微服务(九)-Hystrix(断路器)
|
4月前
|
监控 Java 数据中心
通用快照方案问题之服务雪崩问题如何解决
通用快照方案问题之服务雪崩问题如何解决
21 0
|
4月前
|
设计模式 监控 Java
深入理解Spring Cloud中的断路器模式
深入理解Spring Cloud中的断路器模式
|
5月前
|
监控 Java 微服务
Spring Cloud 之 Hystrix
Spring Cloud Hystrix 是一个用于处理分布式系统延迟和容错的库,防止雪崩效应。它作为断路器,当服务故障时通过监控短路,返回备用响应,保持系统弹性。主要功能包括服务降级和熔断:
|
API
springcloud之hystrix熔断器-Finchley.SR2版
本篇和大家分享的是springcloud-hystrix熔断器,其主要功能是对某模块调用失败做断路和降级,简单点就当某个模块程序出问题了并达到某阈值就限制后面请求,并降级的方式提供一个默认返回数据。最近在琢磨hystrix源码,琢磨思路写一个自己的简易熔断器,希望大家后期关注。
2848 0
|
2月前
|
SQL 监控 druid
springboot-druid数据源的配置方式及配置后台监控-自定义和导入stater(推荐-简单方便使用)两种方式配置druid数据源
这篇文章介绍了如何在Spring Boot项目中配置和监控Druid数据源,包括自定义配置和使用Spring Boot Starter两种方法。