hystrix

在微服务架构中，通常存在多个服务调用层。微服务之间通过网络进行通信，从而支撑起整个应用，为了保证高可用，单个服务通常也会集群部署。但由于网络原因或者自身原因，服务并不能保证100% 可用。而服务间的依赖关系，会导致故障传播，即服务提供者的不可用会导致消费者不可用，并把不可用逐渐放大，这就是雪崩效应。 这里就引入了请求超时机制和断路器模式 Hystrix 简介 Hystrix 是 Netflix 的开源组件，是一个用于实现超时机制和断路器模式的工具类库。在微服务架构中，通常存在多个服务调用层。较低级别的服务中的服务故障可能导致级联故障，一直到达用户。当对特定服务的调用超过一个阈值（默认是 10秒/20个请求/故障百分比 > 50％），断路器将打开并且不会进行调用。在出现错误和开路的情况下，开发人员可以提供一个回退 断路打开后可以防止级联故障。回退可以是另一个受 Hystrix 保护的调用、静态数据或合理的空值。 Ribbon 中整合 Hystrix 我们在 Spring Cloud 服务消费（Ribbon） 中的例子基础上添加 Hystrix 准备工作 eureka-server 作为服务注册中心 product-service 作为服务提供者 复制工程 order-service-ribbon 为 order-service-ribbon-hystrix 来整合 Hystrix

前言 前一章节，我们知道了如何利用 RestTemplate + Ribbon 和 Feign 的方式进行服务的调用。在微服务架构中，一个服务可能会调用很多的其他微服务应用，虽然做了多集群部署，但可能还会存在诸如网络原因或者服务提供者自身处理的原因，或多或少都会出现请求失败或者请求延迟问题，若服务提供者长期未对请求做出回应，服务消费者又不断的请求下，可能就会造成服务提供者服务崩溃，进而服务消费者也一起跟着不可用，严重的时候就发生了 系统雪崩 了。鉴于此，产生了断路器等一系列的服务保护机制。本章节，就来说下如何利用 Hystrix 进行容错处理。 一点知识 按照此系列的惯例，我们先来了解下一些相关的知识。 注：以下部分内容转至大佬纯洁的微笑： 熔断器Hystrix 。 容错处理手段 容错处理是指软件运行时，能对由非正常因素引起的运行错误给出适当的处理或信息提示，使软件运行正常结束——百度百科 从百度百科的解释中可以看出，简单理解，所谓的 容错处理 其实就是捕获异常了，不让异常影响系统的正常运行，正如 java 中的 try catch 一样。 而在微服务调用中，自身异常可自行处理外，对于依赖的服务若发生错误，或者调用异常，或者调用时间过长等原因时，避免长时间等待，造成系统资源耗尽。 一般上都会通过 设置请求的超时时间 ，如 http 请求中的 ConnectTimeout 和

https://cloud.spring.io/spring-cloud-openfeign/reference/html/#spring-cloud-feign-hystrix If one needs access to the cause that made the fallback trigger, one can use the fallbackFactory attribute inside @FeignClient. @FeignClient(name = "microservice-simple-provider-user", fallbackFactory = FeignClientFallbackFactory.class) public interface UserFeignClient { @RequestMapping(value = "/simple/{id}", method = RequestMethod.GET) public User findById(@PathVariable("id") Long id); } @Component public class FeignClientFallbackFactory implements FallbackFactory<UserFeignClient> { private static final

雪崩效应 在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。 如果下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。 熔断器（CircuitBreaker） 熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。 熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。 熔断器开关相互转换的逻辑如下图： 熔断器就是保护服务高可用的最后一道防线。 Hystrix特性 1.断路器机制 断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open).

一、. 创建Eureka-Server 服务中心项目 1. 创建Eureka-Server 服务中心项目架构如下 2. pom.xml <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> 3.配置文件application.properties 1 #给当前服务起名 2 spring.application.name=eureka-server 3 4 #给当前服务指定端口号 5 server.port=8761 6 7 #register-with-eureka ：表示是将自己注册到Eureka Server，默认为true。 8 #因为当前应用就是Eureka Server，所以将其设置位false 9 #

I am having an issue with my Hystrix commands. If the call to hystrix wrapped method comes from within the class, the hystrix-wrapped method does not run in Hystrix enviroment In that case I see logs as 05-02-2018 22:51:25.809 [http-nio-auto-1-exec-3] INFO c.i.q.v.e.ConnectorImpl.populateFIDSchema - populating FID Schema But, if I make call to the same method from outside the class, I see it running it in Hystrix enviroment 05-02-2018 22:54:53.735 [hystrix-ConnectorImpl-1] INFO c.i.q.v.e.ConnectorImpl.populateFIDSchema - populating FID Schema I am wrapping my method with HystrixCommand like

hystrix.command.default和hystrix.threadpool.default中的default为默认CommandKey Command Properties Execution相关的属性的配置： hystrix.command.default.execution.isolation.strategy 隔离策略，默认是Thread, 可选Thread｜Semaphore hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时间，默认1000ms hystrix.command.default.execution.timeout.enabled 执行是否启用超时，默认启用true hystrix.command.default.execution.isolation.thread.interruptOnTimeout 发生超时是是否中断，默认true hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大并发请求数，默认10，该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效。如果达到最大并发请求数

个人GitHub地址： https://github.com/leebingbin/ 在使用Spring Cloud的过程中，难免会遇到一些问题。所以对Spring Cloud的常用问题做一些总结。 关于“Eureka常见问题”可以参考，我之前的文章《微服务开发架构——Spring Cloud常见问题与总结<一>Eureka常见问题》： https://my.oschina.net/u/3375733/blog/1555725 二、Hystrix/Feign 整合Hystrix后首次请求失败 在某些场景下，Feign 或 Ribbon 整合 Hystrix 后，会出现首次调用失败的问题。 2.1 原因分析 Hystrix 默认的超时时间是1秒，如果在1秒内得不到响应，就会进入 fallback 逻辑。由于 Spring 的懒加载机制，首次请求往往会比较慢，因此在某些机器（特别是配置低的机子[Tips:为什么还要用旧瓶装新酒呢？软件都更新了，硬件也要跟上啊！^_^]）上，首次请求需要的时间可能就会大于1秒。 2.2 解决方案 有很多方式解决该问题： 1） 方法一：延长 Hystrix 的超时时间，示例如下 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds:5000 该配置让 Hystrix

个人GitHub地址： https://github.com/leebingbin/ 在使用Spring Cloud的过程中，难免会遇到一些问题。所以对Spring Cloud的常用问题做一些总结。 关于“Eureka常见问题”可以参考，我之前的文章《微服务开发架构——Spring Cloud常见问题与总结<一>Eureka常见问题》： https://my.oschina.net/u/3375733/blog/1555725 ；关于“Hystrix/Feign 整合Hystrix后首次请求失败”可以参考，我之前的文章《微服务开发架构——Spring Cloud常见问题与总结<二>Hystrix/Feign 整合Hystrix后首次请求失败》；关于 “Turbine 聚合数据不完整” 可以参考，我之前的文章《微服务开发架构——Spring Cloud常见问题与总结<三>Turbine 聚合数据不完整》。 四、Spring Cloud 各组件配置属性 Spring Cloud 的所有组件配置都在其官方文档的附录，地址如下: http://cloud.spring.io/spring-cloud-static/Camden.SR4/#_appendix_compendium_of_configuration_properties 原生配置 Spring Cloud 整合了很多类库，例如

一、问题产生 雪崩效应：是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程 正常情况下的服务 ： 某一服务出现异常，拖垮整个服务链路，消耗整个线程队列，造成服务不可用，资源耗尽： 形成过程： 1）服务提供者不可用 a）硬件故障：硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问 b）程序Bug: c) 缓存击穿：缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用 d）用户大量请求：在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用 2）重试加大流量 a）用户重试：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单 b）代码逻辑重试: 服务调用端的会存在大量服务异常后的重试逻辑 3）服务调用者不可用 a）同步等待造成的资源耗尽：当服务调用者使用同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了。 二、概念 服务熔断 ： 一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护