91 | 项目实战一：设计实现一个支持各种算法的限流框架（设计）

限流框架文档哪里可以看到？

背压等于限流吗？如果是的话，要如何实现基于HTTP的restful api背压？

这种限流是不是应该结合物理资源监控动态调整比较好？

在不同的业务场景下，对于每个接口，时间粒度和限流值的选择都是不同的，比如在平时和大促（如618，11.11）时，因为服务器数量不同，所以选择也不同，比如在618时，流量可能都集中在几秒内，TPS 会非常大，几万甚至几十万，需要选择相对小的限流时间粒度，相反，如果接口 TPS 很小，则使用大一点的时间粒度，比如限制 1 分钟内接口的调用次数不超过 1000 。 对于限流值的选择，需要结合性能压测数据、业务预期流量、线上监控数据来综合设置，最大允许访问频率不大于压测 TPS，不小于业务预期流量，并且参考线上监控数据。 如何验证设置的合理性？可以通过导流的方式将流量集中到一小组机器上做真实场景的测试，并记录下每个请求的对应接口，请求时间点，限流结果，进行分析。另外我们还需要时刻监控限流的工作情况，实时了解限流功能是否运行正常。一旦发生限流异常，能够在不重启服务的情况下，做到热更新限流配置。

以前在耗子叔专栏看到过动态流控的文章（左耳听风49节），可以借鉴了TCP使用RTT来探测网络延时和性能，从而设定相应滑动窗口，根据调用方一段时间内响应时间的P90或P99值，来作为限流的参考。这个一样可以用在限流框架上的。

1.限流值的大小一般在预估流量~压测流量满足响应时长下的最大吞吐之间。 2.时间力度的选择要看场景。首先明确一点，时间力度越小，流量峰值则越小。服务群能否正常提供服务，看的是流量峰值是否小于压测流量最大值（拐点）。那么在整点秒杀这种场景，时间力度就要尽可能小，结合人机检验和先抢购买权等策略降低并发度后，时间窗口应该也能使用。但如果是阿里京东这种大型电商公司的双11，时间窗口就不合适了，除非你的集群规模大于当前时间力度的最大峰值（并行度很可能真达到峰值），不然限流策略都很难保护服务群。而这样的规模服务，在serverless普及前，成本是接受不了的（请求上来时服务瞬间扩容，过去后又瞬间缩容）。这时采用类似均速发牌的算法就合适些。而在平时业务稳定期，时间力度就可以长一些，因为这个时候流量比较平缓，峰值一般都不会很高，只需要做粗力度的流量控制即可。 3.验证是否合理：模拟或则镜像流量压测不能压垮服务，且尽量去减少计算资源。满足稳定服务的前提下，尽量减少计算成本。用合适的成本，提供稳定的服务才叫合理。

可以先测试自己的应用调用接口的次数，合理的使用。怎么验证合理性，主要还是看具体的应用调用次数，可以测出来的。

实践一下吧，可以拿正常的线上流量回放保证不被限流。再用压测流量压一下，保证服务不down就ok

思考题：需要结合线上流量的情况，包括均值和峰值

项目里现在就是从单一的程序进行拆分到多个，有公用的模块，有独立的模块，但是还不是很熟练，还在摸索中前进。看到评论区都说很有收获，这实战，我得看好几遍利用起来