使用Hystrix实现自动降级与依赖隔离[微服务]

左手的ㄟ右手 2022-04-21 23:50 205阅读 0赞

转载：[https://www.jianshu.com/p/138f92aa83dc][https_www.jianshu.com_p_138f92aa83dc]

这篇文章是记录了自己的一次集成Hystrix的经验，原本写在公司内部wiki里，所以里面有一些内容为了避免重复，直接引用了其他同事的wiki，而发布到外网，这部分就不能直接引用了，因此可能不会太完整，后续会补充进去。

# 1.背景 #

目前对于一些非核心操作，如增减库存后保存操作日志 发送异步消息时（具体业务流程），一旦出现MQ服务异常时，会导致接口响应超时，因此可以考虑对非核心操作引入服务降级、服务隔离。

# 2.Hystrix说明 #

官方文档 [https://github.com/Netflix/Hystrix/wiki]

> hystrix是netflix开源的一个容灾框架，解决当外部依赖故障时拖垮业务系统、甚至引起雪崩的问题。

## 2.1为什么需要Hystrix? ##

在大中型分布式系统中，通常系统很多依赖(HTTP,hession,Netty,Dubbo等)，在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等。

当依赖阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性，在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

例如:一个依赖30个SOA服务的系统,每个服务99.99%可用。
    99.99%的30次方 ≈ 99.7%
    0.3% 意味着一亿次请求 会有 3,000,00次失败
    换算成时间大约每月有2个小时服务不稳定.
    随着服务依赖数量的变多，服务不稳定的概率会成指数性提高.

解决问题方案:对依赖做隔离。

## 2.2Hystrix设计理念 ##

想要知道如何使用，必须先明白其核心设计理念，Hystrix基于命令模式，通过UML图先直观的认识一下这一设计模式

![600][]

image.png

可见，Command是在Receiver和Invoker之间添加的中间层，Command实现了对Receiver的封装。那么Hystrix的应用场景如何与上图对应呢？

API既可以是Invoker又可以是reciever，通过继承Hystrix核心类HystrixCommand来封装这些API（例如，远程接口调用，数据库查询之类可能会产生延时的操作）。就可以为API提供弹性保护了。

## 2.3Hystrix如何解决依赖隔离 ##

*  1:Hystrix使用命令模式HystrixCommand(Command)包装依赖调用逻辑，每个命令在单独线程中/信号授权下执行。
 *  2:可配置依赖调用超时时间,超时时间一般设为比99.5%平均时间略高即可.当调用超时时，直接返回或执行fallback逻辑。
 *  3:为每个依赖提供一个小的线程池（或信号），如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。
 *  4:依赖调用结果分:成功，失败（抛出异常），超时，线程拒绝，短路。 请求失败(异常，拒绝，超时，短路)时执行fallback(降级)逻辑。
 *  5:提供熔断器组件,可以自动运行或手动调用,停止当前依赖一段时间(10秒)，熔断器默认错误率阈值为50%,超过将自动运行。
 *  6:提供近实时依赖的统计和监控

## 2.4Hystrix流程结构解析 ##

![1000][]

image.png

流程说明:
    1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.
    2:执行execute()/queue做同步或异步调用.
    3:判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤.
    4:判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续步骤.
    5:调用HystrixCommand的run方法.运行依赖逻辑
    5a:依赖逻辑调用超时,进入步骤8.
    6:判断逻辑是否调用成功
    6a:返回成功调用结果
    6b:调用出错，进入步骤8.
    7:计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.
    8:getFallback()降级逻辑.
      以下四种情况将触发getFallback调用：
     (1):run()方法抛出非HystrixBadRequestException异常。
     (2):run()方法调用超时
     (3):熔断器开启拦截调用
     (4):线程池/队列/信号量是否跑满
    8a:没有实现getFallback的Command将直接抛出异常
    8b:fallback降级逻辑调用成功直接返回
    8c:降级逻辑调用失败抛出异常
    9:返回执行成功结果

## 2.5熔断器:Circuit Breaker ##

每个熔断器默认维护10个bucket,每秒一个bucket,每个bucket记录成功,失败,超时,拒绝的状态，

默认错误超过50%且10秒内超过20个请求进行中断拦截.

![1000 1][]

image.png

## 2.6Hystrix隔离分析 ##

Hystrix隔离方式采用线程/信号的方式,通过隔离限制依赖的并发量和阻塞扩散.

*  (1)线程隔离  
    把执行依赖代码的线程与请求线程(如:jetty线程)分离，请求线程可以自由控制离开的时间(异步过程)。  
    通过线程池大小可以控制并发量，当线程池饱和时可以提前拒绝服务,防止依赖问题扩散。  
    线上建议线程池不要设置过大，否则大量堵塞线程有可能会拖慢服务器。
 *  (2)线程隔离的优缺点
    
     *  线程隔离的优点:
        
         *   
         *   
         *   
     *  线程隔离的缺点:
        
         *   
         *   
     *  NOTE: Netflix公司内部认为线程隔离开销足够小，不会造成重大的成本或性能的影响。
     *  Netflix 内部API 每天100亿的HystrixCommand依赖请求使用线程隔，每个应用大约40多个线程池，每个线程池大约5-20个线程。
 *  (3)信号隔离
    
     *  信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请）,
     *  如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离,降低开销.
     *  信号量的大小可以动态调整, 线程池大小不可以.

> 线程隔离与信号隔离区别如下图:

![656][]

image.png

# 3.接入方式 #

本文会重点介绍基于服务化项目（thrift服务化项目）的接入方式。

## 3.1添加hystrix依赖 ##

> 关于版本问题：由于不同版本Compile Dependencies不同，在使用过程中可以针对具体情况修改版本，具体依赖关系[http://mvnrepository.com/artifact/com.netflix.hystrix/hystrix-javanica][http_mvnrepository.com_artifact_com.netflix.hystrix_hystrix-javanica]

<hystrix-version>1.4.22</hystrix-version>
      
    <dependency>
        <groupId>com.netflix.hystrix</groupId>
        <artifactId>hystrix-core</artifactId>
        <version>${hystrix-version}</version>
    </dependency>
    <dependency>
        <groupId>com.netflix.hystrix</groupId>
        <artifactId>hystrix-metrics-event-stream</artifactId>
        <version>${hystrix-version}</version>
    </dependency>
    <dependency>
        <groupId>com.netflix.hystrix</groupId>
        <artifactId>hystrix-javanica</artifactId>
        <version>${hystrix-version}</version>
    </dependency>
    <dependency>
        <groupId>com.netflix.hystrix</groupId>
        <artifactId>hystrix-servo-metrics-publisher</artifactId>
        <version>${hystrix-version}</version>
    </dependency>
    <dependency>
        <groupId>com.meituan.service.us</groupId>
        <artifactId>hystrix-collector</artifactId>
        <version>1.0-SNAPSHOT</version>
    </dependency>

## 3.2引入Hystrix Aspect ##

application-context.xml文件中

<aop:aspectj-autoproxy/>
    <bean id="hystrixAspect" class="com.netflix.hystrix.contrib.javanica.aop.aspectj.HystrixCommandAspect"></bean>
    <context:component-scan base-package="com.***.***"/>
    <context:annotation-config/>

> 注意：

*  1）hystrixAspect的这两行配置一定要和下面的context:component-scan放在同一个文件
 *  2）Hystrix依赖的一些jar需要解决冲突问题，例如guava为15.0版本

## 3.3统计数据 ##

需要注册plugin，直接从plugin中获取统计数据

新增初始化Bean

import com.meituan.service.us.collector.notifier.CustomEventNotifier;
    import com.netflix.hystrix.contrib.servopublisher.HystrixServoMetricsPublisher;
    import com.netflix.hystrix.strategy.HystrixPlugins;
    import org.slf4j.Logger;
    import org.slf4j.LoggerFactory;
    import org.springframework.beans.factory.InitializingBean;
     
    /**
     * Created by gaoguangchao on 16/7/1.
     */
    public class HystrixMetricsInitializingBean {
        private static final Logger LOGGER = LoggerFactory.getLogger(HystrixMetricsInitializingBean.class);
     
        public void init() throws Exception {
            LOGGER.info("HystrixMetrics starting...");
            HystrixPlugins.getInstance().registerEventNotifier(CustomEventNotifier.getInstance());
            HystrixPlugins.getInstance().registerMetricsPublisher(HystrixServoMetricsPublisher.getInstance());
        }
    }

application-context.xml文件中

## 3.4添加注解 ##

本文使用同步执行方式，因此注解及方法实现都为同步方式，如果有异步执行、反应执行的需求，可以参考：官方注解说明\[[https://github.com/Netflix/Hystrix/tree/master/hystrix-contrib/hystrix-javanica\]][https_github.com_Netflix_Hystrix_tree_master_hystrix-contrib_hystrix-javanica]

@HystrixCommand(groupKey = "productStockOpLog", commandKey = "addProductStockOpLog", fallbackMethod = "addProductStockOpLogFallback",
            commandProperties = {
                    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "400"),//指定多久超时，单位毫秒。超时进fallback
                    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),//判断熔断的最少请求数，默认是10；只有在一个统计窗口内处理的请求数量达到这个阈值，才会进行熔断与否的判断
                    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "10"),//判断熔断的阈值，默认值50，表示在一个统计窗口内有50%的请求处理失败，会触发熔断
            }
    )
    public void addProductStockOpLog(Long sku_id, Object old_value, Object new_value) throws Exception {
        if (new_value != null && !new_value.equals(old_value)) {
            doAddOpLog(null, null, sku_id, null, ProductOpType.PRODUCT_STOCK, old_value != null ? String.valueOf(old_value) : null, String.valueOf(new_value), 0, "C端", null);
        }
    }
     
    public void addProductStockOpLogFallback(Long sku_id, Object old_value, Object new_value) throws Exception {
        LOGGER.warn("发送商品库存变更消息失败,进入Fallback,skuId:{},oldValue:{},newValue:{}", sku_id, old_value, new_value);
    }

示例：

@HystrixCommand(groupKey="UserGroup", commandKey = "GetUserByIdCommand"，
                    commandProperties = {
                        @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "100"),//指定多久超时，单位毫秒。超时进fallback
                        @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),//判断熔断的最少请求数，默认是10；只有在一个统计窗口内处理的请求数量达到这个阈值，才会进行熔断与否的判断
                        @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "10"),//判断熔断的阈值，默认值50，表示在一个统计窗口内有50%的请求处理失败，会触发熔断
                    },
                    threadPoolProperties = {
                            @HystrixProperty(name = "coreSize", value = "30"),
                            @HystrixProperty(name = "maxQueueSize", value = "101"),
                            @HystrixProperty(name = "keepAliveTimeMinutes", value = "2"),
                            @HystrixProperty(name = "queueSizeRejectionThreshold", value = "15"),
                            @HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "12"),
                            @HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds", value = "1440")
            })

说明：  
hystrix函数必须为public，fallback函数可以为private。两者需要返回值和参数相同 详情。

hystrix函数需要放在一个service中，并且，在类本身的其他函数中调用hystrix函数，是无法达到监控的目的的。

## 3.5参数配置 ##

<table> 
 <thead> 
  <tr> 
   <th>参数说明</th> 
   <th>值</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>groupKey</td> 
   <td>productStockOpLog</td> 
   <td>group标识，一个group使用一个线程池</td> 
  </tr> 
  <tr> 
   <td>commandKey</td> 
   <td>addProductStockOpLog</td> 
   <td>command标识</td> 
  </tr> 
  <tr> 
   <td>fallbackMethod</td> 
   <td>addProductStockOpLogFallback</td> 
   <td>fallback方法，两者需要返回值和参数相同</td> 
  </tr> 
  <tr> 
   <td>超时时间设置</td> 
   <td>400ms</td> 
   <td>执行策略，在THREAD模式下，达到超时时间，可以中断 For most circuits, you should try to set their timeout values close to the 99.5th percentile of a normal healthy system so they will cut off bad requests and not let them take up system resources or affect user behavior.</td> 
  </tr> 
  <tr> 
   <td>统计窗口（10s）内最少请求数</td> 
   <td>10</td> 
   <td>熔断策略</td> 
  </tr> 
  <tr> 
   <td>熔断多少秒后去尝试请求</td> 
   <td>5s</td> 
   <td>熔断策略，默认值</td> 
  </tr> 
  <tr> 
   <td>熔断阀值</td> 
   <td>10%</td> 
   <td>熔断策略：一个统计窗口内有10%的请求处理失败，会触发熔断</td> 
  </tr> 
  <tr> 
   <td>线程池coreSize</td> 
   <td>10</td> 
   <td>默认值（推荐值）.在当前项目中，需要做依赖隔离的方法为发送一条MQ消息，发送MQ消息方法的TP99耗时在1ms以下，近2周单机QPS最高值在18左右，经过灰度验证了午高峰后（当日QPS&gt;上周末QPS），ActiveThreads&lt;=2，rejected=0,经过压测后得出结论：线程池大小为10足以应对2000QPS，前提发送MQ消息时耗时正常（该部分为实际项目中的情况，在此不做详述）</td> 
  </tr> 
  <tr> 
   <td>线程池maxQueueSize</td> 
   <td>-1</td> 
   <td>即线程池队列为SynchronousQueue</td> 
  </tr> 
 </tbody> 
</table>

# 4.参数说明 #

其他参数可参见 [https://github.com/Netflix/Hystrix/wiki/Con][https_github.com_Netflix_Hystrix_wiki_Con]

<table> 
 <thead> 
  <tr> 
   <th>分类</th> 
   <th>参数</th> 
   <th>作用</th> 
   <th>默认值</th> 
   <th>备注</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>基本参数</td> 
   <td>groupKey</td> 
   <td>表示所属的group，一个group共用线程池</td> 
   <td>getClass().getSimpleName();</td> 
  </tr> 
  <tr> 
   <td>基本参数</td> 
   <td>commandKey</td> 
   <td>&nbsp;</td> 
   <td>当前执行方法名</td> 
  </tr> 
  <tr> 
   <td>Execution （ 控制HystrixCommand.run()的执行策略）</td> 
   <td>execution.isolation.strategy</td> 
   <td>隔离策略，有THREAD和SEMAPHORE THREAD</td> 
   <td>以下几种可以使用SEMAPHORE模式： 只想控制并发度 外部的方法已经做了线程隔离 调用的是本地方法或者可靠度非常高、耗时特别小的方法（如medis）</td> 
  </tr> 
  <tr> 
   <td>Execution</td> 
   <td>execution.isolation.thread.timeoutInMilliseconds</td> 
   <td>超时时间</td> 
   <td>1000ms</td> 
   <td>默认值：1000 在THREAD模式下，达到超时时间，可以中断 在SEMAPHORE模式下，会等待执行完成后，再去判断是否超时 设置标准： 有retry，99meantime+avg meantime 没有retry，99.5meantime</td> 
  </tr> 
  <tr> 
   <td>Execution</td> 
   <td>execution.timeout.enabled</td> 
   <td>是否打开超时</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>Execution</td> 
   <td>execution.isolation.thread.interruptOnTimeout</td> 
   <td>是否打开超时线程中断</td> 
   <td>true</td> 
   <td>THREAD模式有效</td> 
  </tr> 
  <tr> 
   <td>Execution</td> 
   <td>execution.isolation.semaphore.maxConcurrentRequests</td> 
   <td>信号量最大并发度</td> 
   <td>10</td> 
   <td>SEMAPHORE模式有效</td> 
  </tr> 
  <tr> 
   <td>Fallback （ 设置当fallback降级发生时的策略）</td> 
   <td>fallback.isolation.semaphore.maxConcurrentRequests</td> 
   <td>fallback最大并发度</td> 
   <td>10</td> 
  </tr> 
  <tr> 
   <td>Fallback</td> 
   <td>fallback.enabled</td> 
   <td>fallback是否可用</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>Circuit Breaker （配置熔断的策略）</td> 
   <td>circuitBreaker.enabled</td> 
   <td>是否开启熔断</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>Circuit Breaker</td> 
   <td>circuitBreaker.requestVolumeThreshold</td> 
   <td>一个统计窗口内熔断触发的最小个数/10s</td> 
   <td>20</td> 
  </tr> 
  <tr> 
   <td>Circuit Breaker</td> 
   <td>circuitBreaker.sleepWindowInMilliseconds</td> 
   <td>熔断多少秒后去尝试请求</td> 
   <td>5000ms</td> 
  </tr> 
  <tr> 
   <td>Circuit Breaker</td> 
   <td>circuitBreaker.errorThresholdPercentage</td> 
   <td>失败率达到多少百分比后熔断</td> 
   <td>50</td> 
   <td>主要根据依赖重要性进行调整</td> 
  </tr> 
  <tr> 
   <td>Circuit Breaker</td> 
   <td>circuitBreaker.forceOpen</td> 
   <td>是否强制开启熔断</td> 
  </tr> 
  <tr> 
   <td>Circuit Breaker</td> 
   <td>circuitBreaker.forceClosed</td> 
   <td>是否强制关闭熔断</td> 
   <td>&nbsp;</td> 
   <td>如果是强依赖，应该设置为true</td> 
  </tr> 
  <tr> 
   <td>Metrics （设置关于HystrixCommand执行需要的统计信息）</td> 
   <td>metrics.rollingStats.timeInMilliseconds</td> 
   <td>设置统计滚动窗口的长度，以毫秒为单位。用于监控和熔断器。</td> 
   <td>10000</td> 
   <td>滚动窗口被分隔成桶(bucket)，并且进行滚动。 例如这个属性设置10s(10000)，一个桶是1s。</td> 
  </tr> 
  <tr> 
   <td>Metrics</td> 
   <td>metrics.rollingStats.numBuckets 设置统计窗口的桶数量</td> 
   <td>10</td> 
   <td>metrics.rollingStats.timeInMilliseconds必须能被这个值整除</td> 
  </tr> 
  <tr> 
   <td>Metrics</td> 
   <td>metrics.rollingPercentile.enabled</td> 
   <td>设置执行时间是否被跟踪，并且计算各个百分比，50%,90%等的时间</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>Metrics</td> 
   <td>metrics.rollingPercentile.timeInMilliseconds</td> 
   <td>设置执行时间在滚动窗口中保留时间，用来计算百分比</td> 
   <td>60000ms</td> 
  </tr> 
  <tr> 
   <td>Metrics</td> 
   <td>metrics.rollingPercentile.numBuckets</td> 
   <td>设置rollingPercentile窗口的桶数量</td> 
   <td>6</td> 
   <td>metrics.rollingPercentile.timeInMilliseconds必须能被这个值整除</td> 
  </tr> 
  <tr> 
   <td>Metrics</td> 
   <td>metrics.rollingPercentile.bucketSize</td> 
   <td>此属性设置每个桶保存的执行时间的最大值。</td> 
   <td>100</td> 
   <td>如果设置为100，但是有500次求情，则只会计算最近的100次</td> 
  </tr> 
  <tr> 
   <td>Metrics</td> 
   <td>metrics.healthSnapshot.intervalInMilliseconds</td> 
   <td>采样时间间隔</td> 
   <td>500</td> 
  </tr> 
  <tr> 
   <td>Request Context ( 设置HystrixCommand使用的HystrixRequestContext相关的属性)</td> 
   <td>requestCache.enabled</td> 
   <td>设置是否缓存请求，request-scope内缓存</td> 
   <td>true</td> 
  </tr> 
  <tr> 
   <td>Request Context</td> 
   <td>requestLog.enabled</td> 
   <td>设置HystrixCommand执行和事件是否打印到HystrixRequestLog中</td> 
   <td>&nbsp;</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>ThreadPool Properties(配置HystrixCommand使用的线程池的属性)</td> 
   <td>coreSize</td> 
   <td>设置线程池的core size,这是最大的并发执行数量。</td> 
   <td>10</td> 
   <td>设置标准：coreSize = requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room 大多数情况下默认的10个线程都是值得建议的</td> 
  </tr> 
  <tr> 
   <td>ThreadPool Properties</td> 
   <td>maxQueueSize</td> 
   <td>最大队列长度。设置BlockingQueue的最大长度</td> 
   <td>-1</td> 
   <td>默认值：-1 如果使用正数，队列将从SynchronousQueue改为LinkedBlockingQueue</td> 
  </tr> 
  <tr> 
   <td>ThreadPool Properties</td> 
   <td>queueSizeRejectionThreshold</td> 
   <td>设置拒绝请求的临界值</td> 
   <td>5</td> 
   <td>此属性不适用于maxQueueSize = - 1时 设置设个值的原因是maxQueueSize值运行时不能改变，我们可以通过修改这个变量动态修改允许排队的长度</td> 
  </tr> 
  <tr> 
   <td>ThreadPool Properties</td> 
   <td>keepAliveTimeMinutes</td> 
   <td>设置keep-live时间</td> 
   <td>1分钟</td> 
   <td>这个一般用不到因为默认corePoolSize和maxPoolSize是一样的。</td> 
  </tr> 
 </tbody> 
</table>

# 5.性能测试 #

## 5.1测试情况 ##

![1000 2][]

image.png

去除Cold状态的第一个异常点后，1-10测试场景的Hystrix平均耗时如上图所示， 可以得出结论：

1.  单个HystrixCommand的额外耗时基本稳定处于0.3ms左右，和线程池大小无关，和client数量无关
2.  hystrix的额外耗时和执行的HystrixCommand数量有关系，随着command数量增多，耗时增加，但是增量较小，没有比例关系
3.  App刚启动时，第一个请求耗时300+ms，随后请求的耗时降低至1ms以下；刚启动的一小段时间内耗时略大于Hot状态时耗时，总体不超过1ms

[https_www.jianshu.com_p_138f92aa83dc]: https://www.jianshu.com/p/138f92aa83dc
[600]: /images/20220422/169bf33f33da4fa98b3d253c9b78f7bd.png
[1000]: /images/20220422/940bdc33af874a99972cb1e0b32ccc68.png
[1000 1]: /images/20220422/92477294e7c64470bcd78d04498938b4.png
[656]: /images/20220422/b03d0b3a4dce463ab03c88044a189763.png
[http_mvnrepository.com_artifact_com.netflix.hystrix_hystrix-javanica]: https://link.jianshu.com/?t=http%3A%2F%2Fmvnrepository.com%2Fartifact%2Fcom.netflix.hystrix%2Fhystrix-javanica
[https_github.com_Netflix_Hystrix_tree_master_hystrix-contrib_hystrix-javanica]: https://link.jianshu.com/?t=https%3A%2F%2Fgithub.com%2FNetflix%2FHystrix%2Ftree%2Fmaster%2Fhystrix-contrib%2Fhystrix-javanica%255D
[https_github.com_Netflix_Hystrix_wiki_Con]: https://link.jianshu.com/?t=https%3A%2F%2Fgithub.com%2FNetflix%2FHystrix%2Fwiki%2FCon
[1000 2]: /images/20220422/f38db7d4975a4b819973a332ccd675cb.png