09 | 雪崩（一）：熔断，让故障自适应地恢复

由于单点过载导致单点机器故障，为了避免全局故障引入了熔断机制。一台机器熔断了，流量打到其他机器上，也会触发其他机器熔断机制，最后还不是整个系统对外不可用。和雪崩有啥区别呢？

老师 如果有两个相同的服务接口，因其保障等级，性能，可用性都不同，是不是将他们分开部署比较合适。同时也避免了雪崩发生。

根据基准环境下对接口的压测数据，提前设定一个阈值，如果队列中的等待数量大于这个数字，就简单认为是过载了。

请求在队列中的平均等待时间这个指标 -其中的队列是指请求方中准备请求接口的请求么？这个队列是由什么维护的？是tomcat么？ 一般怎么计算这个平均等待时间？

请教老师两个问题： Q1： “在熔断机制的模式下，服务调用方需要为每一个调用对象，可以是服务、实例和接口，维护一个状态机，在这个状态机中有三种状态：”根据这句话，需要具体的服务来维护状态机，这不合适吧。如果是这样，业务代码岂不是要写很多代码来描述被调用对象？应该是熔断器维护吧。 Q2： 粒度控制部分： A “熔断的敏感度高”，敏感度怎么理解？ B “如果熔断器的阈值大于 10 %，那么将。。。。但是这个结果明显不是我们期待的。”，这段话想说明什么？ 是不是想说“所以，熔断器的阈值不能大于 10 %”

在断开状态下，会启动一个超时计时器，当计时器超时后，状态切换到半打开状态。什么意思啊

我在《Native Cloud Go》这本书上看到的熔断简单示例，Go 语言实现的，大家可以参考一下 type Circuit func(ctx context.Context) (string, error) func Breaker(circuit Circuit, failerThreshold int) Circuit { var ( consecutiveFailers int lastAttempt = time.Now() mu sync.RWMutex ) return func(ctx context.Context) (string, error) { mu.RLock() d := consecutiveFailers - failerThreshold if d >= 0 { // 重新尝试的时间点，以上一次尝试的时间点为基础 shouldRetryAt := lastAttempt.Add(time.Second * 2 << d) // exponential backoff algorithm if shouldRetryAt.After(time.Now()) { mu.RUnlock() return "", errors.New("service is unreachable") } } mu.RUnlock() resp, err := circuit(ctx) mu.Lock() defer mu.Unlock() lastAttempt = time.Now() if err != nil { consecutiveFailers++ return "", err } consecutiveFailers = 0 // reset failures counter return resp, nil } }

可否再介绍下业界先进的实现熔断机制的中间件？

答题 1.每次请求带上健康检测请求，实时获取服务端资源使用情况。 高并发场景无效，请求本身都返回不了，更别说追加的健康检测了。 疑问 2.实例接口的熔断，与rpc的故障转移，在作用上存在重复。仔细想想似乎熔断来做更合适。如此一来rpc应该只关注服务是否存活的场景（更新路由列表），而不是接口是否有故障。不知栏主怎么看？