基础
熔断在微服务架构里面是指当微服务本身出现问题的时候，它会拒绝新的请求，直到微服务恢复。
判断服务健康状态
本质上也是要求你根据自己的业务来选择一些指标，代表这个服务器的健康程度。比如说一般可以考虑使用响应时间、错误率。
不管选择什么指标，都要考虑两个因素：一是阈值如何选择；二是超过阈值之后，要不要持续一段时间才触发熔断。
要求响应时间超过一段时间之后才触发熔断。
你可以根据经验来设定一个值，比如说三十秒或者一分钟。
服务恢复正常
这方面微服务框架都做得比较差。大多数情况下就是触发熔断之后保持一段时间，比如说一分钟，一分钟之后就认为服务已经恢复正常，继续处理新请求。
需要在恢复之后控制住流量。比如说按照 10%、20%、30%……逐步递增，而不是立刻恢复 100% 的流量。
能不能让客户端来控制这个流量？简单来说就是服务端触发熔断之后，客户端就直接不再请求这个节点了，而是换一个节点。等到恢复了之后，客户端再逐步对这个节点放开流量。
亮点
假如说你准备用响应时间来作为指标，那么你可以这么回答，关键词是持续超过阈值。
为了保障微服务的可用性，我在我的核心服务里面接入了熔断。针对不同的服务，我设计了不同的微服务熔断策略。比如说最简单的熔断策略就是根据响应时间来进行。当响应时间超过阈值一段时间之后就会触发熔断。我一般会根据业务情况来选择这个阈值，例如，如果产品经理要求响应时间是 1s，那么我会把阈值设定在 1.2s。如果响应时间超过 1.2s，并且持续三十秒，就会触发熔断。在触发熔断的情况下，新请求会被拒绝，而已有的请求还是会被继续处理，直到服务恢复正常。
客户端控制流量
整体流程：
- 服务端在触发熔断的时候，会返回一个代表熔断的错误。
- 客户端在收到这个错误之后，就会把这个服务端节点暂时挪出可用节点列表。后续所有的新请求都不会再打到这个触发了熔断的服务端节点上了。
- 客户端在等待一段时间后，逐步放开流量。
- 如果服务端正常处理了新来的请求，那么客户端就加大流量。
- 如果服务端再次返回了熔断响应，那么客户端就会再一次将这个节点挪出可用列表。
- 如此循环，直到服务端完全恢复正常，客户端也正常发送请求到该服务端节点。
此文章为9月Day23学习笔记，内容来源于极客时间《后端工程师的高阶面经》
