不吃辣👾2022-03-30由于单点过载导致单点机器故障，为了避免全局故障引入了熔断机制。一台机器熔断了，流量打到其他机器上，也会触发其他机器熔断机制，最后还不是整个系统对外不可用。和雪崩有啥区别呢？作者回复: 熔断后，请求会快速失败，不会将请求转发到其他节点的
共 2 条评论5- 不吃辣👾2022-04-07老师 如果有两个相同的服务接口，因其保障等级，性能，可用性都不同，是不是将他们分开部署比较合适。同时也避免了雪崩发生。
作者回复: 这个是可以的。 可用性是成本和收益之间的平衡。
1 - 墨龙2022-03-08根据基准环境下对接口的压测数据，提前设定一个阈值，如果队列中的等待数量大于这个数字，就简单认为是过载了。
作者回复: 这个方式可行 不过更好的指标是“等待时间”，“等待数量”在突发流量的时候，会出现过载，但是可能系统并没有过载
啊树2022-02-18请求在队列中的平均等待时间这个指标 -其中的队列是指请求方中准备请求接口的请求么？这个队列是由什么维护的？是tomcat么？ 一般怎么计算这个平均等待时间？作者回复: 这个是和实现方式相关的，如果内部实现是生产者消费者模型，可以通过埋点统计来实现，如果不是这种模型是不好统计的，对于这个问题，在“雪崩（四）”中还有进一步的讨论。
共 2 条评论
peter2022-02-16请教老师两个问题： Q1： “在熔断机制的模式下，服务调用方需要为每一个调用对象，可以是服务、实例和接口，维护一个状态机，在这个状态机中有三种状态：”根据这句话，需要具体的服务来维护状态机，这不合适吧。如果是这样，业务代码岂不是要写很多代码来描述被调用对象？应该是熔断器维护吧。 Q2： 粒度控制部分： A “熔断的敏感度高”，敏感度怎么理解？ B “如果熔断器的阈值大于 10 %，那么将。。。。但是这个结果明显不是我们期待的。”，这段话想说明什么？ 是不是想说“所以，熔断器的阈值不能大于 10 %”作者回复: Q1：你的理解是对的，前面就是描述在服务的调用方实现断路器的逻辑，熔断一般都是由框架来实现的。 Q2： A：熔断的敏感度高：可以这样来理解，假设熔断的粒度是服务，错误率超过 20% 就熔断，这个服务有非常多的实例和接口，如果一个接口异常了，但是其他的接口都是正常的，错误率就很难到 20%，也就不能触发熔断；如果粒度是一个实例的接口，阈值还是 20%，那么这个接口出现问题就能触发熔断了，敏感度高很多。 B：和 A 是同一个问题，是因为粒度粗，其他的接口是正常的，导致错误率很难道 10%。不是指熔断器的阈值不能大于 10 %。
- 小叶2022-02-16在断开状态下，会启动一个超时计时器，当计时器超时后，状态切换到半打开状态。什么意思啊
作者回复: 是指在断开状态下，因为所有的请求都会直接熔断，但是熔断的服务可能慢慢会好的，所以一次断开是一个比较小的时候，比较 60 秒，然后进入半打开状态，半打开状态的逻辑在文中有描述的，主要是确认后端服务是否恢复了。
上杉夏香2023-04-04 来自北京我在《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 } }展开
无情2022-06-23可否再介绍下业界先进的实现熔断机制的中间件？
Jxin2022-02-25答题 1.每次请求带上健康检测请求，实时获取服务端资源使用情况。 高并发场景无效，请求本身都返回不了，更别说追加的健康检测了。 疑问 2.实例接口的熔断，与rpc的故障转移，在作用上存在重复。仔细想想似乎熔断来做更合适。如此一来rpc应该只关注服务是否存活的场景（更新路由列表），而不是接口是否有故障。不知栏主怎么看？