略难的题，校招不太可能遇到，在社招的中级工程师以上的面试岗位中会有可能遇到。
在回答这个问题的时候，可以通过强调选取指标要避免使用单一指标，应该使用复合指标来获得竞争优势。而后可以深入讨论选择指标本质上是为了回答如何衡量服务是否健康这一个问题，而这个问题可以认为是服务治理中的一个核心问题
略难的题。在社招中有可能遇到，尤其是中级工程师以上的岗位。
你可以先罗列单一的指标，而后强调单一的指标的局限性，从而得出最终的结论：复合指标更加能够反应系统的负载。最终装逼还是要注意指出不管什么指标都难准确衡量系统状态，这也是为啥我们各种服务治理搞来搞去都会出现服务崩溃的情况。
略难的题，难在你得有很丰富的实战经验才能总结出来这些因素，市面上没啥八股文或者博客会讨论这个问题。
回答这个问题的时候，可以先罗列选择指标的核心因素，而后深入讨论如何综合使用这些指标，设计一个能够综合判定服务状态的算法。
简单题，在校招和初级工程师面试中比较常见。
在这个问题之下，你可以深入讨论引入半开启状态的原因，从而赢得竞争优势。
略难的题，一般来说只会在社招中出现，而且是看你有一定服务治理基础才会考察。不然的话，没有什么服务治理经验的肯定回答不上来。
这个题倒不是难在状态转换以及转换条件，而是难在注意事项。你差不多能把各种注意事项说清楚，而后总结拔高这些所有的注意事项，其实都源自一个问题：我怎么知道这个服务健康还是不健康，一般的面试官是没这个见识的。
简单题，在深入讨论熔断的时候就有可能遇到，在校招和初级工程师中有可能遇到。
在这个问题之下，你要抽象拔高这种半开设计的技术手段，它可以被看做是一种通用的规避系统震荡和系统过载的手段，只要是有流量切换过程，都可以考虑采用类似的设计。
简单题，在微服务话题下很常见。在校招和初级工程中有可能遇到，一般高端的面试不太会讨论这种简单的问题。
在这个问题之下，最佳装逼策略就是列举一些自己使用过熔断的具体场景，最好是有一些花里胡哨的熔断场景，显得你对熔断有很深刻的理解。
在这个问题之下，刷亮点有两个策略。第一个策略是谈及自己使用过的熔断案例，最好是项目经历中的案例，而后将话题引导过去你准备面试项目上；第二个策略是讨论熔断、降级、限流三者的本质，也就是它们其实是一回事。
简单题，在校招和初级工程师中会遇到，高端岗位不太可能出现这种基础题。
在这个问题之下，最好的刷亮点方式就是举例子，阐述自己曾经使用过的熔断技术。
简单题。在微服务相关的面试下非常高频，校招和初中级工程师面试中很常见。
在这个问题之下，你可以深入讨论为什么会引入半开启状态，并且进一步揭示出熔断、限流、降级三者的联系，指出它们本质上是一样的，从而赢得竞争优势。
略难的题，这也是一个需要实践经验才能回答好的问题，在校招和初级工程师的面试中不太可能遇到。
在这个问题之下，要注意强调因为业务场景不同，所以在设计熔断机制的时候，要针对业务特性来筛选出来对业务很重要的指标。
略难的题，理论上来说校招是不应该问这个问题，因为他们没有经验。但是实际校招和初中级工程师面试中都有可能遇到。
大部人人在实践中其实都只是依据经验来随便设置一个阈值，但是在面试中就不能这么回答。
你可以通过深入讨论各种场景和限制下，如何设置一个合理的阈值，从而赢得竞争优势。
简单题，在讨论熔断的时候有可能问到，在校招和初中级工程师面试中有可能问到。
坦白说，触发熔断之后能做的事情，和被限流的请求比起来，能玩的花活还是要少一些的。毕竟熔断讲究的是快速失败，防止雪崩。
在这个问题之下，你可以用动态调整权重的负载均衡算法来刷亮点，因为这个算法可以针对触发熔断的服务节点进行特殊处理。
简单题，在讨论到熔断的时候有可能遇到，校招或者初中级岗位面试有可能遇到。
这个问题和开启状态的比起来，就是请求分成了两类，正常处理的和拒绝的。因此可以通过讨论怎么平滑控制两类请求的比率来刷亮点，大部分的熔断器的设计和实现都没有考虑这一点。
简单题，在校招和初中级工程师面试中都有可能遇到。
在这个问题之下，你可以结合实践谈谈自己用过的熔断策略，引导话题，刷出亮点。
略难的题。这个难是指面试不好回答，也是指实践中就很难解决。一般出现在社招中，校招不太会问，因为校招生没经验。
在这个问题之下，要抽象出一个最终的结论：即不管怎么设计、优化熔断策略，最终都难以避免出现漏判、误判的问题。而这和负载均衡难以彻底解决偶发性负载不均衡问题是一样的。
在这个问题之下，最佳刷亮点策略是谈及自己使用过的熔断案例，最好是项目经历中的案例，而后将话题引导过去你准备面试项目上。
简单题，在校招和社招都有可能遇到。
其实一句话就能说清楚：熔断中断了调用链路，链路都没了还有个屁的雪崩效应和级联故障了。如果要刷亮点，你可以对比降级和限流，强调熔断解决这两个问题的效果最好。
简单题，校招和社招中都很常见。
这个题目本质上就是考察你是否知道半开启这个状态，知不知道要避免抖动的问题。你可以讨论你在别的地方也用过类似的思想，避免了系统震荡或者系统过载的问题。
简单题，在校招中不太会遇到，社招中可能遇到。
在这个问题之下，其实有一个非常好回答的点，就是讨论熔断中难以处理的漏判和误判问题。当然，你也可以根据自己的体会来刷亮点。
简单题，在校招和社招里面都有可能遇到。
在这个问题之下，最好的还是列举自己在微服务架构下用的熔断的案例，从而将话题引导到自己的项目经历上。
略难的题，一般你得有使用经验才能意识到熔断的负面影响，而后去琢磨怎么改进。主要出现在社招中。
略难的题，你得在高并发环境下用过才有可能遇到这些问题，一般出现在社招中，校招不常见。
其实很多解决方案都是在低并发场景下没有任何问题，但是在高并发环境下就会有问题。尤其是各种不起眼的资源消耗，在高并发环境下就蜕变成为一个不能容忍的资源开销。
简单题，校招和社招都有可能遇到。
你要刷亮点，就还是要站在一个抽象的故障处理三步曲的角度去，统一描述熔断、限流和降级。
简单题，在校招和社招中都有可能遇到。
你可以站在故障三步曲的角度深入讨论这两者的区别和联系。从本质上来说，熔断、限流和降级并没有本质的去呗。
你可以站在故障三步曲的角度，深入讨论三者的区别的联系。从本质上来说，三者并没多少区别。
