负载均衡本身不解决高并发，而是使多台机器协同扛压可行可控可恢复；真正的弹性扩展必须与健康检查、自动注册、资源联动深度绑定。
负载均衡本身不解决高并发，它只是让“多台机器一起扛压”这件事变得可行、可控、可恢复——真正的弹性扩展，必须和健康检查、自动注册、资源联动三者咬死。
怎么让新实例上线后立刻被流量打到？关键在服务注册时机
很多团队部署完新 LangFlow 或 Django 实例，发现流量没分过去，查半天是注册没触发。不是加了 nginx upstream 就算接入成功。
- 无状态服务（如 LangFlow、Dify）必须依赖外部注册机制：启动时主动调用负载均衡器 API（如 Nginx Plus 的
upstream_conf），或通过 Consul/Etcd 自动同步；静态配置upstream列表只适合预知扩容节奏的场景 - 容器化部署下，Kubernetes 的
Service+EndpointSlice是默认注册通路，但要注意：Pod 启动后需通过 readiness probe 返回 200 才会被加入 Endpoints，否则流量仍会 503 - 常见错误：Django 应用启用了 Gunicorn 的
--preload，导致 health check 接口在 worker 加载前就返回失败，注册被拒绝
健康检查配错，等于把负载均衡器变成“盲人引导员”
某次大促中，3 台服务器里有 1 台内存泄漏但 CPU 正常，因健康检查只做 TCP 连通性检测，该节点持续接收请求，最终拖垮整个集群。
- 四层（TCP/UDP）检查只验证端口是否 open，适合数据库代理等简单透传场景；七层（HTTP/HTTPS）检查能验证业务逻辑可用性，例如访问
/healthz并校验响应体中的"status": "ok" - 超时时间不能设成 1s：Python 的 Django/Flask 默认启动慢，冷启动可能达 3–5s；建议 initial delay ≥ 10s，check interval ≥ 5s，failure threshold ≥ 3
- 避免用
/做健康检查路径：某些前端路由框架（如 Next.js）对根路径做 SSR 渲染，反而加重负担；专用路径更轻量、更可控
加权最少连接算法，比轮询更适合真实高并发场景
轮询看着公平，但在长连接、异步任务、LLM 流式响应等场景下，极易造成“连接数失衡”。一台服务器挂着 200 个未结束的 SSE 连接，另一台却只有 5 个 HTTP 短连接，轮询还在继续发新请求。
-
least_conn（Nginx）、leastconn（HAProxy）动态看活跃连接数，天然适配 WebSocket、gRPC stream、LangFlow 的流式 LLM 输出 - 若后端性能差异大（比如混用 8C16G 和 4C8G 实例），改用
least_time last_byte（HAProxy）或 Nginx 的ip_hash+ 权重组合，但注意：加权需配合监控数据人工校准，别凭空写weight=3 - 一致性哈希（
hash $remote_addr consistent）适合需要会话保持的场景，但别滥用——它会让扩容/缩容时 30%~40% 请求命中缓存失效，对 Redis 缓存雪崩敏感
弹性伸缩不是“加机器→生效”，而是“指标触发→注册→验证→引流→观察”闭环
自动扩容后 QPS 没涨反降？大概率是新实例还没通过健康检查，或者数据库连接池没预热，直接被塞满请求。
- 伸缩策略不能只盯 CPU：高并发下，DB 连接池耗尽、Redis 响应延迟 >100ms、线程阻塞率 >15% 更早暴露瓶颈；建议用 Prometheus + Alertmanager 基于
process_cpu_seconds_total+redis_exporter_latency_seconds联合告警 - 新实例启动后，务必预热：Django 可跑一次
python manage.py shell -c "from django.db import connection; connection.cursor()"；LangFlow 可提前加载常用 model config 到内存 - ELB/Nginx 不支持“渐进式引流”，但可通过灰度权重控制：先设新实例
weight=1，5 分钟后升到weight=5，配合日志监控错误率突增
最常被忽略的一点：负载均衡器自身的连接数和 TLS 握手能力。Nginx 默认 worker_connections 512，面对百万并发时，光是 SSL handshake 就可能卡在 accept 队列。别只盯着后端，先确认你手里的“引导员”有没有足够多的胳膊和眼睛。
