1. 课程导入与工程全景

当一台服务器只能承载有限并发时，业务增长带来的第一道门槛往往不是代码写不出来，而是流量进来之后没人接得住。网络负载均衡与连接调度，解决的正是这个问题：把到达入口的请求，按照既定策略分发到后端多台服务器上，让每一台机器都工作在合理水位，同时在某台机器故障时把流量自动绕开。它不是简单的“加机器”，而是一套围绕连接建立、转发、健康判断和调度决策的工程体系。

从定义上看，负载均衡（Load Balancing）关注的是“把请求分给谁”，连接调度（Connection Scheduling）关注的是“连接如何被选中、建立、保持和回收”。两者常常一起出现：四层负载均衡在传输层根据 IP、端口和连接状态做转发，七层负载均衡在应用层根据 URL、Header、Cookie 做路由。前者像交通枢纽，后者像智能分拣中心。理解它们的差别，是后续所有配置和排障工作的起点。

核心价值：不只是分摊流量

负载均衡的价值至少体现在四个层面。第一是吞吐扩展：单机 QPS 有上限，通过横向扩展后端并前置调度，整体处理能力可以近似线性提升。第二是高可用：健康检查发现后端异常后，调度器停止向该节点转发，业务不中断。第三是弹性伸缩：在云环境中，后端实例可随负载增加或减少，负载均衡器作为稳定入口，屏蔽后端变化。第四是可观测与治理：入口层可以统一做限流、鉴权、灰度、日志采集，避免每个服务重复实现。

典型部署位置：入口、服务间、数据库层

负载均衡在真实系统中通常出现在三个位置。最外层是入口负载均衡，面向公网用户，常见形态是 LVS、Nginx、HAProxy 或云厂商的 CLB/ALB。它负责 TLS 卸载、域名路由、WAF 联动和第一层限流。第二层是服务间负载均衡，微服务之间通过服务注册发现和客户端负载均衡（如 gRPC、Spring Cloud LoadBalancer、Service Mesh Sidecar）选择实例，关注的是低延迟、熔断和重试。第三层是数据库层负载均衡，例如 MySQL 读写分离中间件、ProxySQL 或数据库代理，把读请求分发到多个只读副本，写请求路由到主库，同时处理连接池和故障切换。

这三层不是互相替代，而是叠加关系。入口层解决“用户请求怎么进来”，服务间解决“内部调用怎么选实例”，数据库层解决“数据访问怎么分摊”。任何一层缺失，都可能在流量上涨时成为瓶颈。

与高可用、弹性伸缩的关系

高可用和弹性伸缩都依赖负载均衡作为“稳定入口”。高可用的典型做法是：入口层自身做双机热备或集群，后端至少两个实例，健康检查周期设为 2 秒、失败阈值 3 次、成功阈值 2 次。当某台后端连续 3 次探测失败，调度器将其权重置零或直接摘除，新连接不再分配过去；恢复后连续 2 次成功再重新加入。弹性伸缩则依赖负载均衡器提供的连接数、QPS、响应时间等指标触发扩容。例如，当平均 CPU 超过 70% 持续 3 分钟，自动增加 2 个实例，注册到后端池后自动开始接收流量。

需要特别注意的是，负载均衡器本身也可能成为单点。因此入口层通常采用主备（Active-Standby）或集群（如 LVS + Keepalived、云 LB 多可用区）部署。主备切换时间、连接同步机制、VIP 漂移，都是后续章节会展开的工程细节。

本课程学习地图

本课程围绕“真实流量接入与连接分发任务”展开，整体分为五个阶段。第一阶段建立全景认知，理解三层部署位置和核心指标。第二阶段深入四层与七层负载均衡原理，包括 LVS 的 DR/NAT/TUN 模式、Nginx 的 upstream 配置、HAProxy 的 frontend/backend 结构。第三阶段聚焦调度算法，从轮询、加权轮询、最少连接、一致性哈希到动态反馈调度，结合参数计算和效果对比。第四阶段处理连接级问题：会话保持、连接池、超时、重试、熔断、慢启动。第五阶段进入实战排障与容量规划，包括健康检查误判、长连接不均、后端雪崩、灰度发布等真实场景。

学习过程中，你会反复接触几个关键对象：VIP、后端池、健康检查、调度算法、连接状态表、权重、超时时间。它们之间的关系可以用一句话概括：流量从 VIP 进入，经过调度算法选择后端，健康检查决定谁可用，连接状态表记录谁在服务，权重和超时控制分配比例与回收节奏。理解这条链路，后续所有配置和排障都会变得有据可依。