hystrix

如图所示，在微服务中使用Hystrix 作为断路器时，通常涉及到一下三个重要的指标参数（这里是写在@HystrixProperties注解中，当然实际项目中可以全局配置在yml或properties中） 1、circuitBreaker.sleepWindowInMilliseconds 断路器的快照时间窗，也叫做窗口期。可以理解为一个触发断路器的周期时间值，默认为 10秒（10000） 。 2、circuitBreaker.requestVolumeThreshold 断路器的窗口期内触发断路的请求阈值，默认为 20 。换句话说，假如某个窗口期内的请求总数都不到该配置值，那么断路器连发生的资格都没有。断路器在该窗口期内将不会被打开。 3、circuitBreaker.errorThresholdPercentage 断路器的窗口期内能够容忍的错误百分比阈值，默认为 50（也就是说默认容忍50%的错误率） 。打个比方，假如一个窗口期内，发生了100次服务请求，其中50次出现了错误。在这样的情况下，断路器将会被打开。在该窗口期结束之前，即使第51次请求没有发生异常，也将被执行fallback逻辑。 综上所述，在以上三个参数缺省的情况下，Hystrix断路器触发的默认策略为： 在10秒内，发生20次以上的请求时，假如错误率达到50%以上，则断路器将被打开。（当一个窗口期过去的时候

Hystrix概述 分布式系统面临的问题： 复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。  服务雪崩： 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。 备注：一般情况对于服务依赖的保护主要有3中解决方案： 熔断模式：这种模式主要是参考电路熔断，如果一条线路电压过高，保险丝会熔断，防止火灾。放到我们的系统中，如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。 隔离模式：这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火少光了，不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离

伴随着微服务架构被宣传得如火如荼，一些概念也被推到了我们面前（管你接受不接受），其实大多数概念以前就有，但很少被提的这么频繁（现在好像不提及都不好意思交流了）。想起有人总结的一句话，微服务架构的特点就是：“一解释就懂，一问就不知，一讨论就吵架”。 服务熔断 在介绍熔断机制之前，我们需要了解微服务的雪崩效应。在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。 熔断机制是应对雪崩效应的一种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。股票交易中，如果股票指数过高，也会采用熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。 在Spring

1、POM配置 　　和普通Spring Boot工程相比，仅仅添加了Hystrix Dashboard和Spring Boot Starter Actuator依赖 <dependencies>　　<!--添加Turbine依赖--> 　　<dependency> 　　　　<groupId>org.springframework.cloud</groupId> 　　　　<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> 　　</dependency> 　　<dependency> 　　　　<groupId>org.springframework.boot</groupId> 　　　　<artifactId>spring-boot-starter-actuator</artifactId> 　　</dependency> </dependencies> <dependencyManagement> 　　<dependencies> 　　　　<dependency> 　　　　　　<groupId>org.springframework.cloud</groupId> 　　　　　　<artifactId>spring-cloud-dependencies</artifactId> 　　　　　　<version

先导篇：SpringCloud介绍篇 第一篇：注册中心Eureka 第二篇：服务提供与Rest+Ribbon调用 第三篇：服务提供与Feign调用 第四篇：熔断器Hystrix（断路器） 第五篇：熔断监控Hystrix Dashboard和Turbine 第六篇：配置中心（Spring Cloud Config） 第七篇：高可用配置中心（Spring Cloud Config） 第七篇（续）：Apollo配置中心 第八篇：消息总线（Spring Cloud Bus） 第九篇：路由网管（Zuul） 第十篇：服务链路追踪（Spring Cloud Sleuth） 来源： https://www.cnblogs.com/niudaben/p/12420892.html

写作时间：2020-03-06 Spring Cloud: Greenwich, Spring Boot: 2.1, JDK: 1.8, IDE: IntelliJ IDEA 说明 Spring Cloud Hystrix 是Spring Cloud Netflix 子项目的核心组件之一，具有服务容错及线程隔离等一系列服务保护功能，本文将对其用法进行详细介绍。 在微服务架构中，服务与服务之间通过远程调用的方式进行通信，一旦某个被调用的服务发生了故障，其依赖服务也会发生故障，此时就会发生故障的蔓延，最终导致系统瘫痪。Hystrix实现了断路器模式，当某个服务发生故障时，通过断路器的监控，给调用方返回一个错误响应，而不是长时间的等待，这样就不会使得调用方由于长时间得不到响应而占用线程，从而防止故障的蔓延。Hystrix具备服务降级、服务熔断、线程隔离、请求缓存、请求合并及服务监控等强大功能。 1. 拷贝Eureka Server和UserServiceClient工程 1.1 【易实战】Spring Cloud Greenwich Ribbon：负载均衡的服务调用 的项目 EurekaServer 和 项目 UserServiceClient 。 1.2 Run Dashboard 运行应用 EurekaServerApplication 和应用 ClientApplication

分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况，这种现象被称为服务雪崩效应。为了应对服务雪崩，一种常见的做法是手动服务降级。而 Hystrix 的出现，给我们提供了另一种选择。 Hystrix [hɪst’rɪks] 的中文含义是 “豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与 Hystrix 本身的功能不谋而合，因此 Netflix 团队将该框架命名为 Hystrix，并使用了对应的卡通形象做作为 logo。 服务雪崩效应 定义 服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用，并将不可用 逐渐放大 的过程。如果所 示: 上图中，A 为服务提供者，B 为 A 的服务调用者，C 和 D 是 B 的服务调用者。当 A 的不可用，引起 B 的不可用，并将不可用逐渐放大 C 和 D 时，服务雪崩就形成了。 形成的原因 我把服务雪崩的参与者简化为 服务提供者 和 服务调用者，并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因: 服务提供者不可用 重试加大流量 服务调用者不可用 服务雪崩的每个阶段都可能由不同的原因造成，比如造成 服务不可用 的原因有: 硬件故障 程序 Bug 缓存击穿 用户大量请求 硬件故障可能为硬件损坏造成的服务器主机宕机，网络硬件故障造成的服务提供者的不可访问。 缓存击穿一般发生在缓存应用重启

spring boot集成Hystrix 1. 什么是Hystrix 2. Hystrix解决了什么问题 3. Hystrix设计原则 4. Hystrix工作机制 5. RestTemplate和Ribbon使用Hystrix 5.1 创建项目 5.2 配置 5.3 添加注解 5.4 创建Ribbon配置 5.5 创建Ribbon Service 5.6 创建controller 5.7 验证 6. 在Feign上使用熔断器 6.1 创建项目 6.2 配置 6.3 添加注解 6.4 feign配置 6.5 feign调用 6.6 feign的hystrix处理 6.7 service 6.8 controller 6.9 验证 7. RestTemplate和Feign对比 8. Hystrix Dashboard & RestTemplate 8.1 创建 8.2 配置 8.3 配置hystrix dashboard 8.4 配置ribbon 8.5 service 8.6 controller 8.7 注解 8.8 启动 9. Hystrix Dashboard & Feign 9.1 创建 9.2 配置 9.3 配置hystrix dashboard 9.4 配置feign 9.5 dao.feign 9.6 hystrix.feign 9.7 service 9.8

　　 概念定义 　　 　　Spring Cloud 是一个服务治理平台，提供了一些服务框架。包含了：服务注册与发现、配置中心、消息中心 、负载均衡、数据监控等等。 　　Spring Cloud 是一个微服务框架，相比 Dubbo 等 RPC 框架，Spring Cloud 提供了全套的分布式系统解决方案。 　　Spring Cloud 对微服务基础框架 Netflix 的多个开源组件进行了封装，同时又实现了和云端平台以及 Spring Boot 框架的集成。 　　Spring Cloud 是一个基于 Spring Boot 实现的云应用开发工具，它为开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。 　　Spring Cloud 为开发者提供了快速构建分布式系统的工具，开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。微服务是可以独立部署、水平扩展、独立访问（或者有独立的数据库）的服务单元，Spring Cloud 就是这些微服务的大管家，采用了微服务这种架构之后，项目的数量会非常多，Spring Cloud 做为大管家需要管理好这些微服务，自然需要很多小弟来帮忙。 　　 子项目 　　 　　Spring Cloud 包含了很多子项目： 　　 Spring Cloud

org.springframework.cloud.sleuth.instrument.web.client.feign.TraceFeignClientAutoConfiguration /** * { @link org.springframework.boot.autoconfigure.EnableAutoConfiguration * Auto-configuration} enables span information propagation when using Feign. * * @author Marcin Grzejszczak * @since 1.0.0 */ @Configuration @ConditionalOnProperty(value = "spring.sleuth.feign.enabled", matchIfMissing = true) @ConditionalOnClass(Client.class) @ConditionalOnBean(Tracer.class) @AutoConfigureBefore(FeignAutoConfiguration.class) @AutoConfigureAfter({SleuthHystrixAutoConfiguration.class, TraceWebAutoConfiguration