spring-cloud-starter-hystrix(断路器)服务不通或者调用失败后的错误处理和回调

雪崩效应

在微服务架构中通常会有多个服务层调用,大量的微服务通过网络进行通信,从而支撑起整个系统。各个微服务之间也难免存在大量的依赖关系。然而任何服务都不是100%可用的,网络往往也是脆弱的,所以难免有些请求会失败。基础服务的故障导致级联故障,进而造成了整个系统的不可用,这种现象被称为服务雪崩效应。服务雪崩效应描述的是一种因服务提供者的不可用导致服务消费者的不可用,并将不可用逐渐放大的过程。

Netflix Hystrix断路器

Netflix的Hystrix类库实现了断路器模式,在微服务架构中有多个层的服务调用。一个低水平的服务群中一个服务挂掉会给用户导致级联失效。调用一个特定的服务达到一定阈值(在Hystrix里默认是5秒内20个失败),断路由开启并且调用没有成功的。开发人员能够提供错误原因和开启一个断路由回调。

断路器简介

Netflix has created a library called Hystrix that implements the circuit breaker pattern. In a microservice architecture it is common to have multiple layers of service calls.

—-摘自官网

Netflix已经创建了一个名为Hystrix的库来实现断路器模式。 在微服务架构中,多层服务调用是非常常见的。

较底层的服务如果出现故障,会导致连锁故障。当对特定的服务的调用达到一个阀值(hystric 是5秒20次) 断路器将会被打开。

断路打开后,可用避免连锁故障,fallback方法可以直接返回一个固定值。

使用Hystrix

第一步:

POM添加依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
        </dependency>

Application入口main方法上增加@EnableCircuitBreaker注解

第二步:

基于RestTemplate的调用方式集成:

在方法上加上@HystrixCommand,并指定fallbackMethod方法。

@Service
public class HelloService {

    @Autowired
    RestTemplate restTemplate;

    @HystrixCommand(fallbackMethod = "hiError")
    public String hiService(String name) {
        return restTemplate.getForObject("http://SERVICE-HI/hi?name="+name,String.class);
    }

    public String hiError(String name) {
        return "hi,"+name+",sorry,error!";
    }
}

基于Feign的方式:

在SchedualServiceHi接口的注解中加上fallback的指定类就行了:

@FeignClient(value = "service-hi",fallback = SchedualServiceHiHystric.class)
public interface SchedualServiceHi {
    @RequestMapping(value = "/hi",method = RequestMethod.GET)
    String sayHiFromClientOne(@RequestParam(value = "name") String name);
}

SchedualServiceHiHystric类:

@Component
public class SchedualServiceHiHystric implements SchedualServiceHi {
    @Override
    public String sayHiFromClientOne(String name) {
        return "sorry "+name;
    }
}

果使用feign不想用断路器的话,可以在配置文件中关闭它,配置如下:

feign.hystrix.enabled=false

第三步:

一些通用配置:

参考官网:https://github.com/Netflix/Hystrix/wiki/Configuration

Maven示例:

https://github.com/easonjim/spring-cloud-demo/tree/master/ZooKeeper

参考:

https://zhuanlan.zhihu.com/p/26426835(以上内容部分内容转自此篇文章)

http://blog.csdn.net/w_x_z_/article/details/53444199(以上内容部分内容转自此篇文章)

时间: 2024-10-06 11:32:44

spring-cloud-starter-hystrix(断路器)服务不通或者调用失败后的错误处理和回调的相关文章

【微服务架构】Spring Cloud之Hystrix(三)

一.雪崩效应 在微服务架构中,由于服务和服务之间可以互相调用,一项工作的完成可能会依赖调用多个微服务模块,但由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪:再加上服务和服务之间的依赖性,瘫痪会迅速传播,给整个微服务系统造成严重的后果,这就是服务故障的“血崩”效应. 服务雪崩效应形成的阶段 1.服务提供者不可用 硬件故障.硬件损坏导致服务器主机宕机,或网络硬件

《Spring Cloud与Docker微服务架构实战》配套代码

不才写了本使用Spring Cloud玩转微服务架构的书,书名是<Spring Cloud与Docker微服务架构实战> - 周立,已于2017-01-12交稿.不少朋友想先看看源码,现将代码放出. 本次放出的代码: 共计70+个DEMO 覆盖Eureka.Ribbon.Feign.Hystrix.Zuul.Spring Cloud Config.Spring Cloud Bus.Spring Cloud Sleuth.Docker.Docker Compose等. 1-11章代码地址: ht

Spring Cloud中Hystrix、Ribbon及Feign的熔断关系

在Spring Cloud中Hystrix.Ribbon以及Feign它们三者之间在处理微服务调用超时从而触发熔断降级的关系是什么? 我们知道在Spring Cloud微服务体系下,微服务之间的互相调用可以通过Feign进行声明式调用,在这个服务调用过程中Feign会通过Ribbon从服务注册中心获取目标微服务的服务器地址列表,之后在网络请求的过程中Ribbon就会将请求以负载均衡的方式打到微服务的不同实例上,从而实现Spring Cloud微服务架构中最为关键的功能即服务发现及客户端负载均衡调

笔记:Spring Cloud Feign Hystrix 配置

在 Spring Cloud Feign 中,除了引入了用户客户端负载均衡的 Spring Cloud Ribbon 之外,还引入了服务保护与容错的工具 Hystrix,默认情况下,Spring Cloud Feign 会为将所有 Feign客户端的方法都封装到 Hystrix 命令中进行服务保护,需要注意的是 Ribbon 的超时与 Hystrix 的超时是二个概念,需要让 Hystrix 的超时时间大于 Ribbon 的超时时间,否则 Hystrix 命令超时后,该命令直接熔断,重试机制就没

spring cloud (四、服务消费者demo_consumer)

spring cloud (一.服务注册demo_eureka) spring cloud (二.服务注册安全demo_eureka) spring cloud (三.服务提供者demo_provider) 写完这些案例的demo后面有时间再写这个框架的思想: 注册中心负责服务管理:提供者负责提供服务:消费者调用提供者的服务: 消费者的demo也是一样建一个spring boot 项目:然后修改pom文件如下: <?xml version="1.0" encoding="

SpringCloud(9)使用Spring Cloud OAuth2保护微服务系统

一.简介 OAth2是一个标准的授权协议. 在认证与授权的过程中,主要包含以下3种角色. 服务提供方 Authorization Server. 资源持有者 Resource Server. 客户端 Client. OAuth2的认证流程如图所示,具体如下. (1)用户(资源持有者)打开客户端 ,客户端询问用户授权. (2)用户同意授权. (3)客户端向授权服务器申请授权. (4)授权服务器对客户端进行认证,也包括用户信息的认证,认证成功后授权给予令牌. (5)客户端获取令牌后,携带令牌向资源服

spring cloud深入学习(三)-----服务消费

在上一篇博文中简单实现了eureka-server以及eureka-provider,后面会实现eureka-cosumer,现在针对eureka做进一步的详解. 微服务整体架构 文字再美也没有图片直观,下面通过一张图来说明微服务的整体架构以及调用过程,如下: 服务注册中心-1和服务注册中心-2互相组成了高可用集群:服务提供者启动了两个实例,一个注册到服务注册中心-1上,另外一个注册到服务注册中心-2上:两个服务消费者,也都分别指向了一个注册中心. 服务提供者 1.服务注册 服务提供者在启动的时

用Spring Cloud OAuth2保护微服务系统

一.简介# OAth2是一个标准的授权协议. 在认证与授权的过程中,主要包含以下3种角色. 服务提供方 Authorization Server. 资源持有者 Resource Server. 客户端 Client. OAuth2的认证流程如图所示,具体如下. (1)用户(资源持有者)打开客户端 ,客户端询问用户授权. (2)用户同意授权. (3)客户端向授权服务器申请授权. (4)授权服务器对客户端进行认证,也包括用户信息的认证,认证成功后授权给予令牌. (5)客户端获取令牌后,携带令牌向资源

spring cloud(一):微服务架构开篇

在公司使用spring cloud快一年了,项目也上线了,同时在线用户到达有几十万,公司之前用的是传统项目部署,业务放在一起,导致系统庞大,难以维护;采用spring cloud之后,一个业务对应一个独立的模块,也就是我们所说的微服务,开发人员维护起来就没那么困难,同时系统启动较快,下面就讲解下项目用到的技术框架: Spring Cloud是一系列框架的有序集合.它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册.配置中心.消息总线.负载均衡.断路器.数