在使用E版本的Spring Cloud Netflix Zuul内置的Ribbon重试功能时，发现Ribbon有一个很精妙的特性：
如果某个服务的某个实例经常需要重试，Ribbon则会在自己维护的一个缓存（serverStatsCache）里将其临时标记为不可用（isCircuitBreakerTripped），后续的所有请求都不会到达该服务实例，直到30（maxCircuitTrippedTimeout的默认值）秒之后，才会放一个请求再次去请求该服务实例。
这其实是Ribbon新增的负载均衡策略之一：AvailabilityFilteringRule（可用性过滤）
—————————————————————————————————————————————————————————————————
———————————————分割线—————以下是一些简单的代码跟踪分析—————观看帮助：截图不是很重要，重要的是文字描述————
—————————————————————————————————————————————————————————————————
当使用Spring Cloud F版本的Gateway的重试功能时，发现并没有该策略，愈发对其感兴趣，想知道如何实现的，索性DEBUG跟着断点走了一百下。。。。在Zuul项目中跟代码分析的思路如下：
0、创建一个spring-cloud-starter-netflix-zuul的项目，和eureka、两个服务，其中一个服务处理时间较长，能触发Ribbon的“熔断”。
1、第一个想到的就是通过日志看一看Ribbon在重试失败的时候做了什么，要看日志当然要打开DEBUG日志级别，在application.yml配置文件中添加如下：
logging:
level:
root: debug
2、清理所有不相干的日志，发现发送HTTP请求的时候走的是RetryTemplate的doExeccute方法，反复debug几遍，发现其中的context在执行到以下代码时忽然有了服务实例信息：
这是一个非常关键的线索，于是重新debug一路跟到给context的serviceInstance赋值的地方
继续跟
上图第56行可以看到赋值，第54行才是选择服务实例，继续
接着：
上图是我改后的源码，做了一些实验，发现当某个服务实例总是触发超时重试后，服务列表经过predicate.getEligibleServers(list,key)方法会把该服务实例给过滤掉。继续跟73行代码
中间略去几张截图，直到跟到
其中的apply方法对服务实例列表中的每个实例进行了过滤，继续跟到其实现
重点来了，用来判断服务实例可不可用的有两个Predicate，其中第二个AvailabilityPredicate就是我们的重点，跟到第二个类的apply方法：
发现总是超时的服务实例，其熔断已经打开，而73行的
stats.getSingleServerStat(input.getServer())
则是整个Ribbon熔断的关键，
通过上图的变量名：serverStatsCache我们就能看明白，这个变量里保存着服务实例的状态，
进一步查看ServerStats中的细节，
是否熔断的判断规则是最后一次触发熔断加上30秒（如下图），和当前时间对比
那么上一次熔断的时间是什么时候设置的呢？
在该方法被调用的时候，至于该方法什么时候被调用的：
上边五张图对其调用时机进行了展示，简单来说就是在发生
java.net.SocketTimeoutException: Read timed out
异常的时候。
到此分析完毕。
分析完后百度上搜一下ServerStats类中的关键字，如
niws.loadbalancer.default.circuitTripMaxTimeoutSeconds
可以看到对Ribbon已经有了很多优秀而系统的源码分析，有时间可以读一下进一步提高。
本文旨在帮助大家分析Ribbon重试和自带熔断机制，并提供一种源码分析的思路，希望对同行有所帮助。
（完毕）