熔断在微服务架构里面是指当前微服务本身出现问题时,会拒绝新的请求,直到微服务恢复
熔断给了服务端恢复的机会,比如如果CPU使用率已经100%了,服务端因此触发了熔断,那么拒绝了新的请求之后,服务端的CPU使用率就会在一段时间内降到100%以内。
提炼出两个点进行讨论
- 怎么判断微服务出现了问题
- 怎么知道微服务恢复了
类似在负载均衡里讨论的动态算法,本质上也是要求自己的业务来选择一些指标,代表这个服务器的健康程度。比如说一般可以考虑使用响应时间、错误率。
比如我们把响应时间作为指标,那么响应时间超过多少应该触发熔断,是根据业务来决定的。比如如果业务对响应时间的要求在1秒以内,那么你的阈值就可以设定在1秒,或是稍高一点,留点容错的余地。
假如产品经理没跟你说这个业务对响应时间的要求,就可以根据整体响应时间设定一个阈值,原则上
要求响应时间超过一段时间之后才触发熔断,一个原因是响应时间可能偶发性地突然增长;另一个原因是防止抖动。
一段时间的长度很大程度上依赖个人经验,如果时间过短,可能会频繁触发熔断,然后又恢复,再熔断,再恢复……反过来,如果时间过长,那就可能导致该触发熔断的时候迟迟没有触发
可以根据经验设定一个值,比如三十秒或一分钟