本文是《网络是怎样连接的》精读系列第 22 篇，全书逐章精讲、通俗拆解，帮你从零吃透计算机网络的底层逻辑。
第一部分：性能不足时，为什么需要负载均衡？
当用户访问量快速上升，单台 Web 服务器即便配置再高，也会遇到无法突破的瓶颈：
- 计算资源耗尽：CPU、内存被大量请求占满，应用响应变慢、超时甚至崩溃；
- 网络带宽瓶颈：单张网卡、单条链路的带宽存在上限，无法承载持续增长的流量；
- 单点故障风险：只有一台服务器提供服务，一旦硬件、系统或网络异常，整个服务直接不可用。
负载均衡的核心价值
负载均衡（Load Balancing） 的本质，是把来自用户的海量请求，均匀、合理地分发到多台服务器，让多台机器形成一个整体，共同承担压力。
它从根本上解决三大问题：
- 提升并发处理能力：从 "一台扛压力" 变为 "多台分摊压力"，实现服务能力的水平扩展；
- 保证高可用：某台服务器异常时，自动把流量切走，实现故障无感切换；
- 优化访问效率：让请求流向负载更低、状态更好的服务器，降低整体响应延迟；
- 降低成本：用多台普通服务器替代昂贵的小型机 / 高端服务器，性价比更高。
第二部分：负载均衡器如何分配访问？
负载均衡器是整个架构的流量调度中心，部署在用户与后端服务器之间，所有请求先经过它，再转发到目标服务器。
核心工作流程
- 用户请求到达负载均衡器；
- 负载均衡器根据配置的策略 / 算法，选择一台健康的后端服务器；
- 将请求转发给这台服务器处理；
- 服务器处理完毕，将响应返回给负载均衡器；
- 负载均衡器再将响应转发给用户，完成一次完整交互。
主流负载均衡算法
不同算法决定流量如何分配，适用场景各不相同：
表格
| 算法类型 | 核心逻辑 | 适用场景 | 优缺点 |
|---|---|---|---|
| 轮询（Round Robin） | 按顺序轮流分配请求 | 服务器配置相近、请求耗时相似 | ✅ 简单高效；❌ 不关心实际负载 |
| 加权轮询（Weighted RR） | 按权重分配，性能强的服务器多分 | 服务器配置有明显差异 | ✅ 适配硬件差距；❌ 无法动态调整 |
| 最小连接数（Least Connections） | 分给当前连接最少的服务器 | 长连接、文件下载、WebSocket | ✅ 贴近真实负载；❌ 略有计算开销 |
| IP 哈希（IP Hash） | 按客户端 IP 哈希固定到一台服务器 | 需要会话保持（登录、购物车） | ✅ 会话稳定；❌ 扩缩容会重新分配 |
| 最短响应时间 | 结合连接数 + 响应时间综合选择 | 实时业务、低延迟要求高 | ✅ 用户体验优；❌ 需要采集性能数据 |
负载均衡器的形态
- 硬件负载均衡：F5、A10 等专业设备，性能极强，用于金融、大型企业；
- 软件负载均衡：Nginx、HAProxy、LVS，灵活、低成本，互联网公司主流；
- 云负载均衡：阿里云 SLB、AWS ELB 等托管服务，开箱即用，免维护。
健康检查：高可用的关键
负载均衡器会持续对后端服务器做健康检查（TCP 端口探测、HTTP 接口探测等）：
- 检测失败：自动将服务器摘除，不再分发流量；
- 检测恢复：自动重新加入集群，继续承担流量；
- 实现故障自动隔离、自动恢复，无需人工干预。
第三部分：负载均衡的典型架构
1. 四层负载均衡（传输层）
- 工作在 TCP/UDP 层 ，基于 IP + 端口 转发；
- 只做流量转发，不解析应用层内容，性能极高；
- 代表：LVS、云厂商四层 SLB；
- 适合：高并发、大流量、通用转发场景。
2. 七层负载均衡（应用层）
- 工作在 HTTP/HTTPS 层，能解析域名、URL、Cookie 等；
- 可做精细路由：按路径、按接口、按设备分流；
- 代表：Nginx、HAProxy、云厂商七层 SLB；
- 适合：Web 服务、API 网关、需要业务策略的场景。
典型完整流量链路
用户 → 运营商网络 → 四层负载均衡 → 七层负载均衡 → Web 服务器集群 → 应用服务 → 数据库
💡 分层价值：四层扛流量、七层做策略，兼顾极致性能与业务灵活。
第四部分：核心结论 ------ 负载均衡是互联网的流量基石
负载均衡的本质，是用分布式协作替代单点高性能：
- 它让多台普通服务器组成稳定、强大的服务集群；
- 解决了高并发、可扩展、高可用三大核心问题；
- 是电商大促、直播、短视频、社交平台等海量访问场景必不可少的底层架构。
没有负载均衡，就没有今天能支撑亿级用户的互联网服务。它把 "单点脆弱" 变成 "集群可靠"，是网络性能与架构设计的关键一步。
💡 想看后续全部章节 → 关注我，不迷路。下一章我们将深入探索：利用缓存服务器提升速度，带你看懂数据如何 "就近触达" 用户。