A应用调用B应用，当B应用的接口响应耗时平均都在3000ms的时，如果当前A调用B的请求数达300/s 那么在3s内A应用在途的请求数 = 300 * 3 =900 ，按照servlet原理一个http的请求需要一个线程提供服务，即需要900个线程提供服务，tomcat线程数一般就1500左右，假设数字我们在变一下：
| 耗时 | qps | 3000ms内需要线程数 | 备注 |
| 3000ms | 300 | 900 | 应用争抢cpu |
| 3000ms | 400 | 1200 | 应用基本抢不到cpu |
| 3000ms | 500 | 1500 | 应用完全死机 |
| 4000ms | 300 | 1200 | 应用基本死机 |
| 4000ms | 400 | 1600 | 应用基本死机 |
| 4000ms | 500 | 2000 | 应用完全死机 |
针对上面的场景，为了保护A应用不被外部B应用响应慢拖死，需要合理设置A调用B的接口超时时间，但是B接口的超时是不可避免的，网络随时抖动，B应用可能故障，B应用可能性能瓶颈，A请求量增大导致B扛不住等。所以A做的措施
- 设置合理接口超时时间
- A调用B设置熔断
- 上游调用A设置限流
- 注意一定是线参数限流模式，因为ｑｐｓ限流当尖峰流量来的时候，同时遇到B响应慢，则A可能瞬间线参数打满，A直接夯死了
以上问题是我在生产上遇到过的，当时8个实例的应用，B应用耗时3s-4s，瞬间A实例的线参数打打到1500-1600，A的所有实例打死了7个，这个时候调整限流qps，熔断时间等已经来不及，因为应用早已经打死了，只能重启。所以一定要有线程数限流的模式做兜底，不管你qps调整多高，要用线程数模式来兜底一次，当前这个接口，需要最大，最多分配多少线程来提供服务？
