网关中加入熔断机制(Hystrix)

网关中加入熔断机制

在网关中加入熔断机制

添加依赖项

spring-cloud-gateway项目POM文件加入spring-cloud-starter-netflix-hystrix

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

修改配置文件

修改application.yml配置文件

server:
 port: 9000
spring:
  cloud:
    consul:
      host: 127.0.0.1
      port: 8500
      discovery:
        register: true
    gateway:
      routes:
        - id: test_route
          uri: lb://service-provider
          predicates:
            - Path=/service-provider/{segment}
          filters:
            - SetPath=/{segment}
            - name: Hystrix
              args:
                name: service-provider-fallback
                fallbackUri: forward:/service-provider-error
            - name: Retry
              args:
                retries: 3
                statuses: BAD_GATEWAY,BAD_REQUEST
      default-filters:
        - name: Hystrix
          args:
            name: fallbackcmd
            fallbackUri: forward:/default-error
  application:
    name: PC-ApiGateWay

在默认过滤器中加入熔断机制

default-filters:
        - name: Hystrix
          args:
            name: fallbackcmd
            fallbackUri: forward:/default-error

gateway下的default-filters代表默认过滤器,Hystrix是熔断机制的实现,fallbackcmd是HystrixCommand对象的名字(name属性),fallbackUri表示触发熔断机制后的跳转请求url,/default-error是在spring-cloud-gateway项目中实现的错误信息统一处理Controller:

@RestController
public class ErrorHandle {

    @RequestMapping("/default-error")
    public String DefaultErrorHandle(){
        return "这是通用错误处理返回的信息。";
    }
}

自定义单条路由的熔断机制处理内容

gateway:
      routes:
        - id: test_route
          uri: lb://service-provider
          predicates:
            - Path=/service-provider/{segment}
          filters:
            - SetPath=/{segment}
            - name: Hystrix
              args:
                name: service-provider-fallback
                fallbackUri: forward:/service-provider-error

内容和上面介绍相同,同样需要spring-cloud-gateway项目实现service-provider-error处理过程。

@RestController
public class ErrorHandle {

    @RequestMapping("/default-error")
    public String DefaultErrorHandle(){
        return "这是通用错误处理返回的信息。";
    }

    @RequestMapping("/service-provider-error")
    public String ServiceProviderErrorHandle(){
        return "这是ServiceProvider服务专属的错误处理信息。";
    }
}

自动重试机制

gateway:
      routes:
        - id: test_route
          uri: lb://service-provider
          predicates:
            - Path=/service-provider/{segment}
          filters:
            - SetPath=/{segment}
            - name: Hystrix
              args:
                name: service-provider-fallback
                fallbackUri: forward:/service-provider-error
            - name: Retry
              args:
                retries: 3
                statuses: BAD_GATEWAY,BAD_REQUEST

在gateway的filters下声明name为Retry的过滤器,retries重试次数,statuses返回HTTP状态码为何值时重试(还有methods和series参数),请参考org.springframework.http.HttpStatus、org.springframework.http.HttpMethod和org.springframework.http.HttpStatus.Series。

启动项目测试

启动 Consul服务中心和spring-cloud-provider微服务,最后启动spring-cloud-gateway项目,正常情况下:

关闭spring-cloud-provider微服务进程之后再次刷新页面:

源码

Github仓库:https://github.com/sunweisheng/spring-cloud-example

原文地址:https://www.cnblogs.com/bluersw/p/11610709.html

时间: 2024-10-10 20:38:38

网关中加入熔断机制(Hystrix)的相关文章

熔断机制hystrix

一.问题产生 雪崩效应:是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程 正常情况下的服务: 某一服务出现异常,拖垮整个服务链路,消耗整个线程队列,造成服务不可用,资源耗尽: 形成过程: 1)服务提供者不可用 a)硬件故障:硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问 b)程序Bug: c)   缓存击穿:缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运

利用Spring Cloud实现微服务- 熔断机制

1. 熔断机制介绍 在介绍熔断机制之前,我们需要了解微服务的雪崩效应.在微服务架构中,微服务是完成一个单一的业务功能,这样做的好处是可以做到解耦,每个微服务可以独立演进.但是,一个应用可能会有多个微服务组成,微服务之间的数据交互通过远程过程调用完成.这就带来一个问题,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的"扇出".如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的&

springcloud熔断机制

最近项目用到springcloud,研究了下springcloud的熔断机制Hystrix. 熔断机制,就是下游服务出现问题后,为保证整个系统正常运行下去,而提供一种降级服务的机制,通过返回缓存数据或者既定数据,避免出现系统整体雪崩效应.在springcloud中,该功能可通过配置的方式加入到项目中. 理论上需要进行分布式调用的服务都应该加上,在项目中,可根据实际项目需要进行添加. Maven项目中提供远程调用Feign中已经依赖了Hystrix,所以在项目的pom配置上不用做任何改动. 实现步

spring cloud 2.x版本 Ribbon服务发现教程(内含集成Hystrix熔断机制)

本文采用Spring cloud本文为2.1.8RELEASE,version=Greenwich.SR3 前言 本文基于前两篇文章eureka-server和eureka-client的实现. 参考 eureka-server eureka-client 1 Ribbon工程搭建 1.1 创建spring boot工程:eureka-ribbon 1.2 pom.xml所需要依赖的jar包 <dependency> <groupId>org.springframework.clo

SpringCloud系列七:Hystrix 熔断机制(Hystrix基本配置、服务降级、HystrixDashboard服务监控、Turbine聚合监控)

1.概念:Hystrix 熔断机制 2.具体内容 所谓的熔断机制和日常生活中见到电路保险丝是非常相似的,当出现了问题之后,保险丝会自动烧断,以保护我们的电器, 那么如果换到了程序之中呢? 当现在服务的提供方出现了问题之后整个的程序将出现错误的信息显示,而这个时候如果不想出现这样的错误信息,而希望替换为一个错误时的内容. 一个服务挂了后续的服务跟着不能用了,这就是雪崩效应 对于熔断技术的实现需要考虑以下几种情况: · 出现错误之后可以 fallback 错误的处理信息: · 如果要结合 Feign

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

容错机制和熔断(Hystrix)

雪崩效应 在微服务架构中,由于服务众多,通常会涉及多个服务层级的调用,而一旦基础服务发生故障,很可能会导致级联故障,进而造成整个系统不可用,这种现象被称为服务雪崩效应.服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将这种不可用逐渐放大的过程. 比如在一个系统中, A作为服务提供者,B是A的服务消费者,C和D又是B的服务消费者.如果此时A发生故障,则会引起B的不可用,而B的不可用又将导致C和D的不可用,当这种不可用像滚雪球一样逐渐放大的时候,雪崩效应就形成了. 熔断器(C

SpringCloud微服务的熔断机制以及相关概念介绍

1.什么是服务的熔断机制? 熔断机制是对系统的防护,比如受到一些恶意攻击,那么需要熔断机制来保护系统的微服务,做出响应,避免资源被耗尽.既要能响应,又要能防护,当我们的请求达到一个负载阈值,就启用熔断,把真实接口关掉,给客户端请求一个响应,这个响应,我们可以设置.服务熔断就是对该服务的调用执行熔断,对应后续请求,不在继续调用该目标服务,而是直接返回,从而可以快速释放资源,或者服务出现故障,会把故障信息返回给客户端 服务熔断的几种方式: 断路器,这是一个硬件设施,比如保险丝或者电子设备等等 断路器

(四)java springcloud b2b2c shop 多用户商城系统:熔断监控Hystrix Dashboard和Turbine:熔断器Hystrix

说起springcloud熔断让我想起了去年股市中的熔断,多次痛的领悟,随意实施的熔断对整个系统的影响是灾难性的,好了接下来我们还是说正事. 熔断器 雪崩效应 在微服务架构中通常会有多个服务层调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,这种现象被称为服务雪崩效应.服务雪崩效应是一种因"服务提供者"的不可用导致"服务消费者"的不可用,并将不可用逐渐放大的过程. 如果下图所示:A作为服务提供者,B为A的服务消费者,C和D是B的服务消费者.A不可