第2章-接入与限流层

第 2 章 · 接入与限流层

导读：请求进入系统的「第一公里」。本章讲清楚如何用分层网关、连接治理和限流算法，把不可控的洪峰变成可控的排队。这是扛住百万 QPS 的物理基础——模型再强，接入层崩了，一切归零。

本章导言

很多人对「百万 QPS 的 AI 对话引擎」的想象，是从模型推理集群开始的：多少张卡、什么并行策略、怎么调度。但真实世界里，系统往往不是被「算不过来」压垮的，而是被「连不过来、涌不过来」压垮的。一个对话请求从用户设备到模型之间，要先穿过接入层这张网——它负责把上百万并发的长连接接住、把流式协议终结、把不可控的流量整形为可预测的后端负载。这一层做不好，后面的架构再精妙也无从谈起。

本书第一章我们已经校准了口径、画出了流量画像，并明确了「真正要设计的是百万用户同时在线流畅对话的并发能力」。那么问题来了：这份并发能力，第一关由谁守？答案是接入与限流层。它要同时回答三个问题：

1. 连得住吗？ 百万级长连接（WebSocket / SSE）如何稳定维持，不把单机 fd 打爆、不让内存被连接表吃光？
2. 转得动吗？ 外部五花八门的客户端协议，如何统一收敛为内部高效的 RPC，且不因协议转换引入瓶颈？
3. 堵得住吗？ 突发洪峰来袭时，如何既保护下游模型不被冲垮，又不至于把用户一刀切拒之门外？

用一个具体数字感受接入层的份量：支撑 100 万长连接，仅连接表与心跳就要吃掉数十 GB 内存，TLS 握手在峰值每秒可达十万级——这些开销发生在任何一次模型推理之前。换句话说，模型决定了「答得好不好」，接入层决定了「答不答得出来」。这也是为什么本书把接入与限流层放在核心模块的第一章：它是最先被流量考验、也最不能出错的一层。

本章分三节逐层拆解。2.1 分层网关与连接治理 解决「连得住、转得动」——用四层卸载、七层转换、连接池复用、背压四件套把洪峰挡在门外；2.2 限流算法选型 解决「堵得住」——令牌桶、漏桶、滑动窗口各自的脾气与组合打法；2.3 降级与排队 解决「堵住了怎么办」——过载时不硬扛、用降级和优先级队列保住核心体验。三节合起来，构成接入与限流层的完整方法论。

带着这一章的方法，你会在第 3 章看到：接入层拦下并整形后的流量，如何被上下文与缓存进一步「打折」；在第 4 章看到：限流放行后的请求，如何被模型路由聪明地分发。但在那之前，先把第一公里守住。

本章与其他章的关系

• 上游（第 1 章）：流量画像告诉我们峰值、并发连接数、突发特征，本章据此设计接入容量。
• 下游（第 3、4 章）：接入层整形后的稳定流量，交给缓存层降本、路由层分发。
• 闭环（第 5 章）：实战中接入层的配置模板与踩坑，会回到总结章形成可复用清单。

读前请记住一句话：接入层的目标不是「接得越多越好」，而是「接得稳、转得顺、堵得巧」。 下面进入 2.1。