极客时间：《从 0 开始学架构》:如何应对接口级的故障？
接口级故障的典型表现就是系统并没有宕机，网络也没有中断，但业务却出现问题了
导致接口级故障的原因一般有下面几种：
- 内部原因
程序 bug 导致死循环，某个接口导致数据库慢查询，程序逻辑不完善导致耗尽内存等。 - 外部原因
如黑客攻击、促销等引入超过平时几倍甚至几十倍的用户、第三方系统大量请求等。
解决接口级故障的核心思想和异地多活基本类似：优先保证核心业务和优先保证绝大部分用户。
降级
降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。
降级的核心思想就是丢车保帅，优先保证核心业务。
常见的实现降级的方式有：
- 系统后门降级
系统预留了后门用于降级操作。如，通过一个降级URL，当访问该URL时，就会执行降级指令，具体的降级指令通过URL的参数传入。
优点：实现成本低；
缺点：需要一台服务器一台服务器的操作，比较浪费时间 - 独立降级系统
为了解决系统后门降级的缺点，将降级操作独立到一个独立的系统中，可以实现复杂的权限管理、批量操作等功能。其基本架构如下：
熔断
降级的目的是应对系统自身的故障，熔断的目的是应对依赖的外部系统故障的情况。
场景：A服务的X功能依赖B服务上的某个接口，但由于B服务的该接口相应较慢，导致A服务的线程卡在X功能的处理上，此时，A服务的其他功能都会被卡住或相应非常慢，这时就需要熔断机制。
熔断机制实现的关键是需要有一个统一的 API 调用层，由 API 调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了。
熔断机制实现的另外一个关键是阈值的设计。实践中一般都是先根据分析确定阈值，然后上线观察效果，再进行调优。
限流
降级是从系统功能优先级的角度考虑如何应对故障，而限流则是从用户访问压力的角度来考虑如何应对故障。限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。
限流一般都是系统内实现的，常见的限流方式可以分为两类：基于请求限流和基于资源限流。
- 基于请求限流
基于请求限流指从外部访问的请求角度考虑限流，常见的方式有：限制总量、限制时间量。
限制总量的方式是限制某个指标的累积上限，常见的是限制当前系统服务的用户总量
限制时间量指限制一段时间内某个指标的上限
这两种方式的共同特点就是实现简单，但在实践中面临的主要问题是：如何找到合适的阈值。
为了找到合理的阈值，通常情况下可以采用性能压测来确定阈值，但性能压测也存在覆盖场景有限的问题，可能出现某个性能压测没有覆盖的功能导致系统压力很大；另外一种方式是逐步优化，即：先设定一个阈值然后上线观察运行情况，发现不合理就调整阈值。
- 基于资源限流
基于请求限流是从系统外部考虑的，而基于资源限流是从系统内部考虑的，即：找到系统内部影响性能的关键资源，对其使用上限进行限制。常见的内部资源有：连接数、文件句柄、线程数、请求队列等。
基于资源限流相比基于请求限流能够更加有效地反映当前系统的压力,但在实践中面临两个问题：
- 如何确定关键资源
- 如何确定关键资源的阈值。
通常情况下，这也是一个逐步调优的过程，即：设计的时候先根据推断选择某个关键资源和阈值，然后测试验证，再上线观察，如果发现不合理，再进行优化。
排队
排队实际上是限流的一个变种，限流是直接拒绝用户，排队是让用户等待一段时间.
由于排队需要临时缓存大量的业务请求，单个系统内部无法缓存这么多数据，一般情况下，排队需要用独立的系统去实现，例如使用 Kafka 这类消息队列来缓存用户请求。
PS:如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等功能，你会如何设计接口级的故障应对手段？
答：
1.对于用户服务，在抢购期间可以准备降级策略，压力过大时保证用户登录的可用，注册和修改信息可以做降级处理
2.抢购下单涉及到订单，库存，和商品查询。可通过请求排队来限流，超出库存的请求直接返回。
为了应对库存和商品服务可能发生的故障，可以提前对商品数据和库存数据做缓存，如果对端服务故障，本地也可以提供服务
3.支付依赖第三方系统，合理设置熔断策略，如支付平均时长超过限制可提示用户稍晚做支付