容错机制和熔断(Hystrix)

雪崩效应

在微服务架构中,由于服务众多,通常会涉及多个服务层级的调用,而一旦基础服务发生故障,很可能会导致级联故障,进而造成整个系统不可用,这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将这种不可用逐渐放大的过程。

比如在一个系统中, A作为服务提供者,B是A的服务消费者,C和D又是B的服务消费者。如果此时A发生故障,则会引起B的不可用,而B的不可用又将导致C和D的不可用,当这种不可用像滚雪球一样逐渐放大的时候,雪崩效应就形成了。

熔断器(CircuitBreaker)

熔断器的原理很简单,如同电力过载保护器。它可以实现快速失败,如果它在一段时间内侦测到许多类似的错误,就会强迫其以后的多个调用快速失败,不再访问远程服务器,从而防止应用程序不断地尝试执行可能会失败的操作,使得应用程序继续执行而不用等待修正错误,或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正,如果已经修正,应用程序会再次尝试调用操作。熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数,然后决定使用允许操作继续,或者立即返回错误。熔断器是保护服务高可用的最后一道防线。

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)来隔离资源。

Feign Hystrix

因为 Feign 中已经依赖了 Hystrix, 所以在 maven 配置上不用做任何改动就可以使用了,我们在 spring-cloud-consul-consumer 项目中直接改造。

修改配置

在配置文件中添加配置,开启 Hystrix 熔断器。

application.yml

#开启熔断器
feign:
  hystrix:
    enabled: true

创建回调类

创建一个回调类 FeignHelloHystrix,实现 FeignHelloService 接口,并实现对应的方法,返回调用失败后的信息。

FeignHelloHystrix.java

package com.louis.spring.cloud.consul.consumer.service;

import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.RequestMapping;

@Component
public class FeignHelloHystrix implements FeignHelloService {

    @RequestMapping("/hello")
    public String hello() {
        return "sorry, this service call failed.";
    }
}

添加fallback属性

修改 FeignHelloService,在 @FeignClient 注解中加入 fallback 属性,绑定我们创建的失败回调处理类。

package com.louis.spring.cloud.consul.consumer.service;

import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.RequestMapping;

@FeignClient(name = "service-producer", fallback = FeignHelloHystrix.class)
public interface FeignHelloService {

    @RequestMapping("/hello")
    public String hello();
}

到此,所有改动代码就完成了。

测试效果

为了方便测试,我们把负载均衡策略修改为轮询模式。

启动成功之后,多次访问 http://localhost:8521/feign/call,结果如同之前一样交替返回 hello consul 和 hello consul two。

说明熔断器的启动,不会影响正常服务的访问。

现在手动把 spring-cloud-consul-producer 的服务停掉,再次访问,返回我们提供的熔断回调信息,熔断成功。

重启 spring-cloud-consul-producer 服务,再次访问,发现服务又可以访问了,说明熔断器具有自我诊断修复的功能。

注意:在重启成功之后,可能需要一些时间,等待熔断器进行自我诊断和修复完成之后,方可正常提供服务。

原文地址:https://www.cnblogs.com/7788IT/p/10667083.html

时间: 2024-09-30 00:25:10

容错机制和熔断(Hystrix)的相关文章

SpringCloud 基础教程(五) 服务熔断机制(Eureka + Ribbon + Hystrix)

1.启动[服务中心]集群,即 Eureka Server 参考 SpringCloud 基础教程(一) 服务中心及集群(Eureka Server) 2.启动[服务提供者]集群,即 Eureka Client 参考 SpringCloud 基础教程(二) 服务注册及集群(Eureka Client) 3.启动[服务消费者],即 Eureka Discovery Client 参考 SpringCloud 基础教程(三) 服务发现及负载均衡(Eureka Discovery Client + Ri

ack是什么,如何使用Ack机制,如何关闭Ack机制,基本实现,STORM的消息容错机制,Ack机制

1.ack是什么 ack 机制是storm整个技术体系中非常闪亮的一个创新点. 通过Ack机制,spout发送出去的每一条消息,都可以确定是被成功处理或失败处理, 从而可以让开发者采取动作.比如在Meta中,成功被处理,即可更新偏移量,当失败时,重复发送数据. 因此,通过Ack机制,很容易做到保证所有数据均被处理,一条都不漏. 另外需要注意的,当spout触发fail动作时,不会自动重发失败的tuple,需要spout自己重新获取数据,手动重新再发送一次 ack机制即, spout发送的每一条消

RDD之七:Spark容错机制

引入 一般来说,分布式数据集的容错性有两种方式:数据检查点和记录数据的更新. 面向大规模数据分析,数据检查点操作成本很高,需要通过数据中心的网络连接在机器之间复制庞大的数据集,而网络带宽往往比内存带宽低得多,同时还需要消耗更多的存储资源. 因此,Spark选择记录更新的方式.但是,如果更新粒度太细太多,那么记录更新成本也不低.因此,RDD只支持粗粒度转换,即只记录单个块上执行的单个操作,然后将创建RDD的一系列变换序列(每个RDD都包含了他是如何由其他RDD变换过来的以及如何重建某一块数据的信息

架构师之路--搜索业务和技术介绍及容错机制

今天和搜索部门一起做了一下MQ的迁移,顺便交流一下业务和技术.发现现在90后小伙都挺不错.我是指能力和探究心.我家男孩,不招女婿. 在前面的文章中也提到,我们有媒资库(乐视视频音频本身内容)和全网作品库(外部视频音频内容),数据量级都在千万级.我们UV,PV,CV,VV都是保密的.所以作为一个合格的员工来说………………数值我也不知道.总之,这些数据作为最终数据源,要走一个跨多个部门的工作流才最终出现在用户点击搜索按钮出现的搜索框里.大体流程图如下: 这个流程图之所以没像以往一样手绘,嗯,那是因为

【Spark】Spark容错机制

引入 一般来说,分布式数据集的容错性有两种方式:数据检查点和记录数据的更新. 面向大规模数据分析,数据检查点操作成本很高,需要通过数据中心的网络连接在机器之间复制庞大的数据集,而网络带宽往往比内存带宽低得多,同时还需要消耗更多的存储资源. 因此,Spark选择记录更新的方式.但是,如果更新粒度太细太多,那么记录更新成本也不低.因此,RDD只支持粗粒度转换,即只记录单个块上执行的单个操作,然后将创建RDD的一系列变换序列(每个RDD都包含了他是如何由其他RDD变换过来的以及如何重建某一块数据的信息

RDD的容错机制

RDD的容错机制 RDD实现了基于Lineage的容错机制.RDD的转换关系,构成了compute chain,可以把这个compute chain认为是RDD之间演化的Lineage.在部分计算结果丢失时,只需要根据这个Lineage重算即可. 图1中,假如RDD2所在的计算作业先计算的话,那么计算完成后RDD1的结果就会被缓存起来.缓存起来的结果会被后续的计算使用.图中的示意是说RDD1的Partition2缓存丢失.如果现在计算RDD3所在的作业,那么它所依赖的Partition0.1.3

数据流容错机制

该文档翻译自Data Streaming Fault Tolerance,文档描述flink在流式数据流图上的容错机制. ------------------------------------------------------------------------------------------------- 一.介绍 flink提供了可以一致地恢复数据流应用的状态的容错机制,该机制保证即使在错误发生后,反射回数据流记录的程序的状态操作最终仅执行一次.值得注意的是,该保证可以降低为“至少执

13.容错机制

知识点: 容错机制 一.容错机制:master选举,replica容错,数据恢复 假设有9个shard(3个primary+6个replica), 3个node, 此时如果有一个master node宕机,容错机制如下: 就会有一个primary丢失,在短时间内,status 是red,ES会自动选取另一个node成为新的master node. 新产生的master shard 会将丢失的primay shard 的某一个replica shard 提升为primary shard,此时clu

Elasticsearch 横向扩容以及容错机制

写在前面的话:读书破万卷,编码如有神-------------------------------------------------------------------- 参考内容: <Elasticsearch顶尖高手系列-快速入门篇>,中华石杉 -------------------------------------------------------------------- 主要内容包括: 横向扩容 容错机制 ------------------------------------