hystrix

在一个具有多服务的应用中，假如由于其中某一个服务出现问题，导致响应速度变慢，或是根本没有响应返回，会导致它的服务消费者由于长时间的等待，消耗尽线程，进而影响到对其他服务的线程调用，进而会转变为整个应用的故障。这也被称之为雪崩效应。 而Hystrix熔断器，正是用来帮助我们解决这种问题的工具。 Hystrix提供了熔断、隔离、fallback、cache、监控等功能，能够在一个或多个服务出现问题的时候保证整个应用依然处于可用状态。 没有做熔断处理的应用，出现问题后： 正常情况：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　A→B→C→D D服务出现了问题：　　　　　　　　　　　　　　　　　　　　 　　　　　 A→B→C×D 从而导致C服务无法获取正确的响应，出现对应的问题：　　　 　　　　　　 A→B×C×D 最后导致B服务，甚至A服务都同样出现问题，由服务不可用变为应用不可用： A×B×C×D 针对于上面的这种情况，在Hystrix中采用了如下的几种方式进行处理。 1.Hystrix请求超时 用hystrix监控请求的响应时间，如果超过我们设置的时间，将会被判定为请求超时，抛出TimeoutException。 （1）引入Maven依赖 <dependency> <groupId>org.springframework.cloud</groupId>

什么是服务雪崩？ 单个服务发生故障，占用过多的系统资源，从而导致级联故障的情况称为服务雪崩。 什么是Hystrix？ 在分布式环境中，许多服务依赖项中的一些必然会失败。(服务挂了) Hystrix是一个库，通过添加延迟容忍和容错逻辑，控制这些分布式服务之间的交互。 Hystrix通过隔离服务之间的访问点、停止级联失败和提供回退选项来实现这一点，所有这些都可以提高系统的整体弹性。 容错：允许犯错，在微服务开放中主要体现在服务故障。 简言之，Hystrix是一个实现 容错机制 的组件。【也是实现高可用的目的】 Hystrix的主要作用 为网络请求设置超时 使用断路器模式 什么是断路器模式？ 家用空开就是一种断路器模式，前身是保险丝。假设某个电器负载过大而损坏，空开会跳闸，而保险丝会熔断。 假设没有空开或者保险丝呢？引起更大的电路故障，甚至导致火灾，再扩张可能会烧到邻居家的房子。 对于微服务来说同样如此，当某一个服务出现问题时，使用断路器关停服务，不会导致由于持续访问导致的资源占有从而引起其他服务的正常运行。 服务熔断与服务降级 服务熔断指的是当网络请求达到某一个阈值（可设置）时，为了防止服务过载，占用系统资源，暂停该服务的调用，使服务降级。【服务没挂，但是担心挂了，就让服务暂时休息一下】 服务降级涉及的范围更大， 超时降级：主要配置好超时时间和超时重试次数和机制

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

Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。 说到熔断器，先要引入另外一个词，雪崩效应。 雪崩效应，百度百科的解释是这样的： 登山时，决不能顺着山边扔石子儿。一是有击中别人的危险，一枚从数千英尺落下的小石头，破坏力相当惊人；二是有可能引发雪崩，一枚不起眼的小石子儿，顶多只能撞动几块差不多大小的石头；但只要有足够数量的石头翻滚起来，用不了多久，大块大块的岩石也会松动下滑。于是乎，这一颗小小的石子儿，就能引发一场雪崩。这个道理不言自明，好比就是水滴石穿、蝴蝶效应，说的都是一个小因素的变化，却往往有着无比强大的力量，以至于最后改变整体结构、产生意想不到的结果。现在，把这个原理适用于商业和技术领域，它同样能得到类似的效果—商业和技术本身具有一定的结构和体系，当人们适当地拆散其结构，并予以重新组合，便能释放出犹如雪崩般巨大的能量。雪崩把旧有的产业体系打得粉碎，甚至，有时候干脆让整个产业消失。在雪崩的巨大压力下，商业与技术之间固有的联系被彻底中断，不得不接受新的改造和整合，其最终将引爆一系列创新的革命，这就是“雪崩效应”。 以上来自百度百科。 从上面可以看到，造成雪崩效应很可能就是因为一个特别小的原因，比如一个石子。然后让我们在看一下下图： 图中每个字母代表了一个微服务，剪头代表服务的调用。 假设1：

微服务 微服务是一种架构风格 单体架构的缺点 开发效率会越来越低， 代码越来越难维护，稳定性不高，扩展性不够 分布式多节点， 各个节点是通过网络发消息通信的 微服务的特点 1， 异构，可以用 不同语言，不同类型的数据库 2，spring cloud 的服务调用方式 可以用 REST or RPC ,因此 其他语言的 客户端可以去实现 比如 Node.js 的 eureka-js-client 可以注册到 eureka 服务中心 spring cloud spring clound 的版本对应的其他相关的 版本 https://spring.io/projects/spring-cloud 可以在官网看的 spring cloud 中文文档 https://springcloud.cc/ Eureka Server com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server 这个错误是因为，开始 eureka 即是服务端，也是客户端，所以需要配置服务端地址 eureka: client: service-url: defaultZone: http://localhost:8080/eureka/ eureka 通过心跳方式，不停检查

微服务架构中，微服务之间相互调用，springcloud可以用feign方式和RestTemplate+ribbon方式来实现服务间的相互调用。但如果某一个服务出现问题，所有调用该出问题的服务都将出现阻塞，如果有大量的请求，则Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 为了解决这个问题，业界提出了断路器模型。 1.ribbon中使用断路器hystrix build.gradle文件 buildscript { ext { springBootVersion = '2.0.4.RELEASE' } repositories { mavenCentral() } dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}") } } apply plugin: 'java' apply plugin: 'eclipse' apply plugin: 'org.springframework.boot' apply plugin: 'io.spring.dependency-management' group = 'com

对断路器模式不太清楚的话，可以参看另一篇博文： 断路器（Curcuit Breaker）模式 ，下面直接介绍Spring Cloud的断路器如何使用。 SpringCloud Netflix实现了断路器库的名字叫Hystrix. 在微服务架构下，通常会有多个层次的服务调用. 下面是微服架构下, 浏览器端通过API访问后台微服务的一个示意图： 一个微服务的超时失败可能导致瀑布式连锁反映，下图中，Hystrix通过自主反馈实现的断路器， 防止了这种情况发生。 图中的服务B因为某些原因失败，变得不可用，所有对服务B的调用都会超时。当对B的调用失败达到一个特定的阀值(5秒之内发生20次失败是Hystrix定义的缺省值), 链路就会被处于open状态， 之后所有所有对服务B的调用都不会被执行， 取而代之的是由断路器提供的一个表示链路open的Fallback消息. Hystrix提供了相应机制，可以让开发者定义这个Fallbak消息. open的链路阻断了瀑布式错误， 可以让被淹没或者错误的服务有时间进行修复。这个fallback可以是另外一个Hystrix保护的调用, 静态数据，或者合法的空值. Fallbacks可以组成链式结构，所以，最底层调用其它业务服务的第一个Fallback返回静态数据. 下面，进入正题，在之前的两HELLO WORLD服务集群中加入断路器，

在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 为了解决这个问题，业界提出 一、断路器简介 Netflix has created a library called Hystrix that implements the circuit breaker pattern. In a microservice architecture it is common to have multiple layers of service calls. . ----摘自官 较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。 断路打开后，可用避免连锁故障，fallback方法可以直接返回一个固定值。 二、准备工作 这篇文章基于上一篇文章的工程

出现这个问题是在zuul集成多实例后，通过zuul访问Ribbon方法出现的 com.netflix.zuul.exception.ZuulException: Hystrix Readed time out 而没有触发配置的服务熔断调用 fallbackMethod ， 但是直接通过Ribbon直接访问确可以触发。 网上搜了半天解决方法大致如下↓ 让我在 application.properties 添加这些，改什么时间大小，但是这些我早就配置了，并没有实际解决问题。。 这里吐槽一下别人写的方法，具体是某某的就不说了。。。 ###socket超时 zuul.host.socket-timeout-millis=60000 #HTTP连接超时要比Hystrix的大 zuul.host.connect-timeout-millis=10000 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=3000 #请求连接的超时时间 ribbon.ConnectTimeout=250 ribbon.ReadTimeout=250 正确的解决方式： #在zuul里，重新封装了hytrix的一些配置名称，导致hytrix的一些原生配置会失效 #需要通过zuulProperties重新设置的属性如下：

Feign在RestTemplate的基础上对其封装，由它来帮助我们定义和实现依赖服务接口的定义。Spring Cloud Feign 基于Netflix Feign 实现的，整合了Spring Cloud Ribbon 与 Spring Cloud Hystrix，并且实现了声明式的Web服务客户端定义方式。 我的理解是Feign是一个接口，是发起rest请求的工具，它集成了ribbon负载均衡和hystrix的错误熔断机制，通过rest的方式得到类似rpc远程调用的服务，也就是根据用户（客户）的url路径参数要求，去申请其他微服务的资源（多个服务可以负载均衡比如轮询），如果某个微服务宕机，可以通过hystric熔断（躲开），并返回回退函数的值给客户。 1. 创建微服务spring start project项目，命名为microservice-Feign-Hystrix-8804 2.pom.xml 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-feign</artifactId> <version>1.4.6.RELEASE</version> </dependency> 3.application.properties server