hystrix

Spring Cloud作为一套微服务治理的框架，几乎考虑到了微服务治理的方方面面，之前也写过一些关于Spring Cloud文章，主要偏重各组件的使用，本次分享主要解答这两个问题：Spring Cloud在微服务的架构中都做了哪些事情？Spring Cloud提供的这些功能对微服务的架构提供了怎样的便利？ 这也是我写Spring Cloud三部曲的最后一篇文章，前两面篇内容如下： 中小型互联网公司微服务实践-经验和教训 Spring Cloud在国内中小型公司能用起来吗？ 我们先来简单回顾一下，我们以往互联网架构的发展情况： 传统架构发展史 单体架构 单体架构在小微企业比较常见，典型代表就是一个应用、一个数据库、一个web容器就可以跑起来，比如我们开发的开源软件 云收藏 ，就是标准的单体架构。 在两种情况下可能会选择单体架构：一是在企业发展的初期，为了保证快速上线，采用此种方案较为简单灵活；二是传统企业中垂直度较高，访问压力较小的业务。在这种模式下对技术要求较低，方便各层次开发人员接手，也能满足客户需求。 下面是单体架构的架构图： 在单体架构中，技术选型非常灵活，优先满足快速上线的要求，也便于快速跟进市场。 垂直架构 在单体架构发展一段时间后，公司的业务模式得到了认可，交易量也慢慢的大起来，这时候有些企业为了应对更大的流量，就会对原有的业务进行拆分，比如说：后台系统、前端系统

　　前言 　　SpringCloud 是微服务中的翘楚，最佳的落地方案。 　　在微服务架构中多层服务之间会相互调用，如果其中有一层服务故障了，可能会导致一层服务或者多层服务故障，从而导致整个系统故障。这种现象被称为服务雪崩效应。 　　SpringCloud 中的 Hystrix 组件就可以解决此类问题，Hystrix 负责监控服务之间的调用情况，连续多次失败的情况进行熔断保护。 　　保护的方法就是使用 Fallback，当调用的服务出现故障时，就可以使用 Fallback 方法的返回值; 　　Hystrix 间隔时间会再次检查故障的服务，如果故障服务恢复，将继续使用服务。 　　源码 　　GitHub地址：https://github.com/intomylife/SpringCloud 　　环境 　　JDK 1.8.0 + 　　Maven 3.0 + 　　SpringBoot 2.0.3 　　SpringCloud Finchley.RELEASE 　　开发工具 　　IntelliJ IDEA 　　正文 　　commons 工程 　　commons 工程 - POM 文件 　　xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 　　4

Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix Dashboard我们可以在直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine. Hystrix Dashboard 我们在熔断示例项目spring-cloud-consumer-hystrix的基础上更改，重新命名为：spring-cloud-consumer-hystrix-dashboard。 1、添加依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> </dependency>

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

本文介绍Hystrix线程池的工作原理和参数配置，指出存在的问题并提供规避方案，阅读本文需要对Hystrix有一定的了解。 文本讨论的内容，基于hystrix 1.5.18： <dependency> <groupId>com.netflix.hystrix</groupId> <artifactId>hystrix-core</artifactId> <version>1.5.18</version> </dependency> 线程池和Hystrix Command之间的关系 当hystrix command的隔离策略配置为线程，也就是execution.isolation.strategy设置为THREAD时，command中的代码会放到线程池里执行，跟发起command调用的线程隔离开。摘要官方wiki如下： execution.isolation.strategy This property indicates which isolation strategy HystrixCommand.run() executes with, one of the following two choices: THREAD — it executes on a separate thread and concurrent requests are limited by the

目录： springcloud费话之Eureka基础 springcloud费话之Eureka集群 springcloud费话之Eureka服务访问（restTemplate） springcloud费话之Eureka接口调用（feign） springcloud费话之断路器（hystrix in feign） 使用eureka服务发现实现服务器之间的http访问（feign）并添加断路器hystrix 断路器，是springcloud中的一种熔断机制的实现方式 熔断机制，是达到了某个异常以后，后续判断不进行，直接否定的一种方式，类似于&&或者||的熔断的感觉 因为服务器之间的调用，判断错误链，以及出现问题以后的回调，时间可能会很长，如果不尽快阻止， 很可能导致很多请求都等待几十秒的超时而造成服务器阻塞，进而造成服务器崩溃 因此熔断机制十分重要 在springcloud的熔断机制，叫做Spring Cloud Circuit Breaker 具体使用的是hystrix断路器 具体使用方式和流程如下 1.依赖 在springcloud官方网站中找到断路器()的依赖,如下图,并导入pom 2.在启动类添加注解 在启动类添加注解@EnableHystrix，添加后代码如下： package com.lyh.lyh_eureka_server; import org

I'm trying to run Spring Boot (with Spring Cloud) + Eureka Server + Hystrix Dashboard and Turbine stream, but I run into a problem I couldn't find any solution so far. I use Spring Boot 1.2.1.RELEASE and Spring Cloud 1.0.0.RC2 . Here is what I have: The first instance is running Eureka server and Hystrix dashboard: @Configuration @EnableAutoConfiguration @EnableEurekaServer @EnableHystrixDashboard @EnableDiscoveryClient class Application { public static void main(String[] args) { SpringApplication.run Application, args } } Here you can find build.gradle for that instance - https://gist.github

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

Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix Dashboard我们可以在直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine. Hystrix Dashboard 我们在熔断示例项目spring-cloud-consumer-hystrix的基础上更改，重新命名为：spring-cloud-consumer-hystrix-dashboard。 1、添加依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> </dependency>

我们提到断路器是根据一段时间窗内的请求情况来判断并操作断路器的打开和关闭状态的。而这些请求情况的指标信息都是HystrixCommand和HystrixObservableCommand实例在执行过程中记录的重要度量信息，它们除了Hystrix断路器实现中使用之外，对于系统运维也有非常大的帮助。这些指标信息会以“滚动时间窗”与“桶”结合的方式进行汇总，并在内存中驻留一段时间，以供内部或外部进行查询使用，Hystrix Dashboard就是这些指标内容的消费者之一。 下面我们基于之前的示例来结合Hystrix Dashboard实现Hystrix指标数据的可视化面板，这里我们将用到下之前实现的几个应用，包括： eureka-server：服务注册中心 eureka-client：服务提供者 eureka-consumer-ribbon-hystrix：使用ribbon和hystrix实现的服务消费者 由于eureka-consumer-ribbon-hystrix项目中的 /consumer 接口实现使用了 @HystrixCommand 修饰，所以这个接口的调用情况会被Hystrix记录下来，以用来给断路器和Hystrix Dashboard使用。断路器我们在上一篇中已经介绍过了，下面我们来具体说说Hystrix Dashboard的构建。 动手试一试 在Spring