SpringCloud——Hystrix

最新推荐文章于 2023-03-14 11:11:04 发布

WYFVV

最新推荐文章于 2023-03-14 11:11:04 发布

阅读量200

点赞数

分类专栏： Spring Cloud

本文链接：https://blog.csdn.net/WYFVV/article/details/115760483

版权

Spring Cloud 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一.简介

1.1 什么是Hystrix

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

"断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应（FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

1.2 解决了什么问题？

在复杂的分布式系统中，服务与服务之间的依赖错综复杂，这些服务由于某些原因，例如机房的不可靠性，网络服务商的不可靠性等，导致某个服务不可用。如果系统不隔离不可用的服务，可能会导致整个系统的不可用。

在高并发的情况下，单个现成的延迟会导致整个请求都处于延迟状态，可能在几秒钟就使整个服务处于线程负载饱和状态。

某个服务的单个点的请求故障会导致用户的请求处于阻塞状态，最终的结果就是整个服务的线程资源消耗殆尽。由于服务的依赖性，会导致依赖该故障服务的其他服务处于线程阻塞状态，最终导致这些服务的线程资源消耗殆尽，直至不可用，从而导致整个服务系统都不可用，即雪崩效应。

为了防止雪崩效应，因此产生了熔断器模型，Hystrix是一个表现非常好的开源组件，是Spring Cloud不可缺少的一个组件。

1.3 Hystrix的设计原则

防止单个服务的故障耗尽整个服务Servlet容器的线程资源
快速失败机制，如果某个服务出现了故障，则调用该服务的请求失败机制，而不是线程等待
提供回退方案，在请求发生故障的时候，提供设定好的回退方案
使用熔断机制，防止故障扩散到其他服务
提供熔断器的监控组件Hystrix Dashboard，可以实时监控熔断器的状态

1.4 Hystrix的工作机制

当某个服务的API接口失败次数在一定时间内小于设定的阀值，熔断器处于关闭状态，该API接口正常提供服务。当API接口处理请求的失败次数大于阀值时，Hystrix判定该接口出现了故障，打开熔断器，此时请求该API接口会执行快速失败的逻辑（即fallback回退的逻辑），不执行业务逻辑，请求线程不会处于阻塞状态。处于打开状态的熔断器，一段时间后会处于半打开状态，并将一定数量的请求执行正常逻辑。剩余请求会执行快速逻辑，若执行正常逻辑失败了，则熔断器打开；若成功了，则将熔断器关闭，这样熔断器就具有自我修复的功能。

二.容错

2.1 服务熔断和服务降级（容错）

服务熔断是应对雪崩效应的一种微服务链路保护机制。例如在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。
服务熔断解决如下问题： 1. 当所依赖的对象不稳定时，能够起到快速失败的目的；2. 快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复。

服务降级是指当服务器压力剧增的情况下，根据实际业务情况和流量，对一些服务和页面有策略上的不处理或者换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或者高效运作。服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。

自动降级分类
1）超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况
2）失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况
3）故障降级：比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）
4）限流降级：秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

熔断和降级的区别

2.1.1 RestTemplate和Ribbon上使用熔断器

1.导入依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>

2.在启动类上增加@EnableHystrix注解，开启Hystrix的熔断器功能

3.在方法增加@HystrixCommand注解，有了这个注解，就开启了熔断器的功能。fallback不需要处理复杂的逻辑，也不需要远程调度其他服务，这样方便执行快速失败，释放线程资源。如果一定要在fallback逻辑中远程调度其他服务，最好在远程调度其他服务时，也加上熔断器。

@RestController
public class OrderController {
    public static final String PAYMENT_URL = "http://localhost:8001";

    @Resource
    private RestTemplate restTemplate;

    @HystrixCommand(fallbackMethod = "fallbackErrod")
    @GetMapping("/consumer/payment/create")
    public CommonResult<Payment> create(Payment payment){

        return restTemplate.postForObject(PAYMENT_URL+"/payment/create", payment, CommonResult.class);
    }

    private String fallbackErrod()
    {
        return "error";
    }

}

2.1.2 Feign上使用熔断器

由于Feign的起步依赖中已经引入Hystrix，所以在Feign中使用Hystrix不需要引入任何的依赖。只需要配置文件applicayion.yml中配置开启Hystrix的功能：

feign:
  hystrix:
     enabled:ture

然后在@FeignClient注解的fallback加上快速失败的处理类，这个处理类是作为Feign熔断器的逻辑处理类，必须实现被@FeignClient修饰的接口。

@FeignClient(value="application-name",
              fallback=MyHystrix.class)
public class FeignClientHy{
    public static final String PAYMENT_URL = "http://localhost:8001";


    @GetMapping("/consumer/payment/create")
    public String create(Payment payment);

}

MyHystrix作为熔断器处理类，需要实现FeignClientHy接口，并需要在接口方法写具体的熔断逻辑，同时还要加上@Component注解：

@Component
public class MyHystrix implements FeignClientHy{
  @Override
  public String create(Payment payment)
   {
        return "error"
    }
}

@HystrixCommand注解的参数

commandKey:配置全局唯一表示服务的名称，比如，库存系统有一个获取库存服务，那么就可以为这个服务起一个名字来唯一识别该服务，如果不配置，则默认是@HystrixCommand注解修饰的函数的函数名。
groupKey：配置全局唯一表示服务分组的名称。比如库存系统就是一个服务分组。通过设置分组，Hystrix会根据组来组织和统计命令等信息。Hystrix命令默认的线程划分也是根据命令组来实现的。默认情况下，Hystrix会让相同组名的命令使用同一个线程池。所以我们需要在创建Hystrix命令时为其指定命令组来实现默认的线程池划分。此外，Hystrix还提供了通过设置threadPoolKey来对线程池进行设置。建议最好设置该参数，使用threadPoolKey来控制线程池
threadPoolKey：设定线程池，细粒度的配置，相当于对单个服务的线程池信息进行设置。也可多个服务设置同一个threadPoolKey构成线程组
fallbackMethod：@HystrixCommand注解修饰的函数的回调函数，@HystrixCommand修饰的函数必须和这个回调函数定义在同一个类中，因为定义在了同一个类中，所以fackback method可以是public/private均可。
commandProperties：配置该命令的一些参数，如executionIsolationStrategy配置执行隔离策略，默认是使用线程隔离，此处我们配置为THREAD，即线程池隔离。参见：com.netflix.hystrix.HystrixCommandProperties中各个参数的定义。
threadPoolProperties：线程池相关参数设置，具体可以设置哪些参数请参见:com.netfilx.hystrix.HystrixThreadPoolProperties
ignoreExceptions：调用服务时，除了HystrixBadRequestException之外，其他@HystrixCommand修饰的函数抛出的异常均会被Hystrix认为命令执行失败而触发服务降级的处理逻辑（调用fallbackMethod指定的回调函数），所以当需要在命令执行中抛出不触发降级的异常时来使用它，通过这个参数指定，哪些异常抛出时不触发降级（不去调用fallbackMethod），而是将异常向上抛出。
observableExecutionMode：定义hystrix observable command的模式
raiseHystrixExceptions：任何不可忽略的异常都包含在HystrixRuntimeException中
efaultFallback：默认的回调函数，该函数的函数体不能有入参，返回值类型与@HystrixCommand修饰的函数体的返回值一致。如果指定了fallbackMethod，则fallbackMethod优先级更高。

2.1.3 熔断器总结

熔断打开：请求不再调用当前服务，内部设置时钟一般为MTTR（平均内部故障时间），当打开熔断器到达一定时长后进入半熔断状态
熔断关闭：熔断关闭不会对服务进行熔断
熔断半开：部分根据规则调用当前服务，如果请求成功且符合规则则任务当前服务恢复正常

//=====服务熔断
@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",commandProperties = {
    @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),// 是否开启断路器
    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),// 请求次数
    @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"), // 时间窗口期
    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),// 失败率达到多少后跳闸
})
public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
    ...
}

快照时间窗：断路器确定是否打开需要统计一些请求和错误数据，而统计的时间范围就是快照时间窗，默认为最近的10秒。
请求总数阀值：在快照时间窗内，必须满足请求总数阀值才有资格熔断。默认为20，意味着在10秒内，如果该hystrix命令的调用次数不足20次7,即使所有的请求都超时或其他原因失败，断路器都不会打开。
错误百分比阀值：当请求总数在快照时间窗内超过了阀值，比如发生了30次调用，如果在这30次调用中，有15次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%阀值情况下，这时候就会将断路器打开

断路器开启或者关闭的条件，到达以下阀值，断路器将会开启：

当满足一定的阀值的时候（默认10秒内超过20个请求次数)
当失败率达到一定的时候（默认10秒内超过50%的请求失败)

当开启的时候，所有请求都不会进行转发

一段时间之后（默认是5秒)，这个时候断路器是半开状态，会让其中一个请求进行转发。如果成功，断路器会关闭，若失败，继续开启。

断路器打开之后

1.再有请求调用的时候，将不会调用主逻辑，而是直接调用降级fallback。通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

2.原来的主逻辑要如何恢复呢？对于这一问题，hystrix也为我们实现了自动恢复功能。当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。
所有配置：

@HystrixCommand(fallbackMethod = "fallbackMethod", 
                groupKey = "strGroupCommand", 
                commandKey = "strCommand", 
                threadPoolKey = "strThreadPool",
                
                commandProperties = {
                    // 设置隔离策略，THREAD 表示线程池 SEMAPHORE：信号池隔离
                    @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"),
                    // 当隔离策略选择信号池隔离的时候，用来设置信号池的大小（最大并发数）
                    @HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests", value = "10"),
                    // 配置命令执行的超时时间
                    @HystrixProperty(name = "execution.isolation.thread.timeoutinMilliseconds", value = "10"),
                    // 是否启用超时时间
                    @HystrixProperty(name = "execution.timeout.enabled", value = "true"),
                    // 执行超时的时候是否中断
                    @HystrixProperty(name = "execution.isolation.thread.interruptOnTimeout", value = "true"),
                    
                    // 执行被取消的时候是否中断
                    @HystrixProperty(name = "execution.isolation.thread.interruptOnCancel", value = "true"),
                    // 允许回调方法执行的最大并发数
                    @HystrixProperty(name = "fallback.isolation.semaphore.maxConcurrentRequests", value = "10"),
                    // 服务降级是否启用，是否执行回调函数
                    @HystrixProperty(name = "fallback.enabled", value = "true"),
                    // 是否启用断路器
                    @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
                    // 该属性用来设置在滚动时间窗中，断路器熔断的最小请求数。例如，默认该值为 20 的时候，如果滚动时间窗（默认10秒）内仅收到了19个请求， 即使这19个请求都失败了，断路器也不会打开。
                    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20"),
                    
                    // 该属性用来设置在滚动时间窗中，表示在滚动时间窗中，在请求数量超过 circuitBreaker.requestVolumeThreshold 的情况下，如果错误请求数的百分比超过50, 就把断路器设置为 "打开" 状态，否则就设置为 "关闭" 状态。
                    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"),
                    // 该属性用来设置当断路器打开之后的休眠时间窗。 休眠时间窗结束之后，会将断路器置为 "半开" 状态，尝试熔断的请求命令，如果依然失败就将断路器继续设置为 "打开" 状态，如果成功就设置为 "关闭" 状态。
                    @HystrixProperty(name = "circuitBreaker.sleepWindowinMilliseconds", value = "5000"),
                    // 断路器强制打开
                    @HystrixProperty(name = "circuitBreaker.forceOpen", value = "false"),
                    // 断路器强制关闭
                    @HystrixProperty(name = "circuitBreaker.forceClosed", value = "false"),
                    // 滚动时间窗设置，该时间用于断路器判断健康度时需要收集信息的持续时间
                    @HystrixProperty(name = "metrics.rollingStats.timeinMilliseconds", value = "10000"),
                    
                    // 该属性用来设置滚动时间窗统计指标信息时划分"桶"的数量，断路器在收集指标信息的时候会根据设置的时间窗长度拆分成多个 "桶" 来累计各度量值，每个"桶"记录了一段时间内的采集指标。
                    // 比如 10 秒内拆分成 10 个"桶"收集这样，所以 timeinMilliseconds 必须能被 numBuckets 整除。否则会抛异常
                    @HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10"),
                    // 该属性用来设置对命令执行的延迟是否使用百分位数来跟踪和计算。如果设置为 false, 那么所有的概要统计都将返回 -1。
                    @HystrixProperty(name = "metrics.rollingPercentile.enabled", value = "false"),
                    // 该属性用来设置百分位统计的滚动窗口的持续时间，单位为毫秒。
                    @HystrixProperty(name = "metrics.rollingPercentile.timeInMilliseconds", value = "60000"),
                    // 该属性用来设置百分位统计滚动窗口中使用 “ 桶 ”的数量。
                    @HystrixProperty(name = "metrics.rollingPercentile.numBuckets", value = "60000"),
                    // 该属性用来设置在执行过程中每个 “桶” 中保留的最大执行次数。如果在滚动时间窗内发生超过该设定值的执行次数，
                    // 就从最初的位置开始重写。例如，将该值设置为100, 滚动窗口为10秒，若在10秒内一个 “桶 ”中发生了500次执行，
                    // 那么该 “桶” 中只保留 最后的100次执行的统计。另外，增加该值的大小将会增加内存量的消耗，并增加排序百分位数所需的计算时间。
                    @HystrixProperty(name = "metrics.rollingPercentile.bucketSize", value = "100"),
                    
                    // 该属性用来设置采集影响断路器状态的健康快照（请求的成功、 错误百分比）的间隔等待时间。
                    @HystrixProperty(name = "metrics.healthSnapshot.intervalinMilliseconds", value = "500"),
                    // 是否开启请求缓存
                    @HystrixProperty(name = "requestCache.enabled", value = "true"),
                    // HystrixCommand的执行和事件是否打印日志到 HystrixRequestLog 中
                    @HystrixProperty(name = "requestLog.enabled", value = "true"),

                },
                threadPoolProperties = {
                    // 该参数用来设置执行命令线程池的核心线程数，该值也就是命令执行的最大并发量
                    @HystrixProperty(name = "coreSize", value = "10"),
                    // 该参数用来设置线程池的最大队列大小。当设置为 -1 时，线程池将使用 SynchronousQueue 实现的队列，否则将使用 LinkedBlockingQueue 实现的队列。
                    @HystrixProperty(name = "maxQueueSize", value = "-1"),
                    // 该参数用来为队列设置拒绝阈值。 通过该参数， 即使队列没有达到最大值也能拒绝请求。
                    // 该参数主要是对 LinkedBlockingQueue 队列的补充,因为 LinkedBlockingQueue 队列不能动态修改它的对象大小，而通过该属性就可以调整拒绝请求的队列大小了。
                    @HystrixProperty(name = "queueSizeRejectionThreshold", value = "5"),
                }
               )
public String doSomething() {
	...
}

2.2 资源隔离

2.2.1 简介

在一个分布式系统中，服务之间都是相互调用的，例如，我们容器（Tomcat）配置的线程个数为 1000，服务 A-服务 R，其中服务 I 的并发量非常的大，需要 500 个线程来执行，此时，服务 I 又挂了，那么这 500 个线程很可能就夯死了，那么剩下的服务，总共可用的线程为 500 个，随着并发量的增大，剩余服务挂掉的风险就会越来越大，最后导致整个系统的所有服务都不可用，直到系统宕机。以上就是服务的雪崩效应。Hystrix 就是用来做资源隔离的，比如说，当客户端向服务端发送请求时，给服务 I 分配了 10 个线程，只要超过了这个并发量就走降级服务，就算服务 I 挂了，最多也就导致服务 I 不可用，容器的 10 个线程不可用了，但是不会影响系统中的其他服务。

2.2.2 线程池隔离

执行依赖代码的线程与请求线程(比如Tomcat线程)分离，请求线程可以自由控制离开的时间，这也是我们通常说的异步编程，Hystrix是结合RxJava来实现的异步编程。通过为每个包裹了HystrixCommand的API接口设置独立的、固定大小的线程池（hystrix.threadpool.default.coreSize）来控制并发访问量，当线程饱和的时候可以拒绝服务（走fallback方法），防止依赖问题扩散。

线上建议线程池不要设置过大，否则大量堵塞线程有可能会拖慢服务器。

使用场景:适合大多数的场景，对依赖服务网络调用要求TimeOut等要求高的

优点：

一个依赖可以给予一个线程池，这个依赖的异常不会影响其他线程
使用线程完全隔离业务代码，请求线程可以快速返回
完全可以模拟异步调用，方便异步编程

缺点：

使用线程池的缺点主要是增加了计算的开销。每一个依赖都会涉及队列，调度，上下文切换。而这些操作可能会在不同线程上使用。

//@HystrixCommand 加到服务的接口方法上，可以对接口限流。

//下面的代码，给服务的 /hello接口 加了hystrix线程隔离，并且限制并发为5。

//当接口熔断或者降级时，会走降级方法，降级方法将异常信息返回，并且返回状态码 503

@RestController

@RequestMapping(value = "/hystrix")

public class HystrixCommandController {

    // 对controller层的接口做hystrix线程池隔离，可以起到限流的作用

    @HystrixCommand(

           fallbackMethod = "fallbackMethod", // 指定降级方法，在熔断和异常时会走降级方法

           groupKey = "querygroup-one", // 一组command，如果没有配threadPoolKey，相同的groupKey会使用同一线程池（线程池隔离策略下）

           commandKey = "helloCommand", // 服务标识，默认就是方法名

           commandProperties = {

              // 超时时间

              @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"),

              @HystrixProperty(name = "execution.timeout.enabled", value = "true"),

              // 默认是线程池隔离策略

              @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD")

           },

           threadPoolKey = "helloPool", // 可以在多个方法上定义同一个线程池

           threadPoolProperties = {

              // 并发，缺省为10

              @HystrixProperty(name = "coreSize", value = "3")

           })

    @RequestMapping(value = "/hello", method = RequestMethod.GET)

    public String sayHello(HttpServletResponse httpServletResponse) throws InterruptedException {

       Thread.sleep(2000L);

       System.out.println("Hello2 World!" + new Date());

       return "Hello World!-thread name:" + Thread.currentThread().getName();

    }

   

    @HystrixCommand(

           fallbackMethod = "fallbackMethod", // 指定降级方法，在熔断和异常时会走降级方法

           groupKey = "querygroup-one", // 一组command，如果没有配threadPoolKey，相同的groupKey会使用同一线程池（线程池隔离策略下）

           threadPoolKey = "helloPool", // 可以在多个方法上定义同一个线程池

           threadPoolProperties = {

              // 并发，缺省为10

              @HystrixProperty(name = "coreSize", value = "2")

           })

    @RequestMapping(value = "/hello2", method = RequestMethod.GET)

    public String sayHello2(HttpServletResponse httpServletResponse) throws InterruptedException {

       Thread.sleep(2000L);

       System.out.println("Hello2 World!" + new Date());

       return "Hello2 World!-thread name:" + Thread.currentThread().getName();

    }

 

    /**

     * 降级方法，状态码返回503 注意，降级方法的返回类型与形参要与原方法相同，可以多一个Throwable参数放到最后，用来获取异常信息

     */

    public String fallbackMethod(HttpServletResponse httpServletResponse, Throwable e) {

       httpServletResponse.setStatus(HttpStatus.SERVICE_UNAVAILABLE.value());

       e.printStackTrace();

       return "亲，后台报错了:" + e;

    }

}

多个不同的API接口如何使用同一个ThreadPool，只要groupKey和threadPoolKey相同就行。如果设置的核心线程数不同，默认设置访问第一个API接口设置的。

2.2.3 信号量隔离

用于隔离本地代码或可快速返回远程调用（memcached,redis等）可以直接使用信号量隔离，降低线程隔离的上下文切换开销。

主要使用场景：并发需求不大的依赖调用（因为如果并发需求较大，相应的信号量的数量就要设置得够大，因为Tomcat线程与处理线程为同一个线程，那么这个依赖调用就会占用过多的Tomcat线程资源，有可能会影响到其他服务的接收）

信号量的资源隔离只是起到一个开关的作用，比如，服务 A 的信号量大小为 10，那么就是说它同时只允许有 10 个 tomcat 线程来访问服务 A，其它的请求都会被拒绝，从而达到资源隔离和限流保护的作用。

两者区别：

三.Hystrix的监控

Hystrix Dashboard是监控Hystrix的熔断器状况的一个组件，提供了数据监控和友好的图形化界面。

使用

1.添加依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>

2.在启动类上增加注解@EnableHystrixDashboard

3.在属性配置文件只需要配置服务名和服务端口

spring.application.name=hystrix-dashboard-demo
server.port=9011

4.然后启动服务，访问 http://localhost:9011/hystrix 就可以看到 dashboard 的主页：

dashboard主页

第一行是监控的 stream 地址，也就是将之前文字监控信息的地址输入到第一个文本框中。第二行的 Delay 是时间，表示用多少毫秒同步一次监控信息，Title 是标题，这个可以随便填写。输入完成后就可以点击 Monitor Stream 按钮以图形化的方式查看监控的数据了

WYFVV

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
SpringCloud——Hystrix

一.简介1.1 什么是HystrixHystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。"断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应（FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用
复制链接

扫一扫

专栏目录