应对接口级故障：服务降级、熔断、限流、排队
- 接口级故障：系统没有宕机、网络没有中断，但是业务却出现了问题：业务响应慢、大量访问超时、大量访问异常。
- 本质：系统负载过高，导致无法快速处理业务。比如，如果系统中存在慢查询，当负载过高时，慢查询会将数据库资源耗尽，导致读写操作超时，业务读写很容易出现超时现象。即使没有慢查询当负载过高时也会出现超时情况。
- 产生原因的内部条件：程序bug导致死循环、存在慢查询、程序逻辑不对导致耗尽内存
- 外部条件：黑客攻击、促销、第三方系统响应缓慢
解决思路
- 解决接口级故障的核心思想是优先保障核心业务和优先保障绝大部分用户。比如登录功能很重要，当访问量过高时，停掉注册功能，为登录腾出资源。
解决策略
降级
系统将某些不重要的业务或接口的功能降低，可以只提供部分功能，也可以完全停到所有所有不重要的功能。降级的思想是丢车保帅。
- 常见降级方式
- 系统后门降级：系统预留后门用于降级，比如提供一个降级URL，访问URL时就执行降级指令。缺点：如果服务器数量多，需要一台一台去操作，效率低。
-
独立系统降级：将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能。
独立降级系统
熔断
降级是应对系统自身的故障，而熔断的目的是应对外部系统的故障。比如A服务的X功能依赖B服务的某个接口，当B服务接口响应很慢时，A服务X功能的响应也会被拖慢，进一步导致了A服务的线程都卡在了X功能上，A服务的其它功能也会卡主或拖慢。此时就需要熔断机制，即A服务不在请求B这个接口，A服务内部发现B接口就直接返回错误，从而避免整个A服务被拖慢。
- 实现思路：需要系统有一个统一的API调用层，由API来进行采样或者统计。
限流
限流：只允许系统能够承受的访问量进来，超出的会被丢弃。
-
降级从系统功能优先级角度考虑如何应对故障，而限流则从用户访问压力的角度来考虑如何应对故障。
-
常见限流方式
-
基于请求限流：指从外部请求的角度考虑限流。常见的方式有：
- 限制总量：限制某个指标的累积上限。比如直播间的用户总数上限为100万，超过后用户无法进入。抢购商品数量为100，限制抢购用户上限为1万个，超过或直接拒绝。
- 限制时间量：限制一段时间内某个指标的上限。例如：一分钟内只允许1000个用户访问。每秒请求峰值为10万。
- 都需要找到合适的阀值：需要通过性能压测来确定阀值或者逐步优化。
-
基于资源限流：指从系统内部考虑，找到影响性能的关键资源，对其使用上限限制。常见的内部资源有：连接数、文件句柄、线程数、请求队列、CPU利用率等。例如，使用Netty实现服务器，每个请求先放到请求队列中，业务线程从请求队列中获取任务进行处理，请求队列大小为1000，那么超过该值则直接拒绝。
-
排队
排队方式来应对接口级故障的方式是：让用户等待一段时间，而不是像限流方式直接拒绝用户。从体验上来讲，虽然用户没有很快得到拒绝响应，但是如果等待时间过长，体验也不是很好。(但是对于一些请求，等待比直接拒绝要好，比如支付请求，排队总比直接拒绝好，因为直接拒绝用户就有可能不买了）
- 实现方式：排队需要保存未被处理的请求，所以排队需要缓存大量数据，一般单个系统无法缓存这么多数据，所有需要单独的排队系统去实现。例如使用Kafka、RocketMQ等消息队列来缓存用户的请求。
1号店双11秒杀排队系统
实现思路：蓝色区域是排队系统
【排队模块】
负责将用户的请求以FIFO的方式存入队列中，不同商品的秒杀请求放在不同的队列中，队列大小可以根据秒杀商品数量自行定义。
【调度模块】
负责动态调度排队模块中的请求到服务模块中。动态性体现在：会根据服务模块的当前处理能力控制拉取请求速度，如果服务模块的处理能力有空闲就提升拉取请求速度，否则降慢速度。
【服务模块】
负责调用真正的业务来处理请求，并获取返回结果，再调用排队模块的接口写回业务处理结果。
案例
如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等核心功能，你会如何设计接口级的故障应对手段？
- 思路：
丢车保帅：在秒杀时，通过服务降级把注册、修改个人信息等非核心功能关闭掉。（是否为核心此时的判断标准为：秒杀时间段这些功能影响人数少）
熔断：支付依赖第三方服务，要设置熔断策略，熔断后要给出友好提示，比如10分钟后再来支付。
排队+限流：抢购下单接口采用排队+限流方式，如抢购1000件商品，则设置2000大小的队列，请求超过2000后直接拒绝掉，前2000请求加入队列中，然后可以开启多线程对队列进行处理。
