一个服务熔断之后要考虑恢复，比如说如果我们判断一个服务响应时间过长，进入了熔断状态。那么十分钟过后，已接收的请求都已经被处理完了，即服务恢复正常了，那么他就要退出熔断状态，继续接收新请求。

因此在触发熔断之后，就要考虑检测服务是否已经恢复正常。
大多数的微服务框架都是触发熔断之后保持一段时间，比如说一分钟，一分钟之后就认为服务已经恢复正常，继续处理新请求。

抖动就是服务频繁地在正常 - 熔断两个状态之间切换。
引起抖动的原因是多样的，比如前面提到的一旦超过阈值就进入熔断状态，或者我们这里说的恢复策略不当也会引起抖动。再比如刚刚提到的“一分钟后就认为服务已经恢复正常，继续处理新请求”就容易引发抖动问题。
如果熔断本身是高并发引起的，在一分钟后，并发依旧很高，这时候一旦直接恢复正常，然后高并发的流量打过来，服务是不是又会触发熔断

而要解决这个抖动问题，就需要在恢复之后控制住流量，比如按照10%、20%、30%……逐步递增，而不是立刻恢复100%的流量

显然这种做法还是不够好，因为在这种逐步放开流量的措施下，依旧有请求因为熔断不会被处理。那么一个自然的想法就是，能不能让客户端来控制这个流量？简单来说就是服务端触发熔断之后，客户端就直接不再请求这个节点了，而是换一个节点。等到恢复了之后，客户端再逐步对这个节点放开流量