http流量分级处理机制

需求：

当后端服务能力不足时我们希望尽可能为更多优质用户请求提供服务相应，放弃部分劣质请求，待峰值回落或后端扩容后再无差别对待。

前提条件：

监控（观察）
必须要有完备的监控体系能及时发现流量的波动，并能推算出后端剩余的服务能力。
网关（控制）
必须要有统一的流量入口用于访问统计和访问控制。 

模块划分：

各个模块的作用：

网关：

流量入口，统计request，控制response。由于网关是高并发、低延时的应用场景，所以对于流量限制部分的判断一定要低运算、短链路，所以限制条件等已经要在网关层有同步和缓存机制。

采样分析：

对流量进行分级的核心算法，可以从以下几个方面考虑。

源IP	请注意这里是用户最原始的请求IP，如果你的系统架构经过公有云LB等，很可能已经丢掉了，所以这个条件要求比较苛刻。
Path	根据用户请求路径进行采样分析，但是如果Path太多了，不方便扩展和维护。
Params	根据用户请求参数进行采样分析，同path，如果参数太多，不方便扩展和维护。
用户	看能否区分VIP用户、普通用户，或者通过token或ticket机制区分登录用户、匿名用户。

待限制：

采样分析的产出结果，需要经过同步机制内置到网关层。 

状态监控：

要及时发现并计算当前请求量与后端服务能力之间的gap，可以从以下几个方面考虑。

 

频响	可以通过后端服务的响应速度来推断服务情况，例如频响升高多少则认为服务能力开始吃紧。
QPS	可行用户请求的qps来推断是否需要为后端服务进行限流控制，推荐该方式，因为配合token或用户信息可以“防刷”。
资源利用率	通过后端服务的CPU、内存等资源利用情况来判断服务能力，但其实一些写的好的程序对性能压榨的很充分，该判断依据个人认为并不靠谱。

 挡位：

可以将对请求的限制策略划分为几个挡位，例如服务能力70%时禁止匿名用户访问，80%时限流并禁用非VIP用户，90%时禁用“高频”请求用户。

 案例：

这里给一个基于token流量分级的简单案例

这里的场景需要一个异步的流式监控工具，所以选择了Netflix的Mantis，统计分析ticket的请求频次，当服务能力充足时不做任何限制。当服务能力紧张时可以禁用非登录用户、禁用高频用户等。