一、项目背景

我们这套 AI 网关刚接进生产时，下游模型实例不多，流量也温柔，一切正常。直到某业务方搞促销，短时间涌进来一大波请求，后端连接数瞬间被打满，新建连接开始抖，老连接又没及时释放，模型服务超时一片。更糟的是有个别客户端写错了，反复建连不关，连接像漏水一样慢慢漏光，其他正常请求也被拖死。

这个问题暴露的是网关对下游连接缺乏治理。我们在 AI 网关的接入层和路由层之间加了一层连接与并发治理，目标很简单：后端连接数可控、单客户端不能霸占、漏的连接要被捞回来。底层是基于现有网关的路由转发逻辑扩展。

二、落地场景

落了四件事。后端连接池上限与复用，每个模型实例配连接池上限，请求取连接用完归还，不每次新建。单客户端并发限制，按调用方标识限最大并发，超了排队或拒，防止一家把池子占满。空闲回收与健康探测，长时间没动静的连接主动关掉，定期探活踢掉死连接。慢连接熔断，单次请求超过阈值直接断，不让它一直占着连接不撒手。

上线先在其中一个模型集群试点，那个集群之前最容易被打挂。配置上我们保守起步，先限流再观察，避免一刀切把正常业务也拦了。

三、关键技术挑战与解决思路

第一个挑战是连接池上限怎么定。定小了正常流量排队，定大了又回到被打满的老路。我们按单实例能稳扛的并发数倒推池大小，留两成余量，再配排队上限，超排队的才拒，既保护后端又不瞎拦。

第二个是连接泄漏。客户端不关连接，池子慢慢空。我们在连接上挂空闲超时，超过一定时间没活动直接回收，同时在网关侧统计每个客户端的连接占有时长，异常长的报警，漏的能被捞回来。

第三个是慢连接。有的请求模型卡住几十秒不返回，一直占连接。我们给每次调用设硬超时，到点网关主动断连并归还池子，同时把这类慢请求计数，频繁慢的客户端降级处理，避免一颗老鼠屎坏一池汤。

案例片段（已脱敏）： 连接池配置片段（YAML 示意）：upstream:  model_a:    max_connections: 64    max_queue: 128    idle_timeout_sec: 30    per_client_concurrency: 8    call_timeout_ms: 30000监控日志一例：促销期单客户端并发冲到 40，超 per_client_concurrency 8 的部分进入队列，排队超 128 后拒绝少量尖峰；连接空闲回收任务每 30 秒扫一次，当日回收泄漏连接约 220 个，后端超时率从约 12% 降至约 1.5%。

四、效果数据

试点集群跑了一个促销周期，数据是实的。连接复用率从原来近乎零（每次新建）升到约 88%，后端新建连接的压力小了一大截。后端超时率，促销高峰从约 12% 降到约 1.5%，主要是池子不再被打爆。新建连接抖动，之前促销期标准差很大，治理后平稳，因为连接是复用不是现建。泄漏连接数，每日自动回收约两百个，没再出现池子被漏光的情况。

有个细节要提，限流初期我们把 per_client_concurrency 定太低，把一家正常做批处理的客户拦了，后来调到合理值并加了白名单，正常批量不受影响。限流这种事，阈值得贴着真实流量调，不能拍脑袋。

五、可复用经验总结

网关对下游一定要建连接池，每次新建连接在洪峰下必死，我们那次促销打挂就是教训。泄漏比打满更阴险，连接慢慢漏光你一时发现不了，挂空闲超时加占有时长监控才是正解。慢连接必须硬超时，占着茅坑不拉的请求最伤整体，断了它池子才转得动。限流阈值贴近真实流量调，太低误伤正常业务，太高形同虚设，批处理客户记得留白名单。

后来我们把连接池配置纳入网关接入规范，新模型上线先配池子和限流再放流量。

附：治理之外的运维手感

连接池稳定后，我们复盘了那次打挂的根因，其实是客户端没做重试退避，失败就猛冲，把池子当成了无限资源。后来我们在网关侧给客户端加了退避提示，返回里带重试间隔建议，规范一点的客户端就老实等了。还有个观察，连接复用率上来后，后端实例的句柄数平稳了，之前每次新建连接，操作系统文件描述符涨落大，偶尔触到上限，这种隐性故障最难查。我们把连接池大小和实例句柄上限做了联动配置，一方改另一方跟着校验，避免人配错。网关对下游的治理，表面是限流和池子，底下是把客户端的坏习惯也管起来，否则再大的池子也架不住瞎冲。

我们还给连接池加了饱和度看板，实时显示各模型连接占用，运营一看就知道哪里快满了，提前扩池子而不是等打挂。之前那次事故后，我们特意把历史事故指标钉在看板上做对照，防止好了伤疤忘了疼。客户端侧我们也推了接入规范，要求必须实现退避和连接归还，不符合的接入时直接拒，从源头减少漏连接。网关对下游的治理，一半是技术一半是约束调用方，只管自己不管别人，池子永远不够用。现在我们新接一个模型，先过连接池和限流这关，不过不让放流量。