// Linux · 2026-05-21

搞懂负载均衡（Load Balancer）：现代化高并发架构的“交通指挥官”

负载均衡架构运维

在互联网世界中，当一个网站或应用刚起步时，架构通常很简单：用户直接访问一台服务器。但随着用户量暴增，单台服务器的算力、带宽和内存很快就会见顶。

面对“泼天流量”，单机垂直升级（加内存、换更强的 CPU）总有物理极限，且存在单点故障（SPOF）风险——一旦这台服务器宕机，整个业务彻底瘫痪。

于是，架构演进的核心思想变成了“人多力量大”的水平扩展（Horizontal Scaling）：用一堆服务器组成集群。而在这堆服务器前面，必须有一个角色来负责分发流量、确保大家不饿死也不撑死，这个角色就是 LB（Load Balancer，负载均衡器）。

一、 什么是负载均衡（LB）？

简单来说，负载均衡器就像是银行营业厅里的“排号机”或“大堂经理”。

如果没有大堂经理，客户（用户请求）会盲目冲向某一个窗口（服务器），导致一号窗口排队到大门口，而二号窗口的柜员在闲坐。大堂经理的作用，就是看一眼各个窗口的忙碌状态，把新来的客户有序地指引到空闲或压力较小的窗口。

在技术架构中，LB 接收客户端的所有网络流量，并根据特定的算法和规则，将这些流量合理、均匀地分发到后端的多个服务器节点上。

二、 核心工作原理：四层 vs 七层

根据在 OSI 网络模型中所处的层级，负载均衡最主流的分类是四层负载均衡（L4）和七层负载均衡（L7）。这也是面试和架构设计中最常被提及的概念。

1. 四层负载均衡（L4 - 网络层与传输层）

  • 工作原理： 它主要依据报文中的 IP 地址 和 端口号（Port） 来决定流量怎么走。L4 只负责“转发”，它既不知道、也不关心应用层传输的具体内容（比如 HTTP 请求里带了什么 Cookie、访问的是哪个 URL）。
  • 技术核心： 修改报文的源 IP/目的 IP（NAT 模式）或 MAC 地址（DR 模式），直接建立客户端与后端服务器的 TCP 连接。
  • 经典代表： LVS（Linux Virtual Server）、F5（硬件）、云厂商的 NLB（Network Load Balancer）。
  • 特点： 性能极高，吞吐量大，对 CPU 消耗低，因为它不需要解析复杂的应用层协议。

2. 七层负载均衡（L7 - 应用层）

  • 工作原理： 它能够“看懂”具体的应用层协议（如 HTTP/HTTPS）。它可以根据请求的 URL 路径、域名（Host）、HTTP Header、Cookie、甚至 POST 请求中的内容 来做更智能的路由。
  • 技术核心： LB 作为反向代理，先与客户端建立 TCP 连接，读取并解析 HTTP 内容后，再与后端服务器建立新的 TCP 连接并转发请求。
  • 经典代表： Nginx、HAProxy、云厂商的 ALB（Application Load Balancer）。
  • 特点： 功能强大且灵活，支持动静分离、灰度发布（金丝雀发布）、根据用户身份分发等复杂业务场景，但由于要解析协议，对 CPU 和内存的消耗比四层高。

三、 常见的负载均衡算法

大堂经理（LB）是怎么决定把请求分给谁的？这取决于它运行的调度算法：

  • 轮询（Round Robin）： 顺着数，一人一个。
  • 加权轮询（Weighted Round Robin）： 考虑服务器性能差异。配置高的服务器权重高（如 3），配置低的权重低（如 1）。分配时，高权重的服务器会连续接收更多请求。
  • 最少连接数（Least Connections）： 谁身上当前挂着的 TCP 连接最少，新请求就给谁。适合处理请求耗时差异很大的业务。
  • 源 IP 哈希（Source IP Hash）： 根据客户端的 IP 地址计算哈希值，映射到固定服务器。这能确保来自同一个 IP 的用户总是访问同一台服务器，常用于早期的 Session 保持。
  • 一致性哈希（Consistent Hashing）： 常用于缓存服务（如 Redis/Memcached 集群）的前置负载均衡，在后端节点增减时，能最大程度减少缓存失效的范围。

四、 负载均衡的核心附加功能

现代 LB 早就不只是单纯的“分发器”，它还承载了高并发架构中许多至关重要的边界功能：

1. 健康检查（Health Check）

LB 会定时（如每隔 5 秒）向后端服务器发送心跳包（可以是 Ping，也可以是特定的 HTTP 请求）。

  • 如果发现某台服务器挂了（返回 500 或无响应），LB 会立刻将其从可用列表中剔除，不再给它分发流量。
  • 当这台服务器修复并重新通过检查后，LB 会自动把它加回集群。整个过程对用户完全透明，实现了系统的高可用（HA）。

2. SSL/TLS 卸载（SSL Offloading）

HTTPS 协议的握手和加密解密非常消耗服务器的 CPU 算力。通过将 SSL 证书统一部署在 LB 上，由 LB 负责处理密文交互，后端服务器只需处理清爽的 HTTP 明文请求。这极大地解放了后端业务服务器的性能。

3. 会话保持（Session Sticky / Sticky Cookies）

在前后端未完全分离的传统架构中，用户的登录信息可能保存在特定服务器的 Session 中。七层 LB 可以通过在客户端植入特殊的 Cookie，确保该用户在后续交互中始终路由到同一台服务器，避免登录状态丢失。

五、 现代云原生时代的 LB：从硬件到 Ingress

回顾负载均衡的发展史，也是技术演进的缩影：

  1. 硬件时代： 早期大厂依赖 F5、Citrix NetScaler 等专有硬件设备。它们是塞满机房的昂贵怪兽，性能极强，但动辄几十万的价格和闭源生态让中小企业望而却步。
  2. 软件时代： LVS、Nginx、HAProxy 的崛起，让开源软件加普通 X86 服务器就能搭建出极高并发的反向代理与负载均衡集群。
  3. 云原生时代： 在 AWS、阿里云等云环境中，LB 变成了开箱即用的基础设施（如 ALB/NLB/CLB）。在 Kubernetes (K8s) 微服务架构中，LB 进一步演进为了 Ingress 控制器（如 Nginx Ingress、Traefik）和 Service 网格（Service Mesh，如 Istio），实现了针对容器间流量（东西向流量）以及外网入站流量（南北向流量）的动态、自动化、精细化控制。

总结

负载均衡（LB）是现代化分布式系统不可或缺的底层基石。它不仅解决了性能（通过横向扩展抗住高并发）问题，更解决了稳定性（通过健康检查和容灾切换实现高可用）问题。

无论是构建一个小而美的 Web 网站，还是设计支撑数亿用户的微服务中台，理解并合理配置 LB，都是每一位网络工程师和系统架构师的必修课。

原文 https://blog.csdn.net/2301_79518550/article/details/161257890