场景

请求的到来，往往是没有规律的。

例如，某应用的处理能力是每秒 10 个请求。在某一秒，突然到来了 30 个请求，而接下来两秒，都没有请求到达。在这种情况下，如果直接拒绝 20 个请求，应用在接下来的两秒就会空闲。所以，需要把请求突刺均摊到一段时间内，让系统负载保持在请求处理水位之内，同时尽可能地处理更多请求，从而起到“削峰填谷”的效果。

image.png
上图中，红色的部分代表超出消息处理能力的部分。观察得出，消息突刺往往都是瞬时的、不规律的，其后一段时间系统往往都会有空闲资源。把红色的那部分消息平摊到后面空闲时去处理，这样既可以保证系统负载处在一个稳定的水位，又可以尽可能地处理更多消息。通过配置流控规则，可以达到消息匀速处理的效果。

分析问答

1. 问：站点与服务，服务与服务上下游之间，一般如何通讯？

答：有两种常见的方式
一种是“直接调用”，通过RPC框架，上游直接调用下游：

还有一种，在某些业务场景之下，可以采用“MQ推送”，上游将消息发给MQ，MQ将消息推送给下游。

2. 问：以上两种为什么为有流量冲击？

答：不管采用“直接调用” 还是 “MQ推送”，都有一个很大的缺点，下游消息接收方无法控制到达自己的流量，如果调用方不断的调用且不限速，很有可能把下游服务压垮。

举个例子：秒杀业务
上游发起高并发的下单请求。
下游完成秒杀业务逻辑（库存检查 - 库存冻结 - 余额检查 - 余额冻结 - 订单完成 - 余额扣减 - 库存扣减 - 生成流水 - 余额解冻 - 库存解冻）。
上游下单业务简单，每秒发起10000+个请求，下游秒杀业务复杂，每秒只能处理2000+个请求，很有可能上游不限速的下单，导致下游系统被压垮，引起雪崩。