负载均衡（Load Balancing）是一种将网络流量或客户端请求，通过特定算法分配到多台服务器的技术，核心目的是避免单台服务器过载，保障系统稳定和高效运行。
负载均衡本质上是一种资源调度技术，通过特定算法将客户端请求或网络流量分配到多个服务器节点上。其最终目标是提升系统整体的吞吐量、可用性和响应速度，同时防止单点故障导致服务中断。
简单来说，负载均衡就像超时的“排队结账”，不会让所有客人都挤在一个结账闸机面前，而是均匀分配给多个闸机，让整体结账速度更快、更不容易出问题。即使有一个闸机出现问题，依然能够正常结账，即将坏掉闸机前排队的客人分配到其他正常运转的闸机。
多台服务器构成集群，即使某一台宕机，其他服务器仍能继续处理请求，保障服务不中断。
将流量分散到多台服务器，相当于整合了所有服务器的 CPU、内存等资源，整体能处理更多并发请求。
避免部分服务器空闲、部分服务器高负载的 “忙闲不均” 情况，让每台服务器的资源都得到合理使用。
部分负载均衡器支持按服务器地理位置、网络延迟等因素分配请求，让用户连接到最近或响应最快的节点，减少等待时间。
负载均衡主要分为硬件负载均衡、软件负载均衡和云负载均衡三大类，不同类型在性能、成本和灵活性上各有侧重。
硬件负载均衡基于专用硬件设备，内置了负载均衡的芯片和操作系统，性能强，成本高。例如：F5 BIG-IP、Citrix NetScaler。
优势：处理性能极强，能应对高并发、大流量场景，且稳定性高、安全性好。
劣势：成本昂贵，设备固化，扩展性较差，升级和维护依赖厂商。
软件负载均衡基于通用服务器或虚拟机，通过部署软件实现负载均衡，成本低且灵活。例如：Nginx、HAProxy、LVS（Linux Virtual Server）。
优势：成本低，可按需部署和扩展，支持自定义配置，适配多种场景。
劣势：性能受服务器硬件限制，高并发下可能成为瓶颈，需要自行维护和保障高可用。
注意，软件负载均衡进一步又分为客户端软件负载均衡和服务端软件负载均衡，二者核心区别在于负载决策的执行位置，一个在客户端，一个在独立的服务端中间层。
负载决策由客户端（如应用程序、服务实例）自身通过软件逻辑完成，无需独立的负载均衡服务，客户端直接与服务端通信，减少转发延迟。
客户端集成负载均衡库或组件，先从服务注册中心（如 Nacos、Eureka）获取可用服务节点列表，再通过内置算法（轮询、随机等）选择目标节点。例如：Ribbon、Spring Cloud LoadBalancer
负载决策由一台或多台独立部署的“负载均衡服务器”（运行专用软件）完成，客户端无需感知后端节点，客户端仅与负载均衡服务器交互，便于统一管控。
客户端将请求统一发送到负载均衡服务器，服务器通过软件逻辑（如 Nginx 的反向代理、HAProxy 的转发规则）将请求分发到后端服务节点。例如：Nginx、HAProxy、LVS（Linux Virtual Server）。
云负载均衡是由云厂商（如阿里云、AWS）提供，集成在云基础设施中，用户无需关注底层硬件，按使用量付费。例如：阿里云 SLB、AWS ELB、腾讯云 CLB。
优势：弹性扩展能力强，可根据流量自动调整资源，按需付费，运维成本低。
劣势：依赖特定云厂商，迁移成本可能较高，部分高级功能需额外付费。
下图是OSI 网络模型图（来自网络）：
负载均衡按 OSI 网络模型的工作层级划分，核心分为四层负载均衡和七层负载均衡，两者的本质区别在于基于什么信息进行请求分发，适用场景也因此不同。
四层负载均衡工作在 OSI 模型的传输层（TCP/UDP 层），仅基于IP 地址和端口进行请求转发，不关心应用层数据（如 HTTP 内容）。
客户端请求到达负载均衡器后，负载均衡器解析数据包的源 IP、目标 IP、源端口、目标端口（TCP/UDP 头部信息）。
根据预设规则（如轮询、IP 哈希），将请求转发到后端服务器的对应 IP: 端口。
转发过程中可能修改数据包的 IP 或端口（如 NAT 模式），但不解析 HTTP 头、URL 等应用层内容。
优势：性能极高（仅处理传输层协议），转发速度快，适合高并发、大流量场景（如数据库、视频流）。
劣势：功能简单，无法基于应用层信息（如 URL 路径、Cookie）做精细化分发，对后端服务的健康检查也较基础（多基于端口是否存活）。
LVS（Linux Virtual Server，Linux 内核级负载均衡，性能极强）
F5 BIG-IP（硬件设备，支持四层 / 七层，四层性能突出）
HAProxy（软件，可配置为四层模式）
工作在 OSI 模型的应用层（如 HTTP/HTTPS、FTP 层），基于应用层协议内容（如 HTTP 头、URL 路径、Cookie、请求参数）进行请求分发。
客户端请求到达负载均衡器后，负载均衡器会完整解析应用层协议（如 HTTP 请求的 URL、Host、Cookie 等）。
根据应用层信息制定转发规则（如将/api/user请求转发到用户服务集群，/api/order转发到订单服务集群）。
转发时可能修改应用层数据（如添加 HTTP 头），并能对后端服务做更细致的健康检查（如模拟 HTTP 请求判断服务是否正常）。
优势：功能灵活强大，支持基于应用层信息的精细化路由、SSL 卸载（负载均衡器解密 HTTPS，后端用 HTTP）、缓存静态资源等，适合 Web 应用、API 服务。
劣势：需解析应用层协议，性能略低于四层负载均衡，高并发场景下可能成为瓶颈（需通过集群缓解）。
Nginx（主流 Web 服务器，同时是高性能七层负载均衡器）
HAProxy（支持七层模式，常用于 TCP 和 HTTP 混合场景）
维度 | 四层负载均衡 | 七层负载均衡 |
工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS 等） |
转发依据 | IP 地址 + 端口 | URL、Host、Cookie 等应用层信息 |
性能 | 极高（仅处理传输层协议） | 较高（需解析应用层协议） |
功能灵活性 | 低（无应用层逻辑） | 高（支持精细化路由、SSL 卸载等） |
适用场景 | 数据库、视频流、高并发服务 | Web 应用、API 网关、微服务路由 |
注意，除了四层和七层负载均衡，还有一些其他层级的负载均衡：
二层负载均衡：工作在数据链路层（MAC 层），基于 MAC 地址转发，较少见（如某些硬件设备的集群模式）。
三层负载均衡：工作在网络层（IP 层），基于 IP 地址转发，常与四层结合使用（如 LVS 的 DR 模式依赖三层 IP 转发）。
实际场景中，四层和七层是最常用的两类，且常结合使用（如 “四层负载均衡 + 七层负载均衡” 的多级架构，既保证性能又兼顾灵活性）。如下图：
上图架构中，入口采用四层负载负责 “粗粒度” 的流量分发（基于 IP / 端口），性能极高，可应对大并发场景；后端的 Nginx（七层负载均衡）负责“细粒度” 的应用层路由（基于 URL、Cookie 等），支持精细化的业务逻辑（如静态资源缓存、SSL 卸载、URL 重写）。两者结合既保证了高吞吐，又满足了应用层的灵活需求。
同时，多台 Nginx 节点并行工作，避免了单点故障；四层负载均衡可动态扩展 Nginx 集群的规模，随着流量增长能通过增加 Nginx 节点来分摊压力，整体架构的扩展性强。
但是，存在一个问题，入口机器存在单节点故障，可以通过下面方案进行解决：
主备冗余（Keepalived + VRRP）
部署至少两台入口机器，通过 Keepalived 实现虚拟 IP（VIP）漂移。正常时主节点承载流量，备节点待机；主节点故障时，备节点自动接管 VIP，确保客户端无感知切换。
多活集群（DNS 轮询 / Anycast）
DNS 轮询：将多个入口机器的公网 IP 配置到 DNS 解析中，客户端随机选择 IP 访问。结合健康检查，自动剔除故障 IP（需缩短 DNS TTL）。
Anycast + BGP：所有入口机器宣告同一 Anycast IP，通过 BGP 协议将路由广播到网络。某节点故障时，BGP 自动撤销路由，流量自动切到其他节点（如 Cloudflare、阿里云 SLB 的实现方式）。
负载均衡主流调度算法主要围绕 “公平分发”“效率优先”“按需定制” 三大目标设计，不同算法适用于不同的业务场景，核心可分为静态算法和动态算法两大类。
静态算法仅根据预设规则分发请求，不动态感知后端服务器的负载（如 CPU、内存使用率），实现简单、效率高。
该算法按顺序依次将请求分配给后端服务器，例如请求 1→服务器 A、请求 2→服务器 B、请求 3→服务器 A，循环往复。
适合后端所有服务器性能一致、无状态服务（如静态资源服务）。如果服务器性能差异大，会导致性能差的服务器过载，性能好的服务器资源闲置。
该算法给性能不同的服务器分配不同“权重”，权重越高的服务器接收的请求越多。例如服务器 A 权重 3、服务器 B 权重 1，请求分配比例约为 3:1。
适合后端服务器性能不均衡（如部分服务器配置更高），需要按能力分配负载。弥补了普通轮询的缺陷，能更合理利用服务器资源。
该算法对客户端的 IP 地址进行哈希计算，根据计算结果将请求固定分配给某一台后端服务器。
适合需要“会话保持”的服务（如用户登录状态、购物车数据存储在服务器本地），确保同一客户端的请求始终落到同一台服务器。如果某台服务器故障，会导致该哈希结果对应的所有客户端请求失败（需结合健康检查和故障转移优化）。
动态算法会实时采集后端服务器的负载数据（如 CPU 使用率、内存占用、连接数），根据负载情况动态调整请求分发策略，避免服务器过载。
该算法实时统计后端服务器的当前连接数，将新请求分配给连接数最少的服务器。
适合后端服务存在长连接（如数据库连接、WebSocket），或请求处理时间差异大（如部分请求需复杂计算）。它能动态平衡服务器负载，避免某台服务器因连接堆积过载。
该算法结合“权重”和“最小连接数”，给性能更好的服务器分配更高权重，同时优先选择权重归一化后连接数最少的服务器（即“权重 / 连接数” 比值最大的服务器）。
适合后端服务器性能不均衡，且请求处理时间差异大（如混合部署了高性能服务器和普通服务器的 API 服务）。它兼顾服务器性能差异和实时负载，是更智能的动态均衡策略。
该算法将实时统计后端服务器的“请求响应时间”（从接收请求到返回响应的耗时），将新请求分配给响应时间最短的服务器。这不仅考虑连接数，还关注服务器的实际处理效率，能更精准地选择“最快”的服务器。
适合对延迟敏感的服务（如金融交易、实时数据查询），需优先保证客户端的响应速度。
如果要了解更多负载均衡算法请参考专业算法书籍。
川公网安备51010802032098
