05百万架构师核心技术设计实践——熔断、降级、限流

狭义上的熔断、降级、限流
一、降级（fallback）：
1.触发服务降级出现的情况：

• 程序运行异常
• 超时
• 服务熔断触发的服务降级
• 高并发下，信号量/线程池用完后服务降级（传送门: hystrix两种资源隔离模式.）

2.服务降级的目的：

• 系统能力有限：为了最大的ROI,保证核心服务可用，非核心服务弱可用，甚至不可用。
• 避免服务雪崩：如果下游某服务不可用或者响应时间过长，会使得大量的线程被夯在此服务，对服务进行降级，会避免雪崩效应。

3.流量高峰应对策略：
流量高峰场景分为可预测（如双十一、618、春运）、不可预测（微博突发明星离婚事件）两种；
应对策略分三方面：

• 服务层降级：拒绝老请求、设置请求的优先级、随机丢弃
• 数据层降级：读操作读缓存；写操作先更新缓存，顺序写mq，再异步持久化到db
• 柔性可用策略：AP->Base

3.1服务层降级：
a.服务层降级策略
关闭部分服务：
拒绝部分请求：

• 客户端拒绝请求：京东抢茅台，在客户端就将一些活跃度低、薅羊毛的人过滤掉，根本不往服务器发请求。
• 拒绝部分老请求：拒绝已经超时的老请求；在每一层做
• 优先级请求方式：非核心请求直接丢弃，根据业务header里面的cmd，在gw做
• 随机拒绝方式：随机丢弃一定比例的请求 根据业务场景

b.服务层降级策略层次
集中式：网关层
自治式：网关层、业务逻辑层、数据访问层
我们应该选择自治式，因为只在网关层做，颗粒度太粗。

3.2数据层（DB/cache）降级：
根据curd降级：

1. 更新请求u：只更新缓存，持久化到消息队列（顺序写），等高峰期过去后再进行db持久化（随机写）。
2. 读请求r：读缓存
3. 数据补齐cd：由于insert与delete操作较少，消息队列对齐到数据库就可；其实写操作cud都可以双写缓存与mq，然后异步对齐到数据库。

可用：

• 根据数据统计，自动打开，不依赖与人工
• 上线前演练，保证线上生效

数据层面的降级一般发生在服务提供方，熔断发生在服务调用方

二、熔断（break）：

1.熔断机制概述：
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务调用，快速返回错误的响应信息。

服务雪崩：　服务雪崩效应是一种因“服务提供者的不可用”（原因）导致“服务调用者不可用”（结果），并将不可用逐渐放大的现象。这个时候，需要及时发现下游服务不可用，通过熔断防止错误放大，服务恢复后自动恢复调用。

2.熔断需求：

• 熔断可默认返回null，也可定制，RPC client原生支持最好，业务方少改代码
• 打印异常日志
• 可视化服务治理平台
• 报警，通知责任人
• 自动恢复

3.业界熔断方案：
Hystrix（最早经典的SDK级断路器）：每个方法都写麻烦，滑动窗口实现
resilience4j(spring官方推荐)：环形缓冲区
sentinal（阿里出的平台级断路器）:滑动窗口实现

4.添加代理层进行资源隔离
根据错误比例熔断，根据代理层捕获的异常码数除以总请求数，但是应该设置最小请求数。

5.可恢复，定时检测，服务探活
对于熔断后的降级，带@fallback注解就走自定义的降级，不带就走默认的