在客户端和服务端架构里，负载均衡不是单纯“把请求分给多台机器”，它真正解决的是：流量入口、服务扩展、故障隔离和系统稳定性问题。
1. 先从单机服务说起
最简单的客户端服务端架构是这样的：
Client ---> Server用户打开网页、App 调接口，本质上都是客户端向服务端发送请求。
如果用户很少，一台服务器可能就够了。但当请求变多时，单机服务会遇到几个问题：
- CPU、内存、网络带宽不够。
- 一台机器挂掉，整个服务不可用。
- 发布、扩容、下线都很难不影响用户。
- 不同地区、不同网络的访问体验差异很大。
所以服务端通常会变成多台机器：
Client ---> Server A
---> Server B
---> Server C但这时候又出现新问题：客户端到底应该请求哪一台？
负载均衡就是为了解决这个问题。
2. 负载均衡的核心目标
负载均衡主要做几件事：
- 分摊流量：不要让所有请求都打到同一台服务器。
- 屏蔽后端细节：客户端只需要访问一个统一入口。
- 提高可用性：某台服务器挂了，就把流量摘掉。
- 方便扩容缩容：新增机器后，流量可以逐步分过去。
- 提升稳定性：配合限流、熔断、超时、重试减少故障扩散。
可以把负载均衡理解成一个“流量调度器”。
┌────────── Server A
Client -> │
│ Load Balancer -> Server B
│
└────────── Server C客户端不直接关心后面有几台服务器，它只访问负载均衡器。
3. 负载均衡出现在哪些位置
负载均衡不一定只有一个位置，它可能出现在不同层级。
DNS 负载均衡
用户访问域名时，DNS 可以返回不同 IP。
example.com -> 1.1.1.1
example.com -> 2.2.2.2优点是简单、入口靠前；缺点是 DNS 缓存会导致切换不够实时。
网关或反向代理负载均衡
比如 Nginx、API Gateway、云厂商负载均衡器。
Client -> Nginx / Gateway -> App Servers这是最常见的服务端入口负载均衡方式。
客户端负载均衡
客户端自己从服务注册中心拿到服务列表，然后选择一台服务调用。
Client -> Service Registry
Client -> Service A / B / C这种方式在微服务内部调用中比较常见。
服务网格负载均衡
服务网格会把流量治理能力放到 sidecar 或基础设施层里。
Service A -> Sidecar -> Sidecar -> Service B业务代码不用自己处理太多负载均衡细节，但系统复杂度也会变高。
4. 负载均衡不是平均分
很多初学者会把负载均衡理解成“平均分配请求”。
但真实系统里，不一定是平均才合理。
原因包括：
- 机器配置不同，有的机器更强。
- 请求复杂度不同，有的接口很重。
- 某些连接是长连接，不能只看请求数。
- 某台机器可能刚启动，需要预热。
- 某些用户需要会话保持，不能随便切机器。
所以负载均衡更准确地说是：
根据后端实例状态、流量特征和调度策略，把请求分配到合适的服务实例上。
5. 一个请求经过负载均衡的大致过程
假设用户访问一个网站：
浏览器
↓
DNS 解析域名
↓
负载均衡入口
↓
后端应用服务器
↓
数据库 / 缓存 / 消息队列负载均衡器通常会做这些判断：
- 后端实例是否健康。
- 这次请求应该转发给哪台机器。
- 是否需要保持同一个用户打到同一台机器。
- 后端超时或失败后要不要重试。
- 当前流量是否超过系统承受能力。
所以它不仅是转发请求，也承担一部分系统稳定性职责。
6. 初学时容易混淆的几个概念
负载均衡和反向代理
反向代理强调“代理服务端接收请求”，负载均衡强调“把请求分配到多个后端实例”。
很多工具同时具备这两个能力，比如 Nginx。
负载均衡和网关
网关通常是更综合的入口层，除了负载均衡，还可能负责认证、鉴权、限流、日志、协议转换。
负载均衡是网关可能具备的一种能力。
负载均衡和服务发现
服务发现负责回答“有哪些可用实例”。
负载均衡负责回答“这次请求选哪一个实例”。
7. 小结
负载均衡是分布式系统里非常基础的架构能力。
可以先这样理解：
- 单机服务扛不住流量，也不够可靠。
- 多实例部署后，需要一个流量调度机制。
- 负载均衡让客户端面对统一入口，后端可以横向扩展。
- 它不仅分摊流量，还要考虑健康检查、故障摘除、扩容缩容和稳定性。
后面继续看负载均衡算法时，不要只背轮询、随机这些名词，要结合“请求如何被分配到合适实例”来理解。
留言板