面试官：高并发场景下，如何设计一个好的熔断策略？
在你能够回答下面这些问题的时候，你也就能回答这个面试题了：
1：什么是熔断？
2：如何精准判断一个服务”快没气了“，要触发熔断？有哪些指标？
3：熔断后，如何判断它“又有气了”，要恢复服务？怎么恢复？如何防止“抖动”？
1.什么是熔断？
我们经常把“熔断、限流、降级”放一块。而熔断是作为微服务系统可用性保障的关键一环，你不仅需要知道它是什么，而且还需要把它说的清楚。
说直白点：微服务节点因为负载过高、程序bug、宕机或升级等原因变得不可用或响应缓慢的时候，为了防止出现服务之间的雪崩效应，所以选择了“弃车保帅”直接让这个服务节点在一定时间内拒绝接受所有请求，从而让服务端“喘口气”。这就是熔断。你想，你的一个服务请求量突然急剧升高，cpu直接飙到100%了，我们先不管是为什么而飙到这么高的，那如果我们不解决的话，那这个服务节点肯定就会被搞崩溃，如果这个时候其它服务依赖这个已经崩溃的服务，但是又得不到响应，那么这些调用线程就会在队列里面阻塞住，一旦线程满了，那这个本来没有问题的服务就无法正常被请求了。那微服务之间又会相互调用，这不就会导致整个微服务变得不可用了嘛？那可亏大了。
所以这个时候，熔断就起到关键作用了，我直接让你拒绝接收几乎一切请求，那另外的节点一看，”哎，居然不让我调用？那好吧我就不调用了。“这就是保障了微服务的高可用。
2.如何精准判断一个服务”快没气了“，要触发熔断？有哪些指标？
通常来说，判断一个服务是不是快没气了，我们需要用一些指标去衡量一个服务的“健康度”。常用的指标是：响应时间和错误率。
不管哪种指标，都是需要达到相应的阈值后才开始后续工作的。
那阈值该如何设定呢？达到阈值后我直接给服务熔断吗？还是过一段时间熔断呢？
关于阈值的设定，需要考虑实际业务需求和情况，并不是一概而论，也没有标准答案，都是不断尝试而选出的。首先我们来看一下响应时间这个指标。比如你希望一个服务在1秒内能处理绝大多数的请求，而它也确确实实做到了，那么这个响应时间就可以设为1.2秒1.3秒，也就是说这个阈值可以比正常响应时间多出来个百分之20到百分之50左右。那么比如说有一个请求就达到了这个阈值了，那你就立即出发熔断了吗？显然我们不这样做，道理也很简单，如果一有请求超过阈值，就熔断，那如果是因为网络抖动等问题你把熔断了，那这不是胡闹嘛。所以说，要求指标持续一段时间超过阈值后，才发生熔断。那这一段时间又该如何设定呢？这一般需要根据经验来判断了，过长不行：服务都快死了你还不熔断？？？过短也不行：会导致熔断和恢复之间频繁切换。那一般呢你可以设成1分钟或者2分钟，然后再根据业务的实际表现而不断去调节。
3.熔断后，如何判断它“又有气了”，要恢复服务？怎么恢复？如何防止“抖动”？有没有更厉害的方案？
一个服务因为流量过高而处理不完导致熔断了，那在这段时间内，积压的请求处理完了，理论上我们就应该对它进行恢复，让它从新开始接收请求。
那么大多数默认策略是：熔断触发后，等待一个固定时间窗口，比如1分钟，然后直接恢复服务，让100%流量又打过去了，那这就会导致“抖动”，服务在熔断和正常直接来回切换。
如何解决呢？我们可以采用半开的方式，先开发10%的请求，之后20%，一步步往上调，最终到100%。这种显然是比较好的方案。但还有更好的吗？有！回答前面的思路已经足以应对面试了，但你想让面试官对你刮目相看，就需要回答这个亮点方案了：客户端和服务端联动熔断。
