狭义上的熔断、降级、限流
一、降级（fallback）：
1.触发服务降级出现的情况：
- 程序运行异常
- 超时
- 服务熔断触发的服务降级
- 高并发下，信号量/线程池用完后服务降级（传送门: hystrix两种资源隔离模式.）
2.服务降级的目的：
- 系统能力有限：为了最大的ROI,保证核心服务可用，非核心服务弱可用，甚至不可用。
- 避免服务雪崩：如果下游某服务不可用或者响应时间过长，会使得大量的线程被夯在此服务，对服务进行降级，会避免雪崩效应。
3.流量高峰应对策略：
流量高峰场景分为可预测（如双十一、618、春运）、不可预测（微博突发明星离婚事件）两种；
应对策略分三方面：
- 服务层降级：拒绝老请求、优先级、随机
- 数据层降级：读操作读缓存；写操作先更新缓存，顺序写mq，再异步持久化到db
- 柔性可用策略：AP->Base
3.1服务层降级：
a.服务层降级策略
关闭部分服务：
拒绝部分请求：
- *客户端拒绝请求：京东抢茅台，在客户端就将一些活跃度低、薅羊毛的人过滤掉，根本不往服务器发请求。
- 拒绝部分老请求：拒绝已经超时的老请求；在每一层做
- 优先级请求方式：非核心请求直接丢弃，根据业务header里面的cmd，在gw做
- 随机拒绝方式：随机丢弃一定比例的请求 根据业务场景
b.服务层降级策略层次
集中式：网关层
自治式：网关层、业务逻辑层、数据访问层
我们应该选择自治式，因为只在网关层做，颗粒度太粗。
3.2数据层（DB/cache）降级：
根据curd降级：
- 更新请求u：只更新缓存，持久化到消息队列（顺序写），等高峰期过去后再进行db持久化（随机写）。
- 读请求r：读缓存
- 数据补齐cd：由于insert与delete操作较少，消息队列对齐到数据库就可；其实写操作cud都可以双写缓存与mq，然后异步对齐到数据库。
可用：
- 根据数据统计，自动打开，不依赖与人工
- 上线前演练，保证线上生效
二、熔断（break）：
1.熔断机制概述：
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务调用，快速返回错误的响应信息。
2.熔断需求：
- 熔断可默认返回null，也可定制，RPC client原生支持最好，业务方少改代码
- 打印异常日志
- 可视化服务治理平台
- 报警，通知责任人
- 自动恢复
3.业界熔断方案：
Hystrix（最早经典的SDK级断路器）：每个方法都写麻烦，滑动窗口实现
resilience4j(spring官方推荐)：环形缓冲区
sentinal（阿里出的平台级断路器）:滑动窗口实现
4.添加代理层进行资源隔离
根据错误比例熔断，根据代理层捕获的异常码数除以总请求数，但是应该设置最小请求数。
5.可恢复，定时检测，服务探活
对于熔断后的降级，带@fallback注解就走自定义的降级，不带就走默认的
