SpringCloud笔记——Hystrix断路器

最新推荐文章于 2023-03-21 16:02:34 发布
最新推荐文章于 2023-03-21 16:02:34 发布
阅读量242 收藏
点赞数
分类专栏： SpringCloud 文章标签： spring cloud 微服务 Hystrix spring boot 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_43240702/article/details/109418212
版权

文章目录

概述

分布式系统面临的问题

复杂的分布式体系结构中应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败

在这里插入图片描述

服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的扇出，如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的雪崩效应

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其它系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败不能取消整个应用程序或系统

所以，通常当你发现一个模块下的某个实例失败以后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩

Hystrix是什么

Hystrix是一个用户处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免地会调用失败，比如超时、异常等。Hystrix能够保证在一个依赖出问题的情况下，不会导致整体的服务失败，避免级联故障，提高分布式系统的弹性

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的可处理的备选响应（FallBack），而不是长期等待或者抛出调用方无法处理的异常，这样就保证了服务调用放方的线程不会被长时间不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩

Hystrix能干嘛？

  • 服务降级
  • 服务熔断
  • 接近实时的监控
  • …

官网资料

https://github.com/Netflix/Hystrix/wiki/How-To-Use

Hystrix停更进维

在这里插入图片描述

官方推荐替代品：resilience4j 或者 sentinel

Hystrix重要概念

服务降级（FallBack）

服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好提示

哪些情况下会发生服务降级？

  • 程序运行异常
  • 执行开始，但没有在允许的时间内完成
  • 服务熔断触发服务降级（ 断路器打开，不尝试执行）
  • 线程池拒绝，不尝试执行
  • 信号量拒绝，不尝试执行

服务熔断（Break）

类比保险丝达到最大服务访问后，直接拒绝访问，拉闸停电，然后调用服务降级的方法并返回友好提示

就是保险丝 —— 服务的降级 -> 进而熔断 -> 恢复调用链路

服务限流（FlowLimit）

秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行

Hystrix案例

构建

//新建PaymentServiceImpl
@Service
public class PaymentServiceImpl implements PaymentService {

    @Override
    public String paymentInfo_OK(Integer id) {
        return "线程池:" + Thread.currentThread().getName() + "paymentInfo_OK - ID:" + id;
    }

    @Override
    public String paymentInfo_TimeOut(Integer id) {
        try {
            TimeUnit.SECONDS.sleep(3);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "线程池:" + Thread.currentThread().getName() + "paymentInfo_TimeOut - ID:" + id + "耗时3秒";
    }
}

//新建PaymentController
@RestController
public class PaymentController {

    @Resource
    private PaymentService paymentService;

    @Value("$(server.port)")
    private String serverPort;

    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id){
        return paymentService.paymentInfo_OK(id);
    }

    @GetMapping("/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id){
        return paymentService.paymentInfo_TimeOut(id);
    }

}

Yaml文件配置

server:
  port: 8001

spring:
  application:
    name: cloud-provider-hystrix-payment
    
eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka/

访问http://localhost:8001/payment/hystrix/ok/11 可以正常访问，立即成功

访问http://localhost:8001/payment/hystrix/timeout/11 延迟三秒后访问成功

上述情况下在非高并发场景下还能满足，但是。。。

高并发测试

JMeter测试

开启JMeter，来2W并发压死8001，两万请求都去访问/payment/hystrix/timeout/11

在这里插入图片描述

再来访问一下http://localhost:8001/payment/hystrix/ok/11 发现这个也在转圈圈

为什么会被卡死呢？是因为tomcat的默认的工作线程数被打满了，没有多余的线程来分解压力和处理

JMeter压力测试结论

上面还是服务提供者8001自己测试，假如此时的外部消费者80也来访问，那消费者只能干等，最终导致消费者端80不满意，服务端8001直接被拖死

新建model消费者80加入

采用OpenFeign进行服务调用

//Service
@FeignClient("CLOUD-PROVIDER-HYSTRIX-PAYMENT")
public interface PaymentHystrixService {
    @GetMapping("/payment/hystrix/ok/{id}")
    String paymentInfo_OK(@PathVariable("id") Integer id);

    @GetMapping("/payment/hystrix/timeout/{id}")
    String paymentInfo_TimeOut(@PathVariable("id") Integer id);
}

//Controller 
@RestController
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id) {
        return paymentHystrixService.paymentInfo_OK(id);
    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        return paymentHystrixService.paymentInfo_TimeOut(id);
    }
}
高并发测试

再次使用JMeter开启2W线程压服务提供者8001，然后消费端微服务80再去访问正常的OK微服务8001地址

http://localhost/consumer/payment/hystrix/ok/1

发现消费者端要么转圈圈等待时间长，要么报超时错误

故障现象和导致原因

8001同一层次的其它接口服务被困死，因为tomcat线程池里面的工作线程已经被挤占完毕

80此时调用8001，客户端访问响应变慢，导致转圈圈

结论：正因为有上述故障或表现不佳，才有我们的降级/容错/限流等技术产生

如何解决？解决的需求？

超时导致服务器变慢（转圈） —> 超时不再等待

出错（宕机或程序运行出错） —> 出错要有兜底

解决方案

  • 对方服务（8001）超时了，调用者（80）不能一直卡死等待，必须有服务降级
  • 对方服务（8001）宕机了，调用者（80）不能一直卡死等待，必须有服务降级
  • 对方服务（8001）OK，调用者（80）自己出故障或需求（自己等待时间 < 服务提供者），自己处理降级

服务降级

降级配置：@HystrixCommand

8001自身找问题

设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方案，做服务降级FallBack

8001FallBack
@Service
public class PaymentServiceImpl implements PaymentService {

    @Override
    public String paymentInfo_OK(Integer id) {
        return "线程池:" + Thread.currentThread().getName() + "paymentInfo_OK - ID:" + id;
    }

    @Override
    @HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3000")
    })
    public String paymentInfo_TimeOut(Integer id) {
        int a = 10 / 0;
        try {
            TimeUnit.SECONDS.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "线程池:" + Thread.currentThread().getName() + "paymentInfo_TimeOut - ID:" + id + "耗时3秒";
    }
    
	//处理时发现线程为Hystrix的线程
    public String paymentInfo_TimeOutHandler(Integer id) {
        return "线程池:" + Thread.currentThread().getName() + "paymentInfo_TimeOutHandler - ID:" + id + "/(ㄒoㄒ)/~~";
    }
}

一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的兜底方法来进行处理

我们在代码中分别制造两个异常

  • int a = 10/0 计算异常
  • 我们能接受三秒钟，它运行五秒，超时异常

当前服务不可用了，做服务降级，兜底的方案都是paymentInfo_TimeOutHandler

主启动类激活：添加新的注解@EnableCircuitBreaker

80FallBack

80订单微服务，也可以更好地保护自己，自己也照葫芦画瓢进行客户端降级保护

主启动类：@EnableHystrix

注：@EnableHystrix其实就是继承了@EnableCircuitBreaker

@EnableCircuitBreaker
public @interface EnableHystrix {
}

ribbon:										#设置Ribbon超时时间5s
  ReadTimeout: 5000 		  #指的是建立连接后从服务器读取到可用资源的时间
  ConnectTimeout: 5000	  #指的是建立连接所用的时间，适用于网络状态正常的情况下，两端连接所用的时间

80消费者

@RestController
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id) {
        return paymentHystrixService.paymentInfo_OK(id);
    }

    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
    @HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1500")
    })
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        return paymentHystrixService.paymentInfo_TimeOut(id);
    }

    public String paymentInfo_TimeOutHandler(Integer id) {
        return "消费者80,忙死了/(ㄒoㄒ)/~~";
    }
}

消费者80这里的超时时间设置为1.5秒，服务提供者8001可以通过（8001端设置允许5秒但是耗时3秒），但消费者80只等待1.5秒就转去执行兜底方案

目前问题
  • 每一个业务方法对应一个兜底的方法，代码膨胀
  • 业务逻辑方法和处理异常服务降级的方法混在一块，耦合度高
解决问题

每个方法配置一个？？？膨胀

@DefaultProperties：标注在类上，表示没有配过fallbackMethod的就找这个default全局通用的，配置过的就找自己配置的精确打击的

@DefaultProperties(defaultFallBack = “”)

1：1 每个方法配置一个服务降级方法，技术上可以，实际上很傻

1：N除了个别重要的任务有专属兜底方案，其他普通的都可以通过它统一跳转到统一处理结果页面

通用的和独享的各自分开，避免了代码膨胀，合理的减少了代码量

@RestController
@DefaultProperties(defaultFallback = "paymentGlobalFallbackMethod")
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    public String paymentInfo_OK(@PathVariable("id") Integer id) {
        return paymentHystrixService.paymentInfo_OK(id);
    }


    @GetMapping("/consumer/payment/hystrix/timeout/{id}")
//    @HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler",commandProperties = {
//            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1500")
//    })
    @HystrixCommand
    public String paymentInfo_TimeOut(@PathVariable("id") Integer id) {
        return paymentHystrixService.paymentInfo_TimeOut(id);
    }

    public String paymentInfo_TimeOutHandler() {
        return "消费者80,忙死了/(ㄒoㄒ)/~~";
    }

    public String paymentGlobalFallbackMethod() {
        return "全局异常处理信息，请稍后再试";
    }
}

和业务逻辑混在一起？？？混乱

服务降级，客户端去调用服务器端，遇到服务端宕机或关闭

修改客户端消费者80的程序，新建PaymentFallbackService实现Feign客户端接口

@Component
public class PaymentFallbackService implements PaymentHystrixService {
    @Override
    public String paymentInfo_OK(Integer id) {
        return "---PaymentFallbackService: paymentInfo_OK fallback ";
    }

    @Override
    public String paymentInfo_TimeOut(Integer id) {
        return "---PaymentFallbackService: paymentInfo_TimeOut fallback ";
    }
}

并在Feign客户端注解上新加一个fallback属性，指出用来兜底的服务降级类

@FeignClient(value = “CLOUD-PROVIDER-HYSTRIX-PAYMENT”,fallback = PaymentFallbackService.class)

最后在application.yml中开启Feign对于Hystrix支持，OpenFeign客户端将被Hystrix断路器包裹

feign:
  hystrix:
    enabled: true

关闭服务端8001，访问测试http://localhost/consumer/payment/hystrix/ok/22，发现此时的服务端8001虽然已经down了，但是我们做了服务降级处理，让客户端80在服务端不可用的情况下也会获得提示信息而不会挂起耗死服务器

服务熔断

熔断是什么？

熔断机制概述

熔断机制是应对雪崩效应的一种微服务链路保护机制，当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该结点微服务的调用，快速返回错误的响应信息

当检测到该节点微服务调用响应正常时，恢复调用链路

在Spring Cloud框架里，熔断机制通过Hystrix实现，Hystrix会监控微服务间的调用情况

当失败的调用到了一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制，熔断机制的注解是@HystrixCommand

附上martinfowler大神论文https://martinfowler.com/bliki/CircuitBreaker.html

理解

  1. 调用失败会出发降级，而降级会调用fallback方法
  2. 但无论如何降级，流程一定是先调用正常方法再调用fallback方法
  3. 假如单位时间内调用失败次数过多，也就是降级次数过多，则会触发熔断
  4. 熔断以后就会跳过正常方法直接调用fallback方法
  5. 所谓 “ 熔断服务不可用 ” 就是因为跳过了正常方法直接执行fallback

在这里插入图片描述

当失败的次数（降级次数）过多时，即达到了阈值满足了上图中threshold reached条件，触发服务熔断，断路器打开，假设我只能承受100的并发量每秒钟，而现在给我干到了500，所以我死掉了（跳闸），而其中存在第三种状态-半开-表示我已准备好进行再次试验，以查看问题是否已解决。比如过了一会没有那么多并发量了，我觉得我现在慢慢的能够承接的住了，比如现在每秒钟70的并发，我的上限还是100，那么我可以试试放过去一个试试能不能成功，慢慢的放着放着发现能够适应了，就把闸道合上，这就是从半开Half Open到Closed的过程

实操

修改支付微服务提供者8001的service与controller

//service新加两个测试方法
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",commandProperties = {
    	@HystrixProperty(name = "circuitBreaker.enabled",value = "true"),  //是否开启断路器
    	@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),   //熔断触发的最少个数/10s内
    	@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"),  //熔断多少秒后去尝试请求
    	@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"), //失败率达到多少后熔断
})
public String paymentCircuitBreaker(Integer id){
    if (id < 0){
        throw new RuntimeException("*****id 不能负数");
    }
    String serialNumber = UUID.randomUUID().toString();

    return Thread.currentThread().getName()+"\t"+"调用成功,流水号："+serialNumber;
}
public String paymentCircuitBreaker_fallback(Integer id){
    return "id 不能负数，请稍候再试,(┬＿┬)/~~     id: " +id;
}
 

//controller
@GetMapping("/payment/circuit/{id}")
public String paymentCircuitBreaker(@PathVariable("id") Integer id){
    return paymentService.paymentCircuitBreaker(id);
}

熔断打开和闭合的精确方式如下：

  1. 假设电路上的音量达到某个阈值（HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()）
  2. 并假设误差百分比超过阈值误差百分比（HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()）
  3. 然后，断路器从转换CLOSED为OPEN
  4. 当它断开时，它会使针对该断路器的所有请求短路
  5. 经过一段时间（HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()）后，下一个单个请求被允许通过（这是HALF-OPEN状态）。如果请求失败，则断路器将OPEN在睡眠窗口持续时间内返回到该状态。如果请求成功，断路器将切换到，CLOSED并且1中的逻辑将再次接管

测试：测试http://localhost:8001/payment/circuit/-1，多次错误以后，慢慢正确，会发现刚开始的正确不满足条件，就算正确的访问地址也直接走降级，需要慢慢的恢复链路

总结

熔断类型

  • 熔断关闭：熔断关闭不会对服务进行熔断

  • 熔断打开：请求不再进行调用当前服务，当打开时常到所设时常则进入半熔断状态

  • 熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为服务恢复正常，关闭熔断

断路器开启或关闭的条件

  • 当满足一定阈值的时候（默认10秒内超过20的请求次数）
  • 当失败率达到一定的时候（默认10秒内超过50%的请求失败）
  • 到达以上阈值，断路器将会开启
  • 当开启的时候，所有的请求都直接降级
  • 一段时间以后（默认5S），断路器为半开状态，会让其中一个请求尝试，成功则断路器关闭，失败继续重复

断路器打开之后

  • 再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallback。通过断路器，实现自动地发现错误并将逻辑切换，减少响应延迟的效果

  • 当断路器打开，对主逻辑进行熔断以后，Hystrix会启动一个休眠时间窗，在时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此时请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间闯关重新计时

在这里插入图片描述

服务熔断一般放在服务端，而服务降级一般放在消费端

服务限流

为什么需要限流

  • 复杂分布式系统通常有很多依赖，如果一个应用不能对来自依赖故障进行隔离，那么应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，将会在数秒内导致 所有应用资源被耗尽
  • 如秒杀、抢购、双十一等场景，在某一时间点会有爆发式的网络流量涌入，如果没有好的网络流量限制，任由流量压到后台服务实例，很有可能造成资源耗尽，服务无法响应，甚至严重的导致应用崩溃

以后在学习Alibaba的sentinel的时候在做说明

服务监控HystrixDashboard

概述

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续的记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展现给用户，包括每秒执行多少请求，多少成功多少失败Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了HystrixDashboard的整合，对监控内容转化为可视化界面

仪表盘9001

新建9001监控项目引入依赖

    <dependencies>
        <!--新增hystrix dashboard-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
        </dependency>
        <!--注意所有的Provider微服务提供者（8001，8002 ...）都需要依赖监控配置-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

YML

server:
  port: 9001

主启动类新增**@EnableHystrixDashboard**

@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboard9001 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixDashboard9001.class,args);
    }
}

启动项目访问 http://localhost:9001/hystrix

断路器演示

修改8001

    /**
     * 此配置是为了服务监控而配置，SpringCloud升级以后的坑
     * ServletRegistrationBean因为springboot的默认路径不是 /hystrix.stream
     * 只要在自己项目里配置下面的servlet就可以了
     * @return
     */
    @Bean
    public ServletRegistrationBean<Servlet> getServlet(){
        HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
        ServletRegistrationBean<Servlet> registrationBean = new ServletRegistrationBean<Servlet>(streamServlet);
        registrationBean.setLoadOnStartup(1);
        registrationBean.addUrlMappings("/hystrix.stream");
        registrationBean.setName("HystrixMetricsStreamServlet");
        return registrationBean;
    }

启动一个7001Eureka服务端注册中心，再启动我们的8001与9001

在这里插入图片描述

测试地址：

http://localhost:8001/payment/circuit/7

http://localhost:8001/payment/circuit/-7

会看到我们的监控页面发生动态响应，是否触发熔断等

先访问正确地址，再访问错误地址，再访问正确地址，会发现图示的断路器都是慢慢放开的

在这里插入图片描述

如何看？

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

大恐龙的小弟
关注
专栏目录
SpringCloud十七、服务降级。
lbh19630726的博客
02-07 268
①服务降级。 什么是服务降级： 整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。 服务降级处理是在客户端（服务消费者、服务调用方）实现完成的，与服务端（服务提供者）没有关系。 服务熔断的坏处：容易方法膨胀。增加一个方法，就要增加一个fallbackMethod方法。而且出现高耦合现象。这时，我们需要解耦： microservicecloud-prov...
SpringCloud学习笔记(六) Hystrix断路器
冰可乐味儿的深哥哥、
12-11 179
概述；服务熔断；服务降级；服务监控HystrixDashboard；
SpringCloud2020学习笔记09——Hystrix断路器
Radish萝卜的博客
07-26 1996
目录一、概述1、分布式系统面临的问题2、Hystrix简介3、作用① 服务降级② 服务熔断③ 接近实时的监控4、官方资料5、Hystrix官宣，停更进维二、Hystrix重要概念1、服务降级2、服务熔断3、服务限流三、Hystrix案例1、构建① 新建cloud-provider-hystrix-payment8001② POM③ YML④ 主启动类⑤ 业务类2、高并发测试① Jmeter压测测试② Jmeter压测结论③ 80新建加入① 新建cloud-consumer-feign-hystrix-ord
SpringCloud笔记(Dalston)——Netflix之Hystrix断路器
想混口饭&的博客
03-21 449
断路器Hystrix使用
Spring Cloud 学习笔记之——07 Hystrix断路器
qq_38777021的博客
01-22 387
SpringCloud 之 Hystrix 豪猪
SpringCloud笔记——Hystrix+Hystrix DashBoard
liuxing5457的博客
04-15 304
hystrix（断路器）ribbon+restTemplate方式 ​ 在分布式系统中，根据业务来拆分成一个个的微服务，服务与服务之间可以相互调用（RPC），在spring cloud 中可以用RestTemplate+ribbon和feign来调用。为了保证其高可用，单个服务有时候会集群部署，由于网络或程序自躾 的原因，服务并不能保证百分百可靠可用，如果单个服务出现问题，调用这个服务就出现线程阻...
SpringCloud-Netflix学习笔记10——Hystrix实现服务熔断
爱吃雪糕的小布丁的博客
02-09 762
复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败！Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
Spring Cloud 学习笔记 —— Hystrix 介绍 和简单使用（注解模式）
XiaoMing学习分享博文
09-22 321
讲解 1.基本介绍 2.简单使用/容错/服务降级 3.请求命令 4.异常处理 5.请求缓存 6.请求合并 8.1 基本介绍 Hystrix 叫做断路器/熔断器。在微服务中，整个系统出错的概率非常高，因为在微服务项目中，涉及的模块太多了，每个模块出错，都有可能导致整个服务出错，当所有模块都稳定运行时，整个服务才算是稳定运行。 0.999^100 = 0.99 即 99% 情况都运行正常 0.999^1000 = 0.37 即只有 37% 的情况运行正常 我们希望当系统中某个模块不能正常工作时，能够通过我们
springcloud学习笔记——Hystrix学习
sam的博客
04-28 176
概述 分布式系统面临的问题 在复杂分布式体系结构中的应用程序中 ，服务与服务之间往往会有许多依赖，多个微服务至今调用时，假设A调用B，B调用C。若B出现了故障（响应时间长、不可用），如果对于高流量的引用来说，堆积在A上的请求将会越来越多，最终导致服务器资源饱和，增加系统延时风险。 Hystrix Hystrix的出现就是解决服务之间依赖的问题，当一个出现问题时，Hystrix会提供一种备用方法返...
SpringCloud笔记-images
最新发布
05-23
描述中的"SpringCloud笔记——images"进一步确认了这是一个以图片为主的Spring Cloud教程，可能包含了一些截图、流程图或架构图，以直观地展示Spring Cloud如何在实际项目中运作。 在"Springcloud笔记.assets"和...
SpringCloud入门——（一）目录篇
qq_31941773的博客
09-02 698
目前是微服务的天下，我们来搭建自己的微服务系统从而学习及应用。 Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以...
SpringCloud学习笔记——声明式服务调用Feign
负重前行
03-11 210
Feign简介 在前面我们已经搭建了Spring Cloud中的Ribbon和Hytrix，从而实现了微服务架构中客户端的负载均衡以及断路器机制保护服务，这两者的使用非常广泛并且经常一起出现，SpringCloud Feign其实就是一个整合工具，对两者进行了整合，除了原有的功能外，还提供了声明式的Web服务客户端定义方式。 快速搭建 新创建一个springboot项目feign-consume...
Springcloud_alibaba学习笔记
三明治文鱼的博客
04-21 2826
文章目录0. 简介区别特点组件1. 环境搭建2. Nacosa.作为服务注册中心启动Nacos Client简单上手服务间通信（和之前一样）应用搭建Controller具体实现RestTemplate+Ribbon：OpenFeignb.作为统一配置中心Config Client简单上手ControllerNacos中创建配置Nacos config自动刷新细节1、配置集(Data ID)2、配置分组(Group)3、命名空间(Namespace)4、最佳实践c.配置持久化d. 高可用（集群）nacos高可
RabbitMQ详细笔记（包含spring整合与集群搭建）
qq_43240702的博客
11-11 1792
文章目录MQ引言1、什么是MQ2、MQ有哪些3、不同MQ特点RabbitMQ引言1、RabbitMQ的架构与基础概念2、RabbitMQ生产消费消息流程3、RabbitMQ的安装RabbitMQ配置1、RabbitMQ管理命令行2、web管理界面介绍RabbitMQ的消息模型开发1、AMQP协议的回顾2、RabbitMQ支持的消息模型3、引入依赖4、第一种模型（Hello World）开发生产者开发消费者封装连接工具类5、第二种模型（Work Queue）开发生产者开发消费者测试结果消息自动确认机制6、第三
SpringCloud笔记——Gateway服务网关
qq_43240702的博客
11-03 1785
@OC 概述简介 官网 上一代Netflix的Zuul 1.X：https://github.com/Netflix/zuul/wiki/ Gateway：https://docs.spring.io/spring-cloud-gateway/docs/2.2.5.RELEASE/reference/html/ 是什么？ Spring Cloud全家桶中有一个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关 但在2.x版本中，Zuul的升级一直跳票，Spring Cloud最后自己研发了一个网关
SpringCloudAlibaba笔记——Sentinel实现熔断与限流
qq_43240702的博客
12-02 354
文章目录Sentinel概述1、官网2、Sentinel是什么？3、Sentinel去哪下？3、Sentinel能干嘛？4、Sentinel怎么玩？安装Sentinel控制台1、Sentinel两部分组件2、安装步骤初始化演示工程1、Nacos启动成功2、工程3、测试流控规则1、基本介绍2、流控模式2.1、直接（默认）2.2、关联2.3、链路3、流控效果3.1、快速失败3.2、预热（Warm Up）3.3、排队等待降级规则1、概述2、熔断策略3、熔断降级规则说明热点key限流1、基本介绍1.1、热点key限
SpringCloud笔记——Eureka服务注册与发现
qq_43240702的博客
10-26 322
什么是Eureka 概述 Eureka是 Netflix（网飞） 的一个子模块，也是核心模块之一，Eureka是一个基于 REST（Representational State Transfer）的服务。服务注册与发现对于微服务架构来说是非常重要的，有了服务发现和注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务，而不需要修改服务调用的配置文件了，功能类似于dubbo的注册中心，比如zookeeper SpringCloud封装了 Netflix 公司开发的 Eureka 模块来实现服务注册时
Springcloud笔记——Bus消息总线
qq_43240702的博客
11-11 302
概述 根据Spring Cloud Config配置中心，当我们更改了GitHub上面的配置文件后，若想要获取到最新的配置，需要手动刷新或者利用webhook的机制每次提交代码发送请求来刷新客户端，客户端越来越多的时候，需要每个客户端都执行一遍，这种方案很不好。使用Spring Cloud Bus（消息总线）可以解决这一问题 1、Bus是什么？ Spring Cloud Bus 配合 Spring Cloud Config 使用可以实现配置的自动刷新 Spring Cloud Bus是用来将分布式系统的
SpringCloud微服务保障：Hystrix断路器策略详解
在SpringCloud的微服务架构中，第五篇内容主要聚焦于如何利用Hystrix熔断器来确保服务之间的稳健性和容错性。Hystrix是一个由Netflix API团队开发的延迟和容错库，旨在应对分布式系统中服务之间的依赖性问题，特别是...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

大恐龙的小弟

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值