应对接口故障的几种方案

核心思想：优先保证核心业务 + 优先保证大多数用户

1、降级

使某些非核心功能不可用，比如微博的发帖、看帖、评论功能降级为看帖、评论，再降级为看帖

服务后门降级，服务开一个接口，到时候访问这个接口，传进去降级参数来执行关闭某些功能的，优点是实现简单，缺点一是不太安全，这点可以加密，把密钥传进去。二是如果服务的机器比较多，那得一台一台得调用这个接口，有点麻烦，费时间。

独立得降级系统，搭建一个独立的降级系统来做降级功能。

2、熔断

降级是减少服务内部的问题，熔断是减少外部的问题。比如我们的服务依赖一个第三方的接口，那个接口慢导致我们这儿也慢，这时候就可以熔断，不再调用那个接口。

熔断要求有统一的url转发层才能做，如果调用分散在程序各处就不太好做了。

3、限流

限流是机器扛不住了，限制一部分流量，让机器可以正常运转不至于宕机。比如当在线用户达到一千万时，禁止新的用户登陆。

可以以业务指标为标准来做限流，比如用户数，每秒请求数这种；

也可以以机器资源的指标为标准来做限流，比如cpu利用率，内存利用率，高到一定程度之后开始限流；

不管那种方式，限流的判断阈值都得不断的调试，前者可能调的更麻烦一点。

4、排队

排队是限流的一种缓和的处理方式，限流是直接拒绝了，像禁止登陆这种，排队不是，是让用户等一下，比如秒杀排队这种。

排队要实现得配合消息队列，像kafaka，把用户的请求放到队列里面，等允许了在放出来处理。

目前应对接口级故障的方案，大致这四种，核心思想比较重要。