一、什么是负载均衡
负载均衡是位于客户端和后端服务之间的流量分发组件。它接收用户请求，根据预先配置的规则，把请求转发到多个后端实例，同时通过健康检查、连接管理和故障摘除提升服务的可用性。
最简单的负载均衡是“把请求平均分给多台服务器”，但生产环境远不止如此。真实系统还需要处理连接复用、会话保持、慢实例、灰度发布、跨可用区、TLS 终止、长连接、重试、限流和故障切换。
一句话概括：负载均衡的核心不是平均分流，而是在服务实例不断变化和部分故障的情况下，持续把请求送到合适的后端。
二、为什么需要负载均衡
1. 避免单点故障
如果所有请求只进入一台服务器，服务器宕机、进程崩溃或网络中断都会直接造成服务不可用。负载均衡可以把流量分散到多个实例，并在实例故障时停止转发请求。
2. 提升整体吞吐能力
当单个实例的 CPU、内存、连接数或网络带宽达到瓶颈时，可以增加实例数量，由负载均衡器把请求分摊到服务池中。
3. 支持弹性扩缩容
云环境中的实例数量可能随业务高峰和低谷变化。负载均衡器可以作为稳定入口，让后端实例增加或减少时，客户端不需要改变访问地址。
4. 隔离故障实例
健康检查发现某个实例无法正常工作后，负载均衡器可以将其从服务池中摘除，避免大量请求继续发送到故障节点。
5. 承担部分网络和安全职责
负载均衡器还可以完成 TLS 证书终止、访问控制、连接限制、请求路由、基础限流和七层协议处理，减轻后端服务压力。
三、四层负载均衡与七层负载均衡
1. 四层负载均衡
四层负载均衡工作在传输层，主要依据 IP、端口、协议和连接状态进行转发，常见协议包括 TCP 和 UDP。
它通常不理解 HTTP 请求内容，因此转发路径短、性能高、延迟低，适合数据库代理、游戏连接、RPC、TCP 长连接和高吞吐场景。
优点：
- 转发效率高，处理逻辑相对简单。
- 可以支持非 HTTP 协议。
- 对应用内容耦合较少。
局限：
- 不能根据 URL、Host、Cookie 和请求头路由。
- 很难直接理解业务状态。
- 会话、重试和错误处理更多依赖后端应用。
2. 七层负载均衡
七层负载均衡工作在应用层，通常能够解析 HTTP 或 HTTPS 请求，并依据域名、路径、请求头、Cookie、方法和参数进行路由。
例如：
/api转发到 API 服务。/static转发到静态资源服务。test.example.com转发到测试版本。- 带有特定 Cookie 的用户进入灰度实例。
优点：
- 路由规则灵活，适合微服务和灰度发布。
- 可以实现 TLS 终止、请求改写和应用层限流。
- 更容易结合业务指标和请求内容治理流量。
局限：
- 需要解析应用协议，资源消耗和配置复杂度更高。
- HTTPS 解密会增加 CPU 和证书管理成本。
- 配置错误可能造成路径遗漏、循环转发或安全问题。
四、常见负载均衡算法
1. 轮询
轮询按照顺序把请求分配给后端实例，配置简单，适合实例性能相近、请求耗时比较均匀的场景。
问题是它不关注实例当前负载。如果某个实例处理慢请求较多，轮询仍可能继续向它发送相同数量的新请求。
2. 加权轮询
为不同实例配置不同权重，性能更强的实例承担更多流量。适合新旧机器混合、节点规格不同或灰度发布初期。
3. 最少连接
负载均衡器优先把新请求发给当前连接数较少的实例，适合请求耗时差异较大或连接保持时间较长的场景。
它也不是万能的，因为连接数量不等于 CPU 使用率，某个连接很少的实例也可能正在处理高成本任务。
4. 加权最少连接
将连接数和实例权重结合起来，更适合后端规格不一致的服务池。
5. 一致性哈希
根据客户端 IP、用户 ID、请求键或其他字段计算哈希，将相同键尽量分配到相同实例。它适合缓存、本地会话和需要一定访问粘性的场景。
局限是实例变化、热点键和数据倾斜可能导致负载不均。对关键会话数据，仍建议使用共享存储或集中式会话系统，而不是完全依赖本地粘性。
6. 基于业务指标的调度
更高级的系统会综合延迟、错误率、CPU、队列长度、并发数和业务容量进行调度。这类策略效果更好，但需要指标准确、采集及时，并且要防止指标抖动造成频繁切换。
五、健康检查怎么设计
健康检查决定一个实例是否继续接收流量，是负载均衡最容易被低估的部分。
1. TCP 检查
只检查端口是否能建立连接。它能发现进程未监听或网络不可达，但不能证明应用真的可以正常提供服务。
2. HTTP 检查
访问指定 URL，并检查状态码、响应内容或响应时间。它比 TCP 检查更接近真实业务，但检查接口必须足够轻量，不能每次都访问数据库或调用外部服务。
3. 深度健康检查
可以进一步检查关键依赖，例如数据库、缓存和消息队列。但深度检查不能无限扩展，否则依赖服务短暂波动时，可能引发大规模实例同时摘除。
4. 检查参数
需要合理设置检查间隔、超时时间、连续失败次数和恢复阈值。失败阈值过低会导致误摘除，过高则会让故障流量持续进入异常实例。
六、会话保持与无状态服务
1. 为什么会需要会话保持
某些旧系统把登录状态、购物车或临时数据保存在本地内存中。如果用户下一次请求被转发到另一台实例，就可能出现登录失效或数据丢失，因此需要把同一个用户尽量发送到同一实例。
2. 常见方式
- Cookie 粘性：由负载均衡器或应用写入 Cookie。
- 源地址哈希：根据客户端 IP 选择实例。
- 用户键哈希：根据用户 ID 等业务键进行分配。
3. 更推荐的方式
从长期架构看，应用最好设计为无状态，把会话、令牌和临时数据放入共享存储或集中式会话服务。这样更利于扩容、故障转移和跨区域部署。
七、负载均衡与高可用设计
负载均衡器自身也不能成为单点。常见高可用方式包括：
- 部署两个或多个负载均衡节点。
- 使用虚拟 IP、BGP、DNS 或云厂商托管入口实现故障切换。
- 将节点分布到不同可用区。
- 对配置、证书和路由规则进行版本管理与备份。
- 监控入口错误率、连接数、后端延迟和健康实例数量。
需要特别关注“后端全部健康但入口不可用”和“入口可用但后端全部异常”这两类故障，它们的排查路径不同。
八、典型使用场景
Web 网站
使用七层负载均衡按域名和路径分发请求，并在入口完成 HTTPS 终止、基础限流和静态资源路由。
微服务系统
根据服务名、路径或请求头把流量发送到不同服务版本，同时配合服务发现和健康检查完成实例上下线。
数据库与 TCP 服务
使用四层负载均衡或数据库代理承载 TCP 连接，重点关注连接池、主从切换、读写分离和长连接超时。
灰度发布
根据 Cookie、请求头、用户标签或流量比例，将一小部分用户发送到新版本，观察错误率和延迟后再逐步扩大范围。
多可用区部署
优先把用户请求转发到本地可用区，在局部故障时切换到其他可用区，同时权衡跨区流量费用和访问延迟。
九、常见问题与排障顺序
问题一：后端实例健康，但用户仍然访问失败
按客户端 DNS、网络路由、安全组、负载均衡监听器、证书、路由规则、后端端口和应用日志的顺序排查。
问题二：只有部分用户访问失败
重点检查 Cookie 粘性、源地址哈希、灰度规则、某一可用区、某一后端实例和缓存状态。
问题三：负载分配明显不均
检查算法、权重、长连接、连接复用、会话保持和实例规格差异。不能只看请求数，还应比较并发数、响应时间、CPU 和错误率。
问题四：扩容后流量没有进入新实例
检查实例是否注册成功、健康检查是否通过、服务端口是否正确、权重是否为零，以及负载均衡器配置是否已经生效。
问题五：偶发 502、504
分别检查连接建立失败、后端主动断开、响应超时、上游队列、应用线程池、数据库慢查询和网络丢包。只重启后端通常不能解决根因。
十、局限性与使用建议
负载均衡不能自动修复业务 Bug、数据库瓶颈、错误的超时配置和不合理的重试策略。它还可能引入额外延迟、连接状态、证书管理和配置复杂度。
使用时建议：
- 先明确是四层还是七层需求。
- 让健康检查代表“可以接收业务流量”，而不是只代表端口打开。
- 对超时、重试和连接池设置统一策略，避免重试风暴。
- 将路由、证书和后端注册配置纳入版本管理。
- 同时监控入口、负载均衡器、后端服务和关键依赖。
- 用故障演练验证摘除、恢复和跨可用区切换是否符合预期。
十一、总结
云计算负载均衡是连接用户流量和后端服务的关键基础设施。四层负载均衡强调高性能和协议透明，七层负载均衡强调内容路由和应用治理；轮询、最少连接和一致性哈希解决不同的流量分配问题；健康检查、会话设计和多节点高可用决定了系统能否真正稳定运行。
理解负载均衡，不能只记住几个算法名称，更要理解它在云环境中的完整职责：接入流量、选择实例、发现故障、控制连接、支持扩容，并为服务连续性提供基础保障。
