假设准备用响应时间来作为指标，可以这么回答，关键词是持续超过阈值
为了保障微服务的可用性，在核心服务里接入了熔断。针对不同的服务，设计了不同的微服务熔断策略。
比如最简单的熔断就是根据响应时间进行，当响应时间超过阈值一段时间之后就会触发熔断。我一般会根据业务情况来选择这个阈值，例如产品要求响应时间是1秒，就会把阈值设定在1.2秒。如果响应时间超过1.2秒，并且持续三十秒，就会触发熔断。在触发熔断的情况下，新请求会被拒绝，而已有的请求会被继续处理，直到服务恢复正常。
- 阈值怎么确定？根据观测到的响应时间数据来决定
- 持续三十秒是如何计算出来的？基于个人经验，解释一下过长或过短的弊端
- 为什么多了0.2秒？留了余地，防止偶发性的响应时间变长的情况
- 怎么判断服务已经恢复正常了？可以回答等到一段固定的时间，然后尝试逐渐放开流量
微创新的方案，关键词是缓存崩溃。
一个接口并发很高，对缓存依赖也很严重，所以熔断策略就是如果缓存不可用，比如Redis崩溃了，就会触发熔断。因为如果不熔断的话，请求会因为Redis崩溃全部落在MySQL上，基本上会压垮MySQL。
在触发熔断后，会额外开辟一个协程，持续不断地ping Redis
这里用 Redis 来作为例子，可以将 Redis 替换为 MemCache 之类的，甚至你还可以将缓存替换成你业务上任何一个关键的第三方依赖。
这里还留了一些可以引导的点
- 缓存问题：在这里提到了Redis失效，这种情况类似于缓存雪崩，很自然地就可以把话题引导到如何处理缓存击穿、穿透、雪崩这些经典问题上
- 高可用MySQL：使用熔断来保护MySQL，类似地，也可以考虑用限流来保护MySQL
最后我提到了退出熔断状态，如果面试官了解抖动问题，那么他就肯定会追问“你是一次性放开全部流量吗？”，那么你就可以阐述抖动的问题，然后总结一下。
我这种逐步放开流量的方案其实还是有缺陷的，还有一些更加高级的做法，但是需要负载均衡来配合。
