狭义上的熔断、降级、限流
一、降级（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注解就走自定义的降级，不带就走默认的
