负载均衡的本质与核心定义
- 负载均衡，简单说就是：把海量的网络请求流量，合理、均匀地分摊到多台服务器（服务器集群）上处理的技术。它的角色就像流量调度员，站在客户端和后端服务器集群之间，作为流量入口，统一接收所有请求再分发。
- 为什么需要负载均衡？
如果没有负载均衡，所有用户直接访问一台服务器，当用户激增时，会导致：- 单点故障：如果这台服务器宕机，整个业务就彻底瘫痪。
- 资源浪费：可能某些服务器闲得发慌，而另一台服务器却已经过载。
- 响应延迟：服务器处理不过来，用户就会感到卡顿甚至请求超时。
为什么一定要用负载均衡？
负载均衡是分布式架构的基石，但凡后端服务器数量≥2，就有必要做负载均衡。
- 解决单点压力，提升系统处理能力：单台服务器的 CPU、内存、带宽都是瓶颈，集群 + 负载均衡可以线性提升系统的并发承载能力（比如 1 台能抗 1 万并发，10 台集群理论能抗 10 万）。
- 实现故障容错，保证服务高可用：负载均衡会做健康检查，如果某台服务器宕机/卡死/响应超时，会自动把流量切走，不会将请求分发到故障节点，用户无感知，服务不中断。
- 支持弹性扩容/缩容：业务高峰期加服务器、低谷期减服务器，都可以无缝接入/下线，不用停止服务，适配业务流量的动态变化。
- 隐藏后端架构，提升安全性：客户端只需要访问负载均衡的地址，永远不知道后端真实的服务器 IP，避免后端服务器直接暴露在公网被攻击；同时可以在负载均衡层做限流、防 DDOS、黑白名单等安全策略。
- 优化用户体验，降低响应延迟：结合算法可以把请求分发到负载低、距离近的服务器，减少请求排队时间，提升接口响应速度。
- 统一入口，简化业务配置：客户端只需要配置一个负载均衡的域名，不用关心后端有多少台服务器，后续后端集群的变更对前端完全透明。
负载均衡的核心分类
负载均衡的分类有多个维度，最核心的是按网络七层模型分层和按部署形态。
按OSI七层网络模型分层（最核心）
负载均衡设备/软件工作在不同的网络层级，能识别的信息不同，能力和场景也完全不同，行业里只关注四层（传输层）和七层（应用层），二层/三层几乎不用。
- 四层负载均衡（传输层，TCP/UDP层）
- 工作原理：基于IP地址 + 端口号 做流量分发，只识别数据包的源IP、目标IP、源端口、目标端口、协议（TCP/UDP），不关心请求的具体内容。
- 比如：客户端请求 10.0.0.1:80，四层LB会把这个TCP连接转发到后端集群的192.168.1.2:80/192.168.1.3:80 等节点。
- 核心特点：转发速度极快、性能极高，因为只是做简单的数据包转发，不解析应用层内容，几乎无性能损耗；属于无状态转发。
- 缺点：功能简单，只能做端口/IP级别的分发，无法根据请求内容（比如 URL、Cookie、请求头）做精细化调度。
- 七层负载均衡（应用层，HTTP/HTTPS层）
- 工作原理：基于 应用层的具体请求内容 做流量分发，会完整解析 HTTP/HTTPS 请求报文，识别URL、域名、Cookie、请求头、参数等信息，再做分发。
- 比如：把/api/user的请求分发到用户服务集群，把/api/order的请求分发到订单服务集群；把带特定 Cookie 的请求分发到固定服务器。
- 核心特点：功能强大、调度精细化，可以做 URL 路由、会话保持、限流、反向代理、缓存、压缩、SSL 解密等；本质上七层负载均衡 = 反向代理 + 负载均衡。
- 缺点：因为要解析应用层报文，性能比四层低（但足够支撑绝大多数业务场景），属于有状态转发。
| 类型 | 级别 | 特点 | 适用场景 |
|---|---|---|---|
| 四层负载均衡(L4) | 传输层 | 基于IP和端口（TCP/UDP）速度极快，但不看具体内容。 | 数据库集群、简单的 Web 流量。 |
| 七层负载均衡(L7) | 应用层 | 深度分析请求。可以根据 URL、Cookie、HTTP 头部进行分流。 | 动静分离、灰度发布、微服务网关。 |
负载均衡的核心灵魂：调度算法
- 负载均衡的核心就是用什么规则分发请求，这个规则就是负载均衡算法，算法的优劣直接决定了集群的负载是否均匀、服务的响应是否高效。所有算法分为两大核心类：静态算法、动态算法，没有最好的算法，只有最适合业务场景的算法。
静态算法（无状态，推荐简单场景）
- 核心特点：分发规则固定，不考虑后端服务器的实时状态（比如服务器的 CPU 利用率、内存占用、连接数），只按预设规则分发；实现简单、效率高，适合服务器配置一致、业务请求均匀的场景。
- 轮询（Round Robin）
- 原理：请求按顺序依次分发给后端服务器，比如 1→2→3→1→2→3 循环。
- 优点：最简单、公平，无配置成本；
- 缺点：如果服务器配置不同/负载不同，会导致负载不均（比如高配服务器闲、低配服务器崩）。
- 适用：后端所有服务器配置完全相同，业务请求量均匀的场景。
- 加权轮询（Weight Round Robin）
- 原理：给每台服务器设置权重值，权重越高，分到的请求越多；比如服务器 A 权重 2，B 权重 1 → 分发顺序 A→A→B→A→A→B。
- 优点：解决了轮询的负载不均问题，适配服务器配置不同的场景；
- 缺点：依然不考虑服务器实时负载；
- 适用：后端服务器配置有差异（比如高配权重高，低配权重低），最常用的静态算法，生产环境首选。
- 源地址哈希（IP Hash）
- 原理：对客户端的 IP 地址做哈希计算，得到一个固定值，然后映射到固定的后端服务器；同一个客户端的所有请求，永远分发到同一台服务器。
- 优点：天然实现会话保持，不用额外配置；
- 缺点：如果某台服务器宕机，该 IP 的所有请求都会失效；如果客户端 IP 集中，会导致负载不均；
- 适用：需要会话保持的简单场景（比如登录后的请求）。
动态算法（有状态，推荐复杂场景）
- 核心特点：分发规则会根据后端服务器的实时负载状态动态调整，会采集服务器的CPU利用率、内存占用、当前连接数、响应时间等指标，再做分发；实现稍复杂，但能做到极致的负载均匀，适合服务器配置不同、业务请求波动大的场景，也是生产环境的主流。
- 最小连接数（Least Connections）
- 原理：把新请求分发到当前已建立连接数最少的服务器；
- 优点：能适配请求处理时长不同的业务（比如有的请求耗时 10ms，有的耗时 1s），自动把请求分给空闲的服务器；
- 缺点：如果服务器配置不同，低配服务器可能扛不住少量长连接；
- 适用：绝大多数动态业务，比如电商、支付、社交，生产环境最常用。
- 加权最小连接数（Weight Least Connections）
- 原理：在最小连接数的基础上，给服务器加权重；权重越高，能处理的连接数越多；
- 优点：结合了加权轮询和最小连接数的优点，完美适配服务器配置不同 + 请求耗时不同的场景；
- 缺点：配置稍复杂；
- 适用：中大型生产集群，最优解。
- 最短响应时间（Least Response Time）
- 原理：把新请求分发到当前连接数最少 + 平均响应时间最短的服务器；
- 优点：兼顾了服务器的负载和处理效率，能最大程度提升用户体验；
- 缺点：需要采集服务器的响应时间指标，有轻微性能损耗；
- 适用：对响应速度要求极高的场景（比如秒杀、直播、金融交易）。
- 源地址哈希 + 动态兜底
- 原理：基础用 IP 哈希保证会话，当某台服务器负载过高时，自动把该IP的后续请求分发到其他服务器；
- 优点：兼顾会话保持和负载均匀；
- 适用：需要会话保持的高并发场景。
主流负载均衡产品
软件负载均衡
- Nginx
- 定位：七层负载均衡（HTTP/HTTPS），兼顾反向代理、静态资源缓存、限流、SSL 卸载；
- 优点：轻量、高性能、配置简单、免费开源，社区活跃，支持自定义模块；
- 缺点：不支持四层负载均衡（新版本支持 Stream 模块，可做 TCP 四层转发）；
- 适用：所有 Web 服务、HTTP/HTTPS 接口，是互联网公司的绝对主流，面试必考。
- HAProxy
- 定位：同时支持四层+七层，专业的负载均衡软件，性能比Nginx稍高；
- 优点：功能强大，支持更多的调度算法，健康检查更精细，适合高并发场景；
- 缺点：配置稍复杂，不支持静态资源缓存；
- 适用：中大型集群、需要同时做四层和七层调度的场景。
- LVS（Linux Virtual Server）
定位：纯四层负载均衡，Linux内核级别的转发，性能是软件LB的天花板；
优点：性能极高（能扛十万级并发），基于内核转发，几乎无性能损耗；
缺点：功能简单，只做四层转发，不支持七层，配置复杂；
适用：超大型集群的四层流量调度（比如大厂的核心网关）。
硬件负载均衡
- F5BIG-IP：硬件LB的王者，支持四层 + 七层，性能极高、稳定性极强，自带防火墙、防DDOS、SSL 卸载等全套功能，价格昂贵，适合大厂的核心业务（比如支付、登录）。
- 深信服/Array：国产硬件 LB，性价比高，功能和F5类似，适合政企、金融行业。
云厂商负载均衡
所有云厂商都提供托管式负载均衡服务，不用自己部署和维护，按需付费，开箱即用：
- 阿里云：SLB（Server Load Balancer）
- 腾讯云：CLB（Cloud Load Balancer）
- AWS：ELB（Elastic Load Balancer）
- 特点：支持四层 + 七层，自动扩容，自带健康检查、容灾、限流，适合云上部署的业务，是中小企业的首选。
云原生负载均衡（微服务必备）
- Ingress-Nginx/Traefik：基于K8s的七层负载均衡，专门为微服务设计，支持动态配置、服务发现、灰度发布，是云原生时代的主流。