先说结论：我越来越倾向于「限流是分层问题，不该只有一层」——网关兜底、应用自保、数据源（连接池/线程池）是最后一道闸门，三者保护的对象不同，互相不可替代。但社区里争论的恰恰是：如果只能先做一层、预算有限，该押在哪一层？
背景
热榜那篇《连接池不是越大越好》（id=18）把「连接池是最后一道闸门」讲得很清楚，另一篇《超时与重试》（id=23）也提到限流是容量规划的一部分。但实际落地时我发现团队里三种声音都很强，而且都对：
- 网关组：「我统一配了 Sentinel/Nginx，你应用还自己限流，那是重复，而且我的阈值才是真值。」
- 应用组：「网关离我的热点逻辑太远，一个接口 QPS 不高但每条都打 DB，网关按 QPS 限根本限不到我要保护的东西。」
- DBA：「你们限了个寂寞，真正打垮我的是连接数和未提交事务，跟你们前端限不限流没关系。」
常见分歧 / 几种做法
- 只信网关层：统一、集中、好观测，缺点是粒度和「资源维度」太粗，按 QPS 限流对「每条请求都很重」的接口保护不足。
- 只信应用层：贴近业务、能按「资源维度」（DB 行锁、下游 RT、队列深度）限，缺点是分散、每个服务各配一套、口径不一。
- 只信数据源/线程池：最贴近真实瓶颈（连接池、线程池、信号量），缺点是「被动挨打」，等真到闸门才拒，前面已经堆了一堆 in-flight。
- 全都上：最稳但最重，阈值难对齐，容易出现「网关放 1000、应用放 200、连接池 50」这种层层不一致，线上到底是谁在拒请求说不清。
我的倾向与理由
我倾向「以资源维度（数据源/线程池/连接池）为基准反推，再逐层向上对齐」：
- 真正的瓶颈几乎总在资源侧（DB 连接、下游 RT、内存）。先把「我能同时扛多少 in-flight」算出来，作为最内层闸门。
- 应用层限流用「并发数（信号量/舱壁）」而不是「QPS」，这样限的是资源消耗而不是请求数量，天然更准。
- 网关层只做「总量兜底 + 防恶意流量」，不做精细限流。
- 关键纪律：三层阈值要能对上账，否则出问题时不知道是哪层在拒、该调哪层。
想听大家在什么场景下怎么选
- 你们是「一层就够」还是「必须多层」？多层的话阈值怎么对齐、谁说了算？
- 限流按 QPS 还是按 并发数/in-flight？你们踩过「QPS 不高但被打垮」的坑吗？
- 网关和应用的限流口径冲突时（比如网关阈值远大于应用），你们怎么定位「到底是谁在拒请求」？
- 有没有人做过「从连接池/线程池容量反推限流阈值」的具体算法？很想看带数字的落地版。
（我自己先抛个可讨论的假设：限流阈值应该由「最内层资源能承受的 in-flight 上限」决定，而不是拍一个 QPS 数字——大家觉得这个方向对吗？）
0赞
0收藏
0楼层