负载均衡如何影响网络性能？四层和七层负载均衡怎么选？
简化版
负载均衡通过把流量分发到多台后端提升吞吐、可用性和扩展能力。四层负载均衡基于 IP、端口和 TCP/UDP 转发，性能高、延迟低；七层负载均衡理解 HTTP 等应用协议，能按域名、路径、Header 做路由和灰度，但解析和处理开销更大。性能优化要关注算法、健康检查、连接复用、会话保持、TLS 卸载和热点后端。
详细版
四层和七层负载均衡的差异：
| 维度 | 四层负载均衡 | 七层负载均衡 |
|---|---|---|
| 工作层次 | TCP/UDP | HTTP/gRPC/WebSocket 等 |
| 路由依据 | IP、端口、连接 | Host、Path、Header、Cookie |
| 性能 | 更高，处理更少 | 稍低，能力更强 |
| 能力 | 转发为主 | 鉴权、限流、灰度、重写 |
| 典型组件 | LVS、云 NLB | Nginx、Envoy、云 ALB |
负载均衡不是简单随机分发。算法不合适会导致热点；健康检查不准会把流量打到故障节点；连接复用配置不好会让后端建连成本高；会话保持会让负载不均。面试回答要把“分发流量”和“保证性能稳定”一起讲。
完整版教学
一、负载均衡解决的是扩展和容错问题
单台服务器的 CPU、网卡、连接数和进程能力都有限。负载均衡把请求分发给多个后端，让整体容量接近多台机器之和。同时，如果某台后端故障，负载均衡可以摘除它，把流量转到健康节点。
Client -> LB -> Server A
-> Server B
-> Server C假设单台后端能稳定处理 2000 QPS，3 台理论容量约 6000 QPS。但真实容量会受热点、共享数据库、缓存、连接复用和负载均衡器本身瓶颈影响，不是简单乘法。
二、四层负载均衡为什么性能高
四层负载均衡工作在传输层，主要看源/目标 IP、端口和协议，不需要解析 HTTP。它可以直接转发 TCP/UDP 流量，处理路径短，吞吐高，适合需要高性能、协议透明的场景，例如数据库代理、游戏网关、通用 TCP 服务。
四层转发常见模式：
客户端 TCP 连接 -> LB 选择后端 -> 转发字节流因为不理解应用层，它不能按 /api、/static 路径路由，也不能直接做 HTTP Header 修改。能力少，换来的是更低开销和更强通用性。
四层负载均衡像交通分流，七层负载均衡像看懂包裹内容后再分拣。
三、七层负载均衡为什么能力强
七层负载均衡能解析 HTTP、gRPC 等应用协议，所以可以按域名、路径、Header、Cookie、方法、请求体部分信息做路由。它还能做 TLS 终止、压缩、限流、鉴权、灰度发布、A/B 测试、重试和熔断。
例如：
Host: api.example.com, Path: /v1/orders -> order-service
Host: img.example.com, Path: /avatar/* -> image-service
Header: x-gray=true -> canary-service代价是七层代理要解析协议、维护更多状态，CPU 和内存开销更大。高并发下要关注 worker 数、连接池、上游 keepalive、TLS 加速和日志开销。
四、负载均衡算法会影响热点和尾延迟
常见算法包括轮询、加权轮询、最少连接、一致性哈希、随机加权。轮询简单，但不同请求耗时差异大时可能不均；最少连接适合长连接或请求耗时差异大的场景；一致性哈希适合需要会话亲和或缓存命中的场景。
| 算法 | 适合场景 | 风险 |
|---|---|---|
| 轮询 | 后端能力接近，请求均匀 | 慢请求导致局部排队 |
| 加权轮询 | 机器配置不同 | 权重配置不准会偏斜 |
| 最少连接 | 长连接、耗时差异大 | 统计成本更高 |
| 一致性哈希 | 缓存、本地状态 | 热 key 会打爆单点 |
如果某个用户或 key 特别热，一致性哈希会把它固定打到同一后端，缓存命中提高了，但热点风险也更大。
五、健康检查决定故障是否被及时摘除
健康检查不能只看端口通不通。端口通只能说明进程还在监听，不代表业务可用。更好的健康检查应覆盖依赖状态、线程池、数据库连接、磁盘和关键业务自检，但也不能太重，避免健康检查本身拖垮服务。
TCP check: 端口可连接
HTTP /healthz: 进程活着
HTTP /readyz: 依赖就绪，可接流量如果健康检查太宽松，故障节点继续接流量；太严格，短暂抖动会导致频繁摘除和恢复，造成流量震荡。通常还要配置连续失败次数和恢复阈值，例如失败 3 次摘除，成功 2 次恢复。
六、连接复用和 TLS 卸载影响延迟
七层负载均衡经常在客户端侧终止 TLS，然后复用到后端的连接。如果没有上游 keepalive，每个请求都新建后端连接，TCP 握手和 TLS 握手会显著增加延迟和 CPU。
假设后端 TCP 握手 1 ms、TLS 握手 3 ms，每秒 10000 个请求都新建连接，握手成本会非常高。连接复用可以把多次请求放到已有连接里，降低建连开销。
Client --TLS--> LB --keepalive--> BackendTLS 卸载还能集中管理证书和加密计算，但也要考虑 LB 到后端是否需要再加密，尤其在跨机房或零信任网络里。
七、负载均衡器本身也可能成为瓶颈
负载均衡器有自己的 CPU、内存、网卡、连接表、端口范围和日志 I/O 限制。性能问题有时不在后端，而在 LB。比如开启详细 access log、复杂正则路由、过高 TLS 握手、过多短连接，都可能把 LB 打满。
常见指标：
| 指标 | 含义 |
|---|---|
| active connections | 当前连接数 |
| new connections/s | 每秒新建连接 |
| backend error rate | 后端错误比例 |
| upstream latency | 后端响应耗时 |
| LB CPU/网卡 | 转发和加密压力 |
排查时要分清客户端到 LB 慢，还是 LB 到后端慢。七层代理通常能提供 downstream/upstream 分段耗时，这是定位关键。
八、常见误区与追问
- 误区：负载均衡就是随机分发请求。 真实系统要考虑算法、权重、健康检查、连接复用、会话保持和故障摘除。
- 误区：七层负载均衡一定比四层好。 七层能力强但开销更大，四层在通用 TCP 和高性能转发场景更合适。
- 误区：健康检查端口通就够了。 端口通不代表依赖可用，生产上通常区分 liveness 和 readiness。
- 误区：会话保持总是好事。 它能保持状态，但可能造成负载不均和热点。
- 追问：最少连接适合什么场景？ 适合长连接或请求耗时差异大的场景，比轮询更能反映当前压力。
- 追问：TLS 卸载有什么好处？ 集中证书管理、减少后端加密压力、便于七层路由，但要评估内网安全。
- 追问：如何判断 LB 是瓶颈？ 看 LB CPU、连接数、新建连接速率、TLS 握手、队列、下游和上游分段耗时。
九、加强记忆
负载均衡性能题按“层次、算法、健康检查、连接、瓶颈”来答：四层快而透明，七层懂协议能力强；算法决定分布是否均匀，健康检查决定故障是否摘除，连接复用和 TLS 卸载影响延迟，LB 自身指标决定它会不会成为新瓶颈。