负载均衡需“接入”与“集群”协同设计，涵盖流量特征适配、健康探测、配置中心、无状态部署、拓扑标签、指标采集及动态调度闭环。
负载均衡不是加个反向代理就完事，关键在“接入”和“集群”的协同设计。真正扛住高并发的系统，靠的是一套可感知、可伸缩、可自愈的架构闭环。
负载均衡器怎么选型与接入
接入第一步不是部署，而是明确流量特征和调度目标：
- 如果是短连接API服务（如Langflow后端），优先用Traefik或Nginx，配置简单、健康检查成熟；
- 如果是长连接或WebSocket场景（如Agent实时交互），需启用
least_conn或连接数感知策略，避免请求堆积在已满节点； - 若后端节点性能差异大（比如混用A10和H100），必须用加权轮询，并定期根据GPU利用率动态调权；
- 所有接入点必须开启主动健康探测（如
/health端点），失败3次自动摘除，恢复后平滑加回，不能靠重启硬拉。
多实例集群的关键设计原则
集群不是越多越好，而是要让每个实例“有状态地协作”：
- 共享配置中心：模型路径、Prompt模板、限流阈值等统一由Consul或Nacos管理，避免实例间行为不一致；
- 分离无状态与有状态逻辑：通义千问2.5-7B这类推理服务必须无状态部署，会话/缓存/任务队列交由Redis+Celery独立承载；
- 实例命名带拓扑标签：例如
qwen-gpu-a10-01、qwen-gpu-h100-02，便于在Traefik或K8s中按label做灰度路由； - 每个实例暴露标准指标端点（如
/metrics），供Prometheus采集GPU显存、请求P95延迟、排队长度等核心数据。
高并发下的动态调度实战要点
静态配置在流量突增时必然失效，真正的实战在于“实时反馈—决策—执行”闭环：
- 用Kubernetes HPA配合自定义指标（如每秒推理请求数QPS）触发扩缩容，而不是只看CPU；
- 在API网关层嵌入令牌桶限流（如Go的
x/time/rate），单实例限流+全局熔断双保险； - 对慢请求主动干预：当某实例P95延迟超过300ms且连接数＞80%，自动降低其权重至1/4，持续观察5分钟再恢复；
- 任务类请求（如Dify工作流）走异步通道，前端返回TaskID，后端用消息队列分发，避免HTTP连接长时间占用。
常见故障与快速定位方法
高并发系统出问题，90%集中在三类链路断点：
- 请求进不来：检查负载均衡器access log是否收到请求；确认iptables/NAT规则没拦截，云厂商安全组是否放行端口；
-
请求进来了但卡住：登录任一后端实例，用
ss -tnp | grep :7860 | wc -l看连接数，再查nvidia-smi看GPU是否OOM； -
部分实例响应快、部分极慢：对比各实例的
/metrics中model_inference_duration_seconds直方图，排查是否某台机器磁盘IO异常或NUMA绑定失衡； - 所有实例都慢？立刻检查Redis连接池是否耗尽、PostgreSQL连接数是否打满、是否触发了全局分布式锁竞争。
