服务容错保护断路器Hystrix之五:配置

接着《服务容错保护断路器Hystrix之二:Hystrix工作流程解析》中的《2.8、关于配置》再列举重要的配置如下

一、hystrix在生产中的建议

1、保持timeout的默认值(1000ms),除非需要修改(其实通常会修改)

2、保持threadpool的的线程数为10个,除非需要更多

3、依赖标准的报警和监控系统来捕获问题

4、通过dashboards的实时监控来动态修改配置,直到满意为止

二、配置信息(default或HystrixCommandKey最常用的几项

  • 超时时间(默认1000ms,单位:ms)

    • hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds

      • 在调用方配置,被该调用方的所有方法的超时时间都是该值,优先级低于下边的指定配置
    • hystrix.command.HystrixCommandKey.execution.isolation.thread.timeoutInMilliseconds
      • 在调用方配置,被该调用方的指定方法(HystrixCommandKey方法名)的超时时间是该值
  • 线程池核心线程数
    • hystrix.threadpool.default.coreSize(默认为10)
  • Queue
    • hystrix.threadpool.default.maxQueueSize(最大排队长度。默认-1,使用SynchronousQueue。其他值则使用 LinkedBlockingQueue。如果要从-1换成其他值则需重启,即该值不能动态调整,若要动态调整,需要使用到下边这个配置)
    • hystrix.threadpool.default.queueSizeRejectionThreshold(排队线程数量阈值,默认为5,达到时拒绝,如果配置了该选项,队列的大小是该队列)
      • 注意:如果maxQueueSize=-1的话,则该选项不起作用
  • 断路器
    • hystrix.command.default.circuitBreaker.requestVolumeThreshold(当在配置时间窗口内达到此数量的失败后,进行短路。默认20个)

      • For example, if the value is 20, then if only 19 requests are received in the rolling window (say a window of 10 seconds) the circuit will not trip open even if all 19 failed.
    • hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds(短路多久以后开始尝试是否恢复,默认5s)
    • hystrix.command.default.circuitBreaker.errorThresholdPercentage(出错百分比阈值,当达到此阈值后,开始短路。默认50%)
  • fallback
    • hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests(调用线程允许请求HystrixCommand.GetFallback()的最大数量,默认10。超出时将会有异常抛出,注意:该项配置对于THREAD隔离模式也起作用)

三、监控hystrix

说明:hystrix为每一个commandKey提供了计数器。原理:

附:清晰大图

四、常见的hystrix事件类型

  • run()

    • SUCCESS:run()成功,不触发getFallback()
    • FAILURE:run()抛异常,触发getFallback()
    • TIMEOUT:run()超时,触发getFallback()
    • BAD_REQUEST:run()抛出HystrixBadRequestException,不触发getFallback()
    • SHORT_CIRCUITED:断路器开路,触发getFallback()
    • THREAD_POOL_REJECTED:线程池耗尽,触发getFallback()
    • FALLBACK_MISSING:没有实现getFallback(),抛出异常
  • getFallback()
    • FALLBACK_SUCCESS:getFallback()成功,不抛异常
    • FALLBACK_FAILURE:getFallback()失败,抛异常
    • FALLBACK_REJECTION:调用getFallback()的线程数超量,抛异常

五、Metrics storage and Dashboard

仅仅记录hystrix1.5.0及其后续版本,之前的版本的数据结构不一样。

时间: 2024-10-05 21:08:57

服务容错保护断路器Hystrix之五:配置的相关文章

服务容错保护断路器Hystrix之四:turbine集群监控

turbine 英[?t?:ba?n] n. 汽轮机; 涡轮机; 透平机; 本文通过引入Turbine来聚合ribbon-consumer服务的监控信息,并输出给hystrix dashboard来进行展示. 先上部署拓扑图: 构建turbine项目: pom文件: <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.

Spring Cloud(四):服务容错保护 Hystrix【Finchley 版】

Spring Cloud(四):服务容错保护 Hystrix[Finchley 版] 发表于 2018-04-15 |  更新于 2018-05-07 | 分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况,这种现象被称为服务雪崩效应.为了应对服务雪崩,一种常见的做法是手动服务降级.而 Hystrix 的出现,给我们提供了另一种选择. Hystrix [h?st'r?ks] 的中文含义是 "豪猪",豪猪周身长满了刺,能保护自己不受天敌的伤害,代表了一种防御机制,这与 Hy

第四章 服务容错 - 引入hystrix

上一节,描述了服务发现.负载均衡以及服务之间的调用.到这里,加上第二节的服务注册,整个微服务的架构就已经搭建出来了,即功能性需求就完成了.从本节开始的记录其实全部都是非功能性需求. 一.集群容错 技术选型:hystrix.(就是上图中熔断器) 熔断的作用: 第一个作用: 假设有两台服务器server1(假设可以处理的请求阈值是1W请求)和server2,在server1上注册了三个服务service1.service2.service3,在server2上注册了一个服务service4,假设se

Spring Cloud Hystrix - 服务容错

服务容错和Hystrix 在微服务架构中,由于某个服务的不可用导致一系列的服务崩溃,被称之为雪崩效应.所以防御服务的雪崩效应是必不可少的,在Spring Cloud中防雪崩的利器就是Hystrix,Spring Cloud Hystri是基于Netflix Hystrix实现的.Hystrix的目标在于通过控制那些访问远程系统.服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力.Hystrix 具备服务降级.服务容错.服务熔断.线程和信号隔离.请求缓存.请求合并以及服务监控等强大功能.

SpringCloud+Hystrix服务容错

Netflix Hystrix - 应对复杂分布式系统中的延时和故障容错 +应用场景 分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应. 为了应对服务雪崩, 一种常见的做法是手动服务降级. 而Hystrix的出现,给我们提供了另一种选择 Hystrix的内部处理逻辑构建Hystrix的Command对象, 调用执行方法. Hystrix检查当前服务的熔断器开关是否开启, 若开启, 则执行降级服务getFallback方法. 若熔断器开关关闭, 则Hy

SpringCould-------使用Hystrix 实现断路器进行服务容错保护

消费: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelV

Hystrix服务容错处理(一)

在微服务架构中存在多个可直接调用的服务,这些服务若在调用时出现故障会导致连锁效应,也就是可能会让整个系统变得不可用,这种情况我们称之为服务雪崩效应. 如何避免服务雪崩效应?通过Hystrix就能够解决. 1.Hystrix Hystrix是Netflix针对微服务分布式系统采用的熔断保护中间件, 相当于电路中的保险 丝.在微服务架构下,很多服务都相互依赖,如果不能对依赖的服务进行隔离,那么服务 本身也有可能发生故障, Hystrix通过Hystrix Command对调用进行隔离, 这样可以阻止

Spring Cloud 八:服务容错保护(Hystrix断路器)【Dalston版】

断路器 断路器模式源于Martin Fowler的Circuit Breaker一文."断路器"本身是一种开关装置,用于在电路上保护线路过载,当线路中有电器发生短路时,"断路器"能够及时的切断故障电路,防止发生过载.发热.甚至起火等严重后果. 在分布式架构中,断路器模式的作用也是类似的,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),直接切断原来的主逻辑调用.但是,在Hystrix中的断路器除了切断主逻辑的功能之外,还有更复

SpringCloud系列七:Hystrix 熔断机制(Hystrix基本配置、服务降级、HystrixDashboard服务监控、Turbine聚合监控)

1.概念:Hystrix 熔断机制 2.具体内容 所谓的熔断机制和日常生活中见到电路保险丝是非常相似的,当出现了问题之后,保险丝会自动烧断,以保护我们的电器, 那么如果换到了程序之中呢? 当现在服务的提供方出现了问题之后整个的程序将出现错误的信息显示,而这个时候如果不想出现这样的错误信息,而希望替换为一个错误时的内容. 一个服务挂了后续的服务跟着不能用了,这就是雪崩效应 对于熔断技术的实现需要考虑以下几种情况: · 出现错误之后可以 fallback 错误的处理信息: · 如果要结合 Feign