hystrix

一、微服务架构 1、微服务架构简介 　　1.1、分布式：不同的功能模块部署在不同的服务器上，减轻网站高并发带来的压力。 　　1.2、集群：多台服务器上部署相同应用构成一个集群，通过负载均衡共同向外提供服务。 　　1.3、微服务：微服务架构模式就是将web应用拆分为一系列小的服务模块，这些模块可以独立地编译、部署，并通过各自暴露的API接口通讯，共同组成一个web应用。 　　1.4、SpringCloud是基于SpringBoot的一整套微服务框架，提供了一系列可配置的组件，如 配置管理 、 服务发现 、 负载均衡 、 熔断器 、 断路器 、 智能路由 、 微代理 、 控制总线 、 全局锁 、 决策竞选 、 分布式会话 和 集群状态管理 等。 2、微服务的特点 单一职责：每一个服务模块都对应单一的业务实现 微：服务拆分的颗粒度很小 面向服务：每个服务对外仅暴露服务接口API即可，不关心服务的技术实现，与技术、语言和平台无关 自治：服务间互相独立、互不干扰 团队独立 技术独立：提供Rest接口，面向服务即可 前后端分离 数据库分离：每个服务使用自己的数据源 部署独立：每个服务都是独立的组件，可复用，可替换，降低服务间的耦合 3、三者的关系 微服务是一种结构理念，设计原则，提供理论指导； Spring Boot专注于快速、方便集成的单个微服务个体，可以基于Spring

今天和大家聊一聊在Spring Cloud微服务框架实践中，比较核心但是又很容易把人搞得稀里糊涂的一个问题，那就是在Spring Cloud中Hystrix、Ribbon以及Feign它们三者之间在处理微服务调用超时从而触发熔断降级的关系是什么？ 我们知道在Spring Cloud微服务体系下，微服务之间的互相调用可以通过Feign进行声明式调用，在这个服务调用过程中Feign会通过Ribbon从服务注册中心获取目标微服务的服务器地址列表，之后在网络请求的过程中Ribbon就会将请求以负载均衡的方式打到微服务的不同实例上，从而实现Spring Cloud微服务架构中最为关键的功能即服务发现及客户端负载均衡调用。 另一方面微服务在互相调用的过程中，为了防止某个微服务的故障消耗掉整个系统所有微服务的连接资源，所以在实施微服务调用的过程中我们会要求在调用方实施针对被调用微服务的熔断逻辑。而要实现这个逻辑场景在Spring Cloud微服务框架下我们是通过Hystrix这个框架来实现的。 调用方会针对被调用微服务设置调用超时时间，一旦超时就会进入熔断逻辑，而这个故障指标信息也会返回给Hystrix组件，Hystrix组件会根据熔断情况判断被调微服务的故障情况从而打开熔断器，之后所有针对该微服务的请求就会直接进入熔断逻辑，直到被调微服务故障恢复，Hystrix断路器关闭为止。 Hystrix

什么是服务雪崩? 参考: <<重新定义spring cloud>> 代码: https://gitee.com/08081/hello-springcloud/tree/springcloud-fallback/ 在微服务中,我们是服务于服务之间调用,当在微服务突然有大量的请求过来,一个服务瘫痪之后,后面的服务的请求积压,这就造成了服务雪崩! 一个服务瘫痪,另外调用这个服务的服务就会超时,导致整个服务群瘫痪. 造成雪崩的原因可以归结为以下三点: 1. 服务提供者不可用 (硬件故障,程序bug 缓存击穿,用户大量请求) 2. 重试加大流量 (用户重试,代码逻辑重试) 3. 服务调用者不可用 (同步等待造成的资源耗尽) 最终的结果就是一个服务不可用,导致一系列的服务不可用,这种后果无法预料 如何解决在灾难性雪崩效应? 1. 降级: 超时降级资源不足时(线程或信号量)降级,降级后可以配合降级接口返回托底数据,实现一个fallback方法,当请求出现异常之后,调用这个方法 2. 隔离(线程池隔离和信号量隔离) : 限制调用分布式服务的资源使用,某一个调用的服务出现问题不会影响其他服务调用 3. 熔断 : 当失败率(如因网络故障/超时造成的失败率高)达到阈值自动触发降级.熔断器触发的快速失败会进行快速恢复 4. 缓存: 提供请求缓存 5. 提供请求合并 1. 坑1 mapping 报错

一、hystrix在生产中的建议 1、保持timeout的默认值（1000ms），除非需要修改（其实通常会修改） 2、保持threadpool的的线程数为10个，除非需要更多 3、依赖标准的报警和监控系统来捕获问题 4、通过dashboards的实时监控来动态修改配置，直到满意为止 二、配置信息（default或 HystrixCommandKey ） 最常用的几项 超时时间（默认1000ms，单位：ms） hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 在调用方配置，被该调用方的所有方法的超时时间都是该值，优先级低于下边的指定配置 hystrix.command. HystrixCommandKey .execution.isolation.thread.timeoutInMilliseconds 在调用方配置，被该调用方的指定方法（ HystrixCommandKey方法名 ）的超时时间是该值 线程池核心线程数 hystrix.threadpool.default.coreSize（默认为10） Queue hystrix.threadpool.default.maxQueueSize（最大排队长度。默认-1，使用SynchronousQueue。其他值则使用

Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明，本系列教程全采用以上版本 上一篇我们聊了Gateway和注册中心的使用，以及 Gataway 中 Filter 的基本使用，这篇文章我们将继续介绍 Filter 的一些高级功能。 熔断 限流 重试 限速在高并发场景中比较常用的手段之一，可以有效的保障服务的整体稳定性，Spring Cloud Gateway 提供了基于 Redis 的限流方案。所以我们首先需要添加对应的依赖包spring-boot-starter-data-redis-reactive <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis-reactive</artifactId> </dependency> 配置文件中需要添加 Redis 地址和限流的相关配置 server: port: 8080 spring: application: name: spring-cloud-gateway redis: host: localhost password: password port: 6379 cloud: gateway: discovery:

在上两篇文章中讲了，服务提供者 Eureka + 服务消费者 Feign，服务提供者 Eureka + 服务消费者（rest + Ribbon），本篇文章结合，上两篇文章中代码进行修改加入 断路器监控(Hystrix Dashboard) 在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 针对上述问题，在Spring Cloud Hystrix中实现了线程隔离、断路器等一系列的服务保护功能。它也是基于Netflix的开源框架 Hystrix实现的，该框架目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备了服务降级、服务熔断、线程隔离、请求缓存、请求合并以及服务监控等强大功能。 什么是断路器 断路器模式源于Martin Fowler的Circuit Breaker一文。

版权声明：署名，允许他人基于本文进行创作，且必须基于与原先许可协议相同的许可协议分发本文 （ Creative Commons ） 文章目录 使用熔断器仪表盘监控 在 pom.xml 中增加依赖 在 Application 中增加 @EnableHystrixDashboard 注解 创建 hystrix.stream 的 Servlet 配置 测试 Hystrix Dashboard Hystrix 说明 什么情况下会触发` fallback `方法 fallback 方法在什么情况下会抛出异常 Hystrix Dashboard 界面监控参数 Hystrix 常用配置信息 超时时间（默认1000ms，单位：ms） 线程池核心线程数 Queue 断路器 fallback 属性配置参数 使用熔断器仪表盘监控 在 Provider 和 Consumer 项目增加 Hystrix 仪表盘功能，两个项目的改造方式相同 在 pom.xml 中增加依赖 < dependency > < groupId > org . springframework . cloud < / groupId > < artifactId > spring - cloud - starter - netflix - hystrix - dashboard < / artifactId > < version >

Feign的底层基于Rabbion实现的，一般情况下直接导入feign的依赖，然后调用feignClient去发送请求，报请求超时。 application.yml #hystrix的超时时间 hystrix: command: default: execution: timeout: enabled: true isolation: thread: timeoutInMilliseconds: 9000 #ribbon的超时时间 ribbon: ReadTimeout: 3000 ConnectTimeout: 3000

Ŀ¼ Hystrix（ https://github.com/Netflix/Hystrix ）是Netflix（ https://www.netflix.com/global ）的一个开源 项目，主要作用是通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容 错能力。（复制过来的） 上图当前service1异常时候，此时service1来了大量的请求，请求一直继续过来， 一直消耗CPU资源，当CPU资源消耗完了之后，会导致整个项目宕机，不仅使得service1 不能提供正常服务，而且还影响了service2和service3服务。 为了解除此种场景，Hystrix提供了线程隔离。其原理是为每个服务创建一个线程池， 每次请求过来请线程池获取请求资源，线程池中封装了service提供的服务。 单个依赖可以配置超时时间，当前规定时间未获取结果，可直接走callback逻辑。对于不同的处理结果，自定义化处理结果内容和逻辑。 返回结果分别为：成功，失败（抛出异常），超时，线程拒绝，短路。 时间控制：withCircuitBreakerSleepWindowInMilliseconds 超过阈值走getFallback 接口 成功率控制：withCircuitBreakerErrorThresholdPercentage 超过阈值走getFallback 接口

Ŀ¼ 背景 ：分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务 雪崩效应。 为了应对服务雪崩, 一种常见的做法是手动服务降级，而Hystrix的出现,给我们提供了另一 种选择。 出现雪崩原因 ：服务调用者不可用、重试增加流量、服务提供者不可用 服务不可用场景 ：硬件故障、程序Bug、缓存击穿、用户大量请求 重试增加流量场景 ：代码重试调用、用户重复调用 hystrix熔断策略 ：流量阈值控制、熔断开关控制、熔断间断性尝试服务状态 官方流程图 ： （1）构建一个command，command 有两种模式：一种是正常的线程模式，另外一种是观察者模式。 （2）执行command 命令，执行command有四种方式：execute（以同步阻塞方式执行command的 run方法）、queue（以异步方式执行command的run方法）、observe（事件注册前执行run/construct）、 toObservable（事件注册前执行run/construct） （3）缓存命中验证：验证当前请求是否命中缓存，如果命中缓存直接返回命中结果。 （4）熔断开关判定：打开直接进去command的回退逻辑 （5）信号量或者线程池容量判定：判断当前的command对应的请求数量是否超过最大信号量或者线程池 阈值，超过则进入异常处理逻辑fallback