传统架构，为何不是默认流控的？
站点与服务，服务与服务上下游之间，一般如何采用两种通讯模式：
其一，RPC直接调用。
其二，MQ推送模式。其二，MQ推送模式。
画外音：这也是MQ的默认模式。
这两种模式，都可能造成流量冲击：流量从端到站点，到服务，到数据库，流量会一路透传下来，引发雪崩。
举个秒杀业务的栗子。
- 上游：端上发起抢购操作；
- 下游：完成秒杀业务逻辑（库存检查，库存冻结，余额检查，余额冻结，订单生成，余额扣减，库存扣减，生成流水，余额解冻，库存解冻）；
上游每秒并发1W个请求，下游每秒只能并发处理2K个请求，如果流量直接透传，会导致下游系统被压垮。雪崩出现后，整体系统并发处理能力归0。
如何避免雪崩，使得整体系统能够保持在一个并发2K的处理水平？
有两大类优化方向：
- 上游队列缓冲，限速发送；
- 下游队列缓冲，限速执行；
那哪种优化对架构改造最小？
下游队列缓冲，限速执行，对系统改造最小。
如何改造？
上下游之间加一个MQ，采用拉模式：
MQ-reciever根据自己的处理能力，实施流控，就能达到保护自身的效果。并且这是MQ提供的通用功能，无需上下游修改代码。
如果上游发送流量过大，MQ提供拉模式确实可以起到下游自我保护的作用，但会不会导致消息在MQ中堆积，导致全部超时？
下游处理过慢，确实可能会导致消息堆积，常见的有两种处理方法：
- 治标法，提前判断请求在队列中的停留时间，如果超时，直接快速返回，这样至少还能保证一部分请求不超时；
- 治本法，还是要优化下游业务系统，例如批量处理，才能从根本上提升吞吐量；
结论
削峰填谷，避免雪崩，实施流控，最小化升级：
- MQ要做的：MQ-client使用拉模式，定时或者批量拉取，可以起到削平流量，下游自我保护的作用；
- 业务系统要做的：优化处理吞吐量；
知其然，知其所以然。
思路比结论更重要。
