Little 定律与 Gateway 链路并发分析

1. 问题背景

同一个商品接口，直接访问商品服务时可以达到较高 QPS；经过 Gateway 后，链路增加了鉴权、路由、HTTP 转发和响应回写等步骤，单请求耗时会变长。

一个常见问题是：

如果 Gateway转发后，也要保持和后端服务相同的 QPS，是否只需要增加并发数？

Little 定律可以解释其中的关系，但也要注意：增加并发是必要条件，不是充分条件。

2. Little 定律

Little 定律表示：

text 复制代码

L = λ × W

其中：

L：系统中的平均在途请求数，也就是并发量；
λ：系统吞吐量，通常用 QPS 表示；
W：请求从进入到完成的平均耗时。

变形后：

text 复制代码

QPS = 并发量 / 平均响应时间
并发量 = QPS × 平均响应时间

这里的 W 必须使用平均响应时间，不能直接用 P99 代替。P99 用于判断尾延迟和用户体验，不能直接代入 Little 定律计算平均并发需求。

3. 增加 Gateway 链路后的直接影响

假设商品服务直连时：

text 复制代码

QPS = 24,000
平均响应时间 = 40 ms

根据 Little 定律：

text 复制代码

并发量 = 24,000 × 0.040 = 960

那么这个960就是需要保持的最大连接数。

如果经过 Gateway 后，鉴权和代理增加了 10 ms：

text 复制代码

Gateway 平均响应时间 = 50 ms
并发量 = 24,000 × 0.050 = 1,200

要维持相同的 24,000 QPS，Gateway 需要承载的在途请求数从约 960 增加到约 1,200，增加 25%。

因此，链路增加后通常会出现：

text 复制代码

单请求耗时增加
    → 同样 QPS 所需在途请求增加
    → 客户端并发、连接数、线程或 EventLoop 需要承载更多请求

4. 为什么增加并发只是必要条件

根据公式，如果客户端只有 960 个并发，而 Gateway 平均耗时已经变成 50 ms，那么理论最大吞吐约为：

text 复制代码

QPS = 960 / 0.050 = 19,200

即使商品服务仍然有 24,000 QPS 的处理能力，Gateway 也无法达到该吞吐，因为入口并发不足。

但反过来，直接把并发提高到 1,200，也不保证一定达到 24,000 QPS。还必须满足：

Gateway EventLoop 没有饱和；
鉴权线程池没有排队；
出站 HTTP 连接池没有等待；
商品服务仍有处理余量；
Redis、数据库和网络没有达到上限；
压测客户端本身没有成为瓶颈。

如果其中任意一层达到容量上限，继续增加并发只会增加排队和 P99。

5. 结合本次压测数据

商品服务直连测试中，Tomcat 400 线程时：

客户端并发	QPS	P99
400	19,013	278 ms
800	21,702	259 ms
1200	21,276	237 ms
1600	23,769	269 ms

并发从 800 增加到 1600 后，QPS 只增加约 9.5%，说明系统已经接近容量平台，增加的并发主要用于消化排队和等待，而不是带来同等比例的吞吐增长。

双 Nginx 共享同一个商品服务时：

总并发	总 QPS	P99 范围
100	16,546	52～65 ms
200	17,971	52～63 ms
400	17,418	222～228 ms
800	14,604	297～321 ms

总并发从 200 增加到 800 后，QPS 不升反降，P99明显升高。这说明并发已经超过有效处理能力，系统进入排队区间。

6. Gateway 与后端达到相同 QPS的条件

如果目标是让 Gateway 达到商品服务直连的 QPS，至少需要满足两组条件。

并发条件

根据 Gateway 的实际平均耗时计算：

text 复制代码

Gateway 所需并发 ≈ 目标 QPS × Gateway 平均响应时间

例如：

text 复制代码

商品服务目标 QPS = 24,000
Gateway 平均耗时 = 60 ms
所需并发 ≈ 24,000 × 0.060 = 1,440

容量条件

Gateway 还必须有能力处理这 1,440 个在途请求，包括：

足够的 EventLoop 处理网络事件；
足够的鉴权并发度；
足够的出站连接；
足够的文件描述符；
下游服务可以接受相同的请求速率。

如果鉴权平均耗时 10 ms、目标鉴权 QPS 为 24,000，则鉴权线程或异步并发需要承载的基础并发约为：

text 复制代码

24,000 × 0.010 = 240

同步鉴权线程池还要留出安全余量；Reactive 鉴权则需要让 EventLoop 和连接池承载这些在途操作。

7. 为什么不能只看并发数

并发数是系统中的在途请求数，不是处理能力本身。

当并发增加时，可能出现三种阶段：

text 复制代码

并发不足：QPS随并发近似增长
接近容量：QPS增长变慢，P99开始上升
超过容量：QPS平台或下降，P99和超时快速增加

因此压测时应同时观察：

QPS；
平均响应时间；
P50/P95/P99；
超时和错误率；
Gateway EventLoop CPU；
鉴权线程池 active/queued；
出站连接池 pending acquire；
商品服务 Tomcat busy；
Redis 和数据库延迟。

8. 对 Gateway 设计的启示

8.1 增加链路后，需要补足在途并发

Gateway 增加鉴权和代理步骤后，平均响应时间变长。为了达到后端原有 QPS，需要更高的客户端并发或更大的系统在途容量。

8.2 不能用增加并发掩盖真正瓶颈

如果 Gateway 已经出现：

EventLoop CPU高；
鉴权队列增长；
连接池获取超时；
文件描述符耗尽；

继续增加并发只会让延迟变差，应先扩容或优化对应节点。

8.3 Gateway 与后端不能只按 QPS做简单比较

后端直连的 QPS 只反映商品服务链路；Gateway QPS还包含：

text 复制代码

鉴权
路由匹配
过滤器
出站连接获取
HTTP 转发
响应回写

所以两者的 QPS差异需要结合平均耗时和各层饱和度分析，不能仅用一个倍率推断。

9. 最终结论

Little 定律说明：

text 复制代码

链路越长、平均耗时越大
    → 达到相同 QPS 所需的在途并发越多

因此，要让增加了 Gateway 的链路达到后端直连的 QPS，确实需要提高并发承载能力。

但这只是必要条件。最终能否达到相同 QPS，还取决于 Gateway、鉴权线程池、连接池、商品服务和 Redis 中最先达到饱和的节点。

这就有点像高速公路(后端服务)和收费站（gateway），假设原来是满负载的4车道的高速路，增加收费站后，4车道必然跑不满了。而为了跑满，可以增加收费入口（假如是增加到8个），但是从4车道进入8个入口和从8个入口合并到4车道，都是需要时间的。所以不是简单的线性外推的关系，假如你增加到20个收费口，那么显然在20合并到4车道时，必然发生拥堵了，所以不是越多越好。

同样的道理，Redis改为多线程IO后，明确说明最多8个线程（含1个内存读写主线程），更多反而降低性能。