核心思想：优先保证核心业务 + 优先保证大多数用户
1、降级
使某些非核心功能不可用，比如微博的发帖、看帖、评论功能降级为看帖、评论，再降级为看帖
服务后门降级，服务开一个接口，到时候访问这个接口，传进去降级参数来执行关闭某些功能的，优点是实现简单，缺点一是不太安全，这点可以加密，把密钥传进去。二是如果服务的机器比较多，那得一台一台得调用这个接口，有点麻烦，费时间。
独立得降级系统，搭建一个独立的降级系统来做降级功能。
2、熔断
降级是减少服务内部的问题，熔断是减少外部的问题。比如我们的服务依赖一个第三方的接口，那个接口慢导致我们这儿也慢，这时候就可以熔断，不再调用那个接口。
熔断要求有统一的url转发层才能做，如果调用分散在程序各处就不太好做了。
3、限流
限流是机器扛不住了，限制一部分流量，让机器可以正常运转不至于宕机。比如当在线用户达到一千万时，禁止新的用户登陆。
可以以业务指标为标准来做限流，比如用户数，每秒请求数这种；
也可以以机器资源的指标为标准来做限流，比如cpu利用率，内存利用率，高到一定程度之后开始限流；
不管那种方式，限流的判断阈值都得不断的调试，前者可能调的更麻烦一点。
4、排队
排队是限流的一种缓和的处理方式，限流是直接拒绝了，像禁止登陆这种，排队不是，是让用户等一下，比如秒杀排队这种。
排队要实现得配合消息队列，像kafaka，把用户的请求放到队列里面，等允许了在放出来处理。
目前应对接口级故障的方案，大致这四种，核心思想比较重要。
