系统服务响应超时的应对方法和策略

              泛指系统没有宕机，但是业务处理性能差，服务响应低效。通常原因也好理解：

1. 内部程序设计问题：例如数据库查询慢、单个进程占用资源太多、某些处理出现Bug（死循环、低效算法等）
2. 外部原因：业务量快速增长、远远超出预计；遭到黑客攻击如DDos；促销、特殊事件带来的用户量脉冲式爆发

处理思路：保证核心业务和绝大部分用户。

方法策略有：

1. 降级：监控发现资源不足时，对非核心业务不分配资源，全力保证核心业务。例如新闻论坛只保证浏览用户，暂时关闭评论和转发入口。 操作上有：通过后门降级（需要单个单个操作）；通过独立设计的降级系统，触发降级指令（类似以前电信的Overload信令）
2. 熔断：和降级主要针对内部处理能力不足的区别是，主要应对外部业务爆发或攻击。熔断机制实现的关键首先是有统一的API调用层；其次是阈值的设定。一旦启动，则将某项服务直接中断，该服务的API调用全部直接返回错误。
3. 限流：降级是从内部降低服务响应级别来做，限流则是从外部访问压力角度来说的。限制入口流量在系统访问能力内，超出的丢弃。常见的是基于请求限流（总累积请求数、时间内请求数）；基于资源限流（内部的连接数、线程数等）
4. 排队：其实类似于限流。一般同时还会在入口提供等待页面“前面有XXX个用户在等待，预计还需要XXX分钟！”，舒缓一下用户心理。