接口高可用:如何应对API故障?

概述

相较于异地多活、高可用存储、高可用计算这些高大上的东东,接口故障平时出现的概率更高。例如某个接口导致了慢查询,返回时间过长;某个接口依赖第三方接口,结果第三方接口挂掉了,拖慢整个服务。

针对接口故障,有以下处理方法。

降级

其思想是保证核心业务接口正常,关闭其他接口。例如对于论坛,当访问量突增,保证读帖接口正常,但是发帖接口性能可以适当降低。

降级的目的是处理系统自身故障。

熔断

熔断的目的是应对依赖的外部系统的故障。

例如 A 服务接口依赖第三方的 B 服务接口,当 B 服务接口慢或者挂掉,A 服务对外的接口会被拖垮。此时需要进行熔断。

限流

降级是从系统功能优先级的角度考虑如何应对故障,而限流则是从用户访问压力的角度来考虑如何应对故障

对外可以基于请求限流,例如 QPS 上限为 10000;对内可以基于资源限流,例如系统 CPU、内存占用率、连接数等数据。

排队

类似限流,但是限流是直接拒绝用户,排队是让用户等待一段时间。场景主要有:12306 抢票、电商秒杀等等。

思考题

如果你来设计一个整点限量秒杀系统,包括登录、抢购、支付(依赖支付宝)等功能,你会如何设计接口级的故障应对手段?

1、业务上准备降级策略,保证登录可用,注册等功能可以降级
2、秒杀请求做排队处理,防止超卖
3、库存和商品数据属于“缓存热点”,活动开始前可以载入缓存
4、三方支付依赖系统,设置一个平均时长,超出时间,引导用户重新支付

参考链接