负载均衡器是现代系统架构的关键组件，能够智能地将流量分配到多台服务器。本文详细介绍什么是负载均衡器、常用的负载均衡算法、健康检查、会话持久性以及实际部署架构。
什么是负载均衡器？
负载均衡器（Load Balancer）是位于客户端和服务器组（服务器池/服务器集群）之间的设备或软件，负责将来自用户的请求分配到后端服务器，使负载均匀分布——防止任何单台服务器过载而其他服务器闲置。
当您的网站或应用程序不断增长，用户流量持续增加时，单台服务器将无法处理所有请求。这时负载均衡器就派上用场了——它智能地将流量分配到多台服务器，确保系统始终稳定且响应迅速。
现实生活类比
想象一家有5个收银台的餐厅。如果所有顾客都排在同一个收银台，等待时间会非常长，尽管其他4个收银台空闲。负载均衡器就像引导顾客到最空闲收银台的引导员，确保所有收银台都在工作，顾客等待时间最短。
高速代理 - 准备试用？
ALGO Proxy 提供住宅、数据中心和 4G 代理，覆盖 195+ 国家
为什么需要负载均衡器？
高可用性
如果只有一台服务器且它发生故障，整个服务将停止运行。有了负载均衡器：
- 流量自动重定向到其余健康的服务器。
- 系统可以承受一台或多台服务器故障而不影响用户。
- 可以实现99.99%或更高的在线时间。
可扩展性
负载均衡器实现水平扩展——在流量增加时向池中添加新服务器，而不是升级现有硬件（垂直扩展）。水平扩展更加灵活且成本效益更高。
最佳性能
在服务器之间均匀分配负载确保：
- 没有服务器过载。
- 为所有用户提供稳定的响应时间。
- 最大化利用硬件资源。
零停机维护
您可以将单台服务器从池中移除进行维护或更新，而不影响服务。负载均衡器会自动将流量分配到其余服务器。
负载均衡器的类型
第4层负载均衡器（传输层）
在OSI模型的传输层（TCP/UDP）运行。基于源/目标IP和端口号等网络信息做出路由决策，不检查请求内容。
特点：
- 更快，因为不需要分析内容。
- 适合非HTTP服务（数据库、邮件、游戏服务器）。
- 不能基于URL路径或HTTP头部进行路由。
第7层负载均衡器（应用层）
在应用层运行，能够读取和分析HTTP请求内容。基于URL、头部、Cookie和请求体做出路由决策。
特点：
- 更灵活——可以将
/api路由到API服务器，将/images路由到图片服务器。 - 支持SSL终止、压缩和缓存。
- 由于需要内容检查，比第4层略慢。
- 最常用于Web应用程序。
全局服务器负载均衡（GSLB）
在全球级别分配流量，将用户路由到最近的数据中心。通常使用基于DNS的路由结合健康检查。
常用负载均衡算法
轮询（Round Robin）
按顺序循环分配请求：服务器1 → 服务器2 → 服务器3 → 服务器1 → ...
优点： 简单，易于实现。 缺点： 不考虑各服务器的实际容量。如果服务器配置不同，较弱的服务器会过载。
加权轮询（Weighted Round Robin）
类似轮询但为每台服务器分配权重。更强的服务器获得更高权重，接收更多请求。
示例：服务器A（权重5）、服务器B（权重3）、服务器C（权重2）→ 每10个请求中，A接收5个，B接收3个，C接收2个。
最少连接（Least Connections）
将请求发送到活跃连接最少的服务器。适合请求处理时间不均匀的场景——处理完成更早的服务器更快接收新请求。
加权最少连接（Weighted Least Connections）
将最少连接与权重相结合。同时考虑当前连接数和服务器容量。
IP哈希（IP Hash）
使用客户端IP的哈希值来确定服务器。相同的IP始终被导向同一台服务器——无需复杂的粘性会话机制即可确保会话持久性。
最快响应时间（Least Response Time）
将请求发送到响应时间最快且连接最少的服务器。最智能的算法，确保用户始终由最快的服务器服务。
随机（Random）
随机选择服务器。简单且在服务器数量大、流量高时出奇地有效（根据大数定律）。
算法对比表
| 算法 | 复杂度 | 最佳用例 | 感知会话 | 感知容量 |
|---|---|---|---|---|
| 轮询 | O(1) | 相同服务器，短请求 | 否 | 否 |
| 加权轮询 | O(1) | 不同配置的服务器 | 否 | 是（静态） |
| 最少连接 | O(n) | 请求处理时间不同 | 否 | 是（动态） |
| 加权最少连接 | O(n) | 不同服务器，多样请求 | 否 | 是（两者） |
| IP哈希 | O(1) | 需要会话持久性 | 是 | 否 |
| 最快响应时间 | O(n) | 要求最高性能 | 否 | 是（动态） |
健康检查——服务器健康监控
负载均衡器持续监控后端服务器的状态，确保只将流量发送到健康的服务器。
主动健康检查
负载均衡器主动定期向每台服务器发送检查请求（健康检查探针）：
- HTTP健康检查： 向特定端点（通常是
/health）发送GET请求，检查状态码是否为200。 - TCP健康检查： 验证TCP连接是否成功。
- 自定义检查： 测试更复杂的条件（数据库连接、磁盘空间、内存使用）。
被动健康检查
在处理实际请求时监控服务器的响应。如果服务器返回过多错误（5xx）或超时，负载均衡器将其标记为不健康。
故障处理
当服务器被标记为不健康时：
- 负载均衡器停止向该服务器发送新请求。
- 当前请求可能在另一台服务器上重试。
- 健康检查继续运行——当服务器恢复时，负载均衡器自动将其添加回池中。
会话持久性（粘性会话）
某些应用程序要求来自同一用户的所有请求必须发送到同一台服务器（例如：购物车、登录会话）。几种处理方法：
基于Cookie
负载均衡器在响应中添加包含服务器信息的Cookie。后续携带此Cookie的请求被发送到同一台服务器。
源IP绑定
使用客户端IP绑定到特定服务器（类似IP哈希）。
应用层解决方案
最佳方案是设计无状态应用——将会话数据存储在共享存储（Redis、数据库）中而不是服务器上。这样，任何服务器都可以处理任何请求。
常用负载均衡器解决方案
软件负载均衡器
-
Nginx： 兼具Web服务器、反向代理和负载均衡器功能。高性能，配置灵活，免费。当前最流行的选择。
-
HAProxy： 专用负载均衡器，性能极高。被GitHub、Stack Overflow等大公司使用。
-
Traefik： 为容器环境（Docker、Kubernetes）设计。自动发现和配置服务。
-
Envoy： 由Lyft开发的现代微服务架构代理。常用作服务网格中的边车代理。
云负载均衡器
-
AWS弹性负载均衡（ELB）： 应用负载均衡器（ALB）用于第7层，网络负载均衡器（NLB）用于第4层。
-
Google Cloud负载均衡： 支持全局负载均衡，自动扩展。
-
Azure负载均衡器： 与Azure生态系统集成。
硬件负载均衡器
- F5 BIG-IP： 具有高级性能和安全功能的企业解决方案。
- Citrix ADC： 面向大型企业的应用交付控制器。
负载均衡器与代理
负载均衡器与代理有密切关系：
反向代理作为负载均衡器
Nginx和HAProxy同时充当反向代理和负载均衡器。它们接收客户端请求，确定合适的后端服务器并转发请求——这正是反向代理与负载均衡算法相结合的功能。
代理负载均衡
在使用代理的系统中（网页爬虫、广告验证），负载均衡器将请求分配到不同的代理以优化性能并避免单个代理过载。TMProxy集成了内部负载均衡机制，自动将请求分配到超过1000万个IP的代理池中。
实际部署架构
单负载均衡器
最简单的架构——一个负载均衡器在多台服务器前面。缺点：负载均衡器是单点故障。
主动-被动（故障转移）
两个负载均衡器——一个主动处理流量，一个被动待命。当主动发生故障时，被动自动接管（故障转移）。
主动-主动
两个负载均衡器都处于活跃状态，共享流量。比主动-被动更好地利用资源，并消除单点故障。
监控与关键指标
有效运营负载均衡器需要全面的监控。以下是最需要跟踪的关键指标：
每秒请求数（RPS）
负载均衡器每秒处理的请求数量。此指标表明系统当前的负载，并帮助预测何时需要扩展。随时间跟踪RPS以识别流量模式并相应地规划容量。
活跃连接数
每台后端服务器上的并发活跃连接数。如果一台服务器的活跃连接数异常高于其他服务器，可能需要调整均衡算法，或该服务器正在经历请求处理缓慢。
错误率
失败请求（HTTP 4xx和5xx）的百分比。错误率突然飙升可能表明：后端服务器故障、部署问题或系统过载。当错误率超过正常阈值（通常为1-5%）时设置告警。
响应时间（p50、p95、p99）
响应时间百分位数比平均值更重要。p50显示大多数用户的体验，p95揭示最慢5%用户的体验，p99捕获严重的异常值。如果p99比p50高出许多倍，系统存在尾延迟问题。
后端健康状态
每台后端服务器的健康检查状态：健康、不健康或排空中。跟踪健康状态历史有助于检测"抖动"服务器（在健康和不健康之间不断切换）——这是硬件或配置问题的信号。
带宽（吞吐量）
每秒通过负载均衡器的数据量（字节）。监控带宽确保不超过网络接口限制，并帮助在需要时规划升级。异常的带宽模式可能表明DDoS攻击或数据泄露。
常用监控工具： Prometheus + Grafana是负载均衡器监控中使用最广泛的组合。Datadog、New Relic和AWS CloudWatch也是云环境中的热门选择。
真实案例研究
Netflix——全球规模的负载均衡
Netflix为全球超过2亿用户提供服务，使用多层负载均衡架构。在全球层，Netflix使用基于DNS的负载均衡将用户路由到最近的AWS区域。在区域层，Zuul（他们自主开发的API网关）充当第7层负载均衡器，将请求分发到数千个微服务实例。Netflix还开发了Eureka用于服务发现和Ribbon用于客户端负载均衡，使每个服务能够在调用其他服务时自行进行负载均衡。
GitHub——为数百万开发者提供的HAProxy
GitHub使用HAProxy作为主要负载均衡器，每天处理数百万次git操作和Web请求。选择HAProxy是因为其极高的性能和处理数十万并发连接的能力。GitHub部署了多个HAProxy实例的主动-主动架构，结合自定义健康检查确保流量仅路由到正常运行的服务器。维护期间，通过负载均衡器优雅地排空各服务器的流量。
电商闪购——处理流量高峰
在闪购活动期间（双十一、黑色星期五），流量可能在几秒内飙升到正常水平的10-50倍。电商平台使用多层负载均衡策略：全局负载均衡器跨数据中心分配、应用负载均衡器跨服务器组分配（产品目录、购物车、支付），每个组根据负载均衡器指标自动扩展。队列系统（Redis、RabbitMQ）位于负载均衡器之后，对支付处理等敏感服务进行流量节流。
总结： 负载均衡器是现代系统架构的基本组件，确保应用始终可用、快速且可扩展。无论您运营的是小型网站还是复杂的微服务系统，了解负载均衡将帮助您设计稳健的基础设施，准备好应对任何级别的流量。