一、什么是服务熔断？
熔断这一概念来源于电子工程中的断路器（Circuit Breaker）。
在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。
这种牺牲局部，保全整体的措施就叫做熔断。
如果不采取熔断措施，我们的系统会怎样呢？
我们来看一个栗子。
当前系统中有A，B，C三个服务，服务A是上游，服务B是中游，服务C是下游。
它们的调用链如下：
一旦下游服务C因某些原因变得不可用，积压了大量请求，服务B的请求线程也随之阻塞。线程资源逐渐耗尽，使得服务B也变得不可用。紧接着，服务 A也变为不可用，整个调用链路被拖垮。
像这种调用链路的连锁故障，叫做雪崩。
二、熔断机制实际应用
三个状态的转化关系如下图：
1、背景
针对所有二级及以下上游依赖服务提供熔断机制，保障商城整体可用行
2、名词解释
(1)断路器（Breaker）：
一种设计模式，在特定情况下，可以对即将执行一个或一组函数起到拦截作用，并直接返回预定结果。在服务熔断中主要用来判断上游服务是否可用，并决定是否进行调用
(2)断路器的三种状态
开启: 当调用上游服务持续发送异常并达到指定阈值，程序会将断路器置为此状态，此状态下代表上游服务不可用，断路器会拦截该服务的调用。
关闭：默认为此状态，代表上游服务可用，此状态下断路器不作为
半开：但熔断器处于开启状态达到重试时间之后，断路器会置为此状态，此状态下会对上游服务进行重试，成功，则重置为关闭状态。失败，则再次置为开启状态
3、实现方案
(1)基于切面实现，在Adapter层切入，优先级小于降级逻辑
(2)调用服务之前判断当前服务断路器的状态，开启则直接返回；半开或关闭则执行调用
(3)调用服务之后对结果进行断言，并进行数据分析，重置断路器的状态，写入共享内存
在worker进程的做法：
在自定义进程的做法：
4、进程职责划分
(1)worker进程：根据断路器状态判断是否请求上游服务；对请求数、失败数、重试数、成功数进行计数；
(2)管理进程：循环调用，分析当前时间段的数据，切换断路器状态；失败率上报；熔断、恢复通知发送；删除过期数据；
5、接入方式
theone(swoole)：
1.使用swoole\table共享内存存储数据，server启动之前初始化共享内存
2.添加自定义熔断管理进程
3.基于AOP理念，切入Adapter层(调用上游接口类)，在请求之前校验，在请求之后计数
mall-api(swoole+yii):
1.使用swoole\table共享内存存储数据，server启动之前初始化共享内存
2.添加自定义熔断管理进程
3.代码侵入至ApiRpcCall::beforeCoRequest和ApiRpcCall::afterCoRequest两个钩子函数中，实现熔断和计数
fpm模式:
非swoole模式，可以使用yac扩展实现请求计数
6、上报
(1)钉钉消息：当某个服务被熔断或恢复时，由当前worker进程异步发送通知到钉钉群组，开发人员可立即感知
(2)上报OPS：将某个服务的失败率(失败数/请求数)上报至ops，由管理进程处理，每分钟上报一次。可视化观察服务的可用性。
7、人工干预
(1)配置中心：当某个服务触发熔断时，可能不符合我们的预期，需要强制开启针对该服务的调用。更改商城配置中心的配置，在断路器执行开始时，判断该服务的配置判断是否继续熔断。
8、问题
(1)上游服务请求失败的判断标准
只处理请求超时和耗时较长的情况，不考虑httpCode和errCode
存在上游服务被限流，返回的错误状态码
(2)当前时间点的失败率如何计算
1)用前一分钟的失败率；即 04'30''请求失败，使用03'00''~03'59''的失败数/请求数作为失败率；（反应有延迟）
2)用当前分钟+前一分钟总合计算；即4'30''请求失败，使用4'00''4'30''的+03'00''03'59''的失败数/请求数作为失败率（时间跨度不一致）
6、代码目录结构
断路器状态接口：实现 -- 开启 关闭 半开
数据模型接口：实现 -- swoole fpm
消息通知接口：实现 -- 钉钉 ops
断路器管理程序：一些基本属性 + 断路器状态注入 数据模型注入 消息通知注入
