架构之服务器负载均衡（SLB）
架构之服务器负载均衡（SLB）
目录
概述
什么是服务器负载均衡（SLB）
服务器负载均衡（Server Load Balancing，简称SLB）是一种将网络流量分配到多台服务器的技术，旨在优化资源使用、最大化吞吐量、最小化响应时间，并避免任何单点故障。
为什么需要负载均衡
在现代分布式系统中，单台服务器的能力有限，无法满足高并发、高可用性的业务需求。负载均衡通过以下方式解决这些问题：
- 水平扩展：通过添加更多服务器来提升系统整体处理能力
- 高可用性：当某台服务器故障时，流量自动转移到健康服务器
- 流量分发：根据不同策略智能分配请求，优化资源利用率
- 安全防护：隐藏后端服务器真实IP，提供DDoS防护能力
负载均衡在架构中的位置
客户端 → DNS → 负载均衡器 → 后端服务器集群
负载均衡器通常位于网络边缘，作为流量的入口点，是连接外部客户端与内部服务集群的关键组件。
核心概念
虚拟IP（VIP）
虚拟IP（Virtual IP）是负载均衡器对外提供服务的IP地址。客户端通过访问VIP来使用服务，而不需要知道后端真实服务器的IP地址。
真实服务器（RS）
真实服务器（Real Server）是实际处理业务请求的后端服务器。负载均衡器将接收到的请求转发给这些服务器。
转发模式
1. NAT模式（Network Address Translation）
在NAT模式下，负载均衡器修改请求和响应的IP地址：
- 请求：客户端IP → 负载均衡器IP（修改为负载均衡器IP）→ 真实服务器
- 响应：真实服务器 → 负载均衡器（修改为负载均衡器IP）→ 客户端
特点：
- 真实服务器需要配置默认网关为负载均衡器
- 负载均衡器成为瓶颈，处理所有流量
- 适用于小型部署
2. DR模式（Direct Routing）
在DR模式下，负载均衡器只修改请求的MAC地址，不修改IP地址：
- 请求：客户端IP → 负载均衡器（修改MAC地址）→ 真实服务器
- 响应：真实服务器直接返回给客户端（绕过负载均衡器）
特点：
- 真实服务器需要配置VIP在lo接口上，并抑制ARP响应
- 负载均衡器只处理入站流量，性能高
- 要求负载均衡器和真实服务器在同一物理网络
3. TUN模式（IP Tunneling）
在TUN模式下，负载均衡器将请求封装在IP隧道中发送给真实服务器：
- 请求：客户端IP → 负载均衡器（封装）→ 真实服务器（解封装）
- 响应：真实服务器直接返回给客户端
特点：
- 真实服务器可以跨物理网络部署
- 需要IP隧道支持
- 配置复杂度较高
负载均衡算法
1. 轮询（Round Robin）
将请求依次分配给每台服务器。
请求1 → 服务器A
请求2 → 服务器B
请求3 → 服务器C
请求4 → 服务器A
...
优点：
- 实现简单
- 服务器负载相对均衡
缺点：
- 不考虑服务器实际负载
- 不考虑服务器处理能力差异
适用场景：服务器性能相近、请求处理时间相似的场景
2. 加权轮询（Weighted Round Robin）
根据服务器权重分配请求，权重高的服务器获得更多请求。
服务器A（权重3）：请求1、4、7、10...
服务器B（权重2）：请求2、5、8、11...
服务器C（权重1）：请求3、6、9、12...
优点：
- 可以根据服务器性能分配不同权重
- 灵活性高
适用场景：服务器性能不均衡的场景
3. 最少连接（Least Connections）
将请求分配给当前连接数最少的服务器。
服务器A：100个连接
服务器B：150个连接
服务器C：80个连接
新请求 → 服务器C
优点：
- 动态考虑服务器负载
- 适合长连接场景
适用场景：请求处理时间差异较大的场景
4. 加权最少连接（Weighted Least Connections）
结合服务器权重和当前连接数进行分配。
计算公式：
选择服务器 = min(当前连接数 / 权重)
5. 源地址哈希（Source Hash）
根据客户端IP地址的哈希值分配请求，确保同一客户端的请求总是分配到同一台服务器。
hash(client_ip) % 服务器数量 = 目标服务器
优点：
- 会话保持简单
- 适合有状态服务
缺点：
- 可能导致负载不均
适用场景：需要会话保持的场景
6. 一致性哈希（Consistent Hash）
使用一致性哈希环进行分配，当服务器数量变化时，只影响部分请求。
优点：
- 服务器增删时影响范围小
- 适合分布式缓存场景
适用场景：分布式缓存、会话保持要求高的场景
负载均衡层次
四层负载均衡（Layer 4）
基于传输层（TCP/UDP）信息进行负载均衡，主要根据IP地址和端口号进行分发。
特点：
- 性能高，延迟低
- 只检查IP和端口信息
- 无法识别应用层内容
协议支持：TCP、UDP、SCTP
典型产品：LVS、HAProxy（四层模式）、F5（四层模式）
工作流程：
客户端 → [SYN] → 负载均衡器 → [SYN] → 真实服务器
客户端 ← [SYN-ACK] ← 负载均衡器 ← [SYN-ACK] ← 真实服务器
客户端 → [ACK] → 负载均衡器 → [ACK] → 真实服务器
七层负载均衡（Layer 7）
基于应用层（HTTP/HTTPS）信息进行负载均衡，可以根据URL、HTTP头、Cookie等信息进行分发。
特点：
- 功能强大，灵活性高
- 可以进行内容路由
- 性能相对较低
协议支持：HTTP、HTTPS、SMTP、FTP等
典型产品：Nginx、HAProxy（七层模式）、F5（七层模式）、AWS ALB
工作流程：
客户端 → [HTTP请求] → 负载均衡器（解析HTTP）→ [HTTP请求] → 真实服务器
客户端 ← [HTTP响应] ← 负载均衡器 ← [HTTP响应] ← 真实服务器
七层负载均衡能力：
- 基于URL路径的路由
- 基于HTTP头的路由
- 基于Cookie的会话保持
- SSL/TLS卸载
- 请求重写和重定向
- 压缩和缓存
硬件与软件负载均衡
硬件负载均衡器
代表产品：
- F5 BIG-IP
- A10 Networks
- Citrix NetScaler
- Radware
优点：
- 性能强大：专用硬件，ASIC芯片加速
- 功能全面：提供丰富的负载均衡和安全功能
- 稳定性高：经过大规模生产环境验证
- 技术支持：厂商提供专业技术支持
缺点：
- 成本高昂：硬件采购和维护成本高
- 扩展性有限：硬件规格固定，扩展需要购买新设备
- 部署周期长：需要采购、安装、配置
- 厂商锁定：依赖特定厂商的技术栈
适用场景：
- 大型企业核心业务
- 对性能和稳定性要求极高的场景
- 有充足预算的机构
软件负载均衡器
代表产品：
- Nginx
- HAProxy
- LVS（Linux Virtual Server）
- Envoy
- Traefik
优点：
- 成本低：开源免费或低成本许可
- 灵活性强：可运行在通用服务器上，易于部署
- 可扩展性好：可以通过增加服务器数量横向扩展
- 社区活跃：开源社区支持，更新迭代快
- 云原生友好：适合容器化和微服务架构
缺点：
- 性能相对较低：通用硬件处理能力有限
- 稳定性依赖运维：需要专业的运维团队
- 功能可能不完整：部分高级功能需要额外开发
适用场景：
- 互联网公司
- 云原生和微服务架构
- 成本敏感的项目
- 需要快速迭代和灵活部署的场景
健康检查与故障转移
健康检查机制
健康检查是负载均衡器判断后端服务器是否正常工作的关键机制。
1. TCP连接检查
尝试与后端服务器建立TCP连接。
负载均衡器 → [SYN] → 真实服务器
负载均衡器 ← [SYN-ACK] ← 真实服务器
负载均衡器 → [ACK] → 真实服务器
连接成功 → 服务器健康
特点：
- 检查速度快
- 只能确认网络层面可用性
- 无法确认应用是否正常
2. HTTP检查
发送HTTP请求到指定路径，检查响应状态码。
GET /health HTTP/1.1
Host: backend-server
HTTP/1.1 200 OK
Content-Type: application/json
{"status": "healthy"}
特点：
- 可以检查应用层健康状态
- 可以自定义检查逻辑
- 检查开销相对较大
3. SSL/TLS检查
验证SSL证书和TLS连接。
特点：
- 适用于HTTPS服务
- 可以检查证书有效期
- 确保加密通信正常
健康检查参数
| 参数 | 说明 | 典型值 |
|---|---|---|
| 检查间隔 | 两次健康检查之间的时间间隔 | 5-30秒 |
| 超时时间 | 等待响应的最大时间 | 2-10秒 |
| 失败阈值 | 连续失败多少次标记为不健康 | 2-5次 |
| 成功阈值 | 连续成功多少次标记为健康 | 2-3次 |
故障转移流程
1. 健康检查失败 → 标记服务器为不健康
2. 停止向不健康服务器分发新请求
3. 已有连接根据策略处理（等待完成或立即断开）
4. 服务器恢复健康 → 标记为健康
5. 恢复向服务器分发请求
优雅下线
当需要维护或升级服务器时，可以通过优雅下线避免服务中断：
1. 标记服务器为维护状态
2. 停止接收新请求
3. 等待现有请求处理完成
4. 执行维护操作
5. 恢复服务
会话保持
为什么需要会话保持
在无状态的HTTP协议中，某些业务场景需要保持客户端与特定服务器的会话状态：
- 用户登录状态存储在服务器内存中
- 购物车信息保存在服务器端
- WebSocket长连接
- 有状态的业务逻辑
会话保持实现方式
1. 基于源IP的会话保持
根据客户端IP地址的哈希值进行路由。
优点：
- 实现简单
- 不需要客户端配合
缺点：
- NAT环境下多个用户共享同一IP
- IP变化会导致会话丢失
- 可能导致负载不均
2. 基于Cookie的会话保持
负载均衡器在首次响应时插入Cookie，后续请求根据Cookie路由。
流程：
首次请求：
客户端 → 负载均衡器 → 服务器A
客户端 ← Set-Cookie: SERVERID=A ← 负载均衡器 ← 服务器A
后续请求：
客户端 → Cookie: SERVERID=A → 负载均衡器 → 服务器A
优点：
- 精确的会话保持
- 不受NAT影响
缺点：
- 客户端必须支持Cookie
- Cookie可能被禁用
3. 基于HTTP头的会话保持
使用自定义HTTP头进行会话标识。
优点：
- 不依赖Cookie
- 灵活性高
缺点：
- 需要客户端配合
- 实现复杂度较高
4. 会话复制（Session Replication）
在服务器之间复制会话状态，任意服务器都可以处理请求。
实现方式：
- 内存复制（如Tomcat集群）
- 分布式缓存（如Redis）
- 数据库存储
优点：
- 真正的无状态
- 服务器故障不影响会话
缺点：
- 实现复杂
- 数据一致性挑战
- 性能开销
会话保持最佳实践
- 优先使用无状态设计：将会话状态存储在外部存储（Redis、数据库）
- 合理设置会话超时：避免长时间占用资源
- 考虑会话迁移：支持会话在不同服务器间迁移
- 监控会话分布：确保负载均衡
常见实现方案
1. LVS（Linux Virtual Server）
LVS是Linux内核级的四层负载均衡解决方案。
工作模式
| 模式 | 网络层 | 特点 | 适用场景 |
|---|---|---|---|
| NAT | 四层 | 修改IP地址，性能中等 | 小规模部署 |
| DR | 四层 | 修改MAC地址，性能高 | 大规模部署 |
| TUN | 四层 | IP隧道，跨网络 | 跨机房部署 |
调度算法
- 轮询（rr）
- 加权轮询（wrr）
- 最少连接（lc）
- 加权最少连接（wlc）
- 源地址哈希（sh）
- 目标地址哈希（dh）
优点
- 内核级实现，性能极高
- 稳定可靠，广泛使用
- 开源免费
缺点
- 配置相对复杂
- 功能相对简单
- 不支持七层负载均衡
2. HAProxy
HAProxy是高性能的四层和七层负载均衡器。
特性
- 支持四层（TCP）和七层（HTTP）负载均衡
- 丰富的健康检查机制
- 会话保持
- SSL/TLS卸载
- 详细的监控统计
- 配置灵活
配置示例
frontend web_front
bind *:80
default_backend web_servers
backend web_servers
balance roundrobin
server s1 192.168.1.10:80 check
server s2 192.168.1.11:80 check
server s3 192.168.1.12:80 check
优点
- 性能优秀
- 功能全面
- 配置相对简单
- 社区活跃
缺点
- 单进程模型（新版本支持多线程）
- 配置语法学习曲线
3. Nginx
Nginx是轻量级的高性能Web服务器和反向代理。
特性
- 七层负载均衡
- 反向代理
- 静态文件服务
- SSL/TLS卸载
- 限流和访问控制
- 模块化架构
配置示例
upstream backend {
least_conn;
server backend1.example.com weight=3;
server backend2.example.com;
server backend3.example.com backup;
keepalive 32;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
优点
- 轻量级，资源占用少
- 配置简单
- 功能丰富
- 广泛使用
缺点
- 四层负载均衡功能较弱（需要stream模块）
- 动态配置能力有限
4. 云厂商负载均衡服务
AWS
- ALB（Application Load Balancer）：七层负载均衡
- NLB（Network Load Balancer）：四层负载均衡
- CLB（Classic Load Balancer）：传统负载均衡
阿里云
- SLB（Server Load Balancer）：四层和七层负载均衡
- 支持传统型和应用型
腾讯云
- CLB（Cloud Load Balancer）：四层和七层负载均衡
优点
- 托管服务，无需运维
- 高可用性
- 自动扩展
- 与云服务集成
缺点
- 成本较高
- 厂商锁定
- 配置灵活性有限
架构设计最佳实践
1. 多级负载均衡
对于大规模系统，采用多级负载均衡架构：
客户端
↓
DNS负载均衡（GSLB）
↓
数据中心入口负载均衡（L4）
↓
服务集群负载均衡（L7）
↓
后端服务器
优点：
- 分层处理，每层专注不同职责
- 故障隔离
- 灵活扩展
2. 跨数据中心负载均衡
使用全局服务器负载均衡（GSLB）实现跨数据中心流量分发：
实现方式：
- DNS轮询
- Anycast
- CDN智能调度
考虑因素：
- 地理位置就近
- 数据中心健康状态
- 流量成本
- 合规要求
3. 混合负载均衡
结合硬件和软件负载均衡的优势：
硬件负载均衡器（入口）
↓
软件负载均衡器集群
↓
后端服务器
优点：
- 硬件处理入口流量，提供高可用
- 软件处理内部流量，提供灵活性
- 成本和性能平衡
4. 容器化环境负载均衡
在Kubernetes等容器编排平台中：
组件：
- Ingress Controller：七层负载均衡
- Service：四层负载均衡
- Service Mesh（如Istio）：服务网格负载均衡
特点：
- 动态服务发现
- 自动配置
- 流量管理
5. 高可用设计
负载均衡器高可用
- 主备模式（Active-Standby）
- 主主模式（Active-Active）
- VRRP协议实现虚拟IP漂移
网络冗余
- 多网络路径
- 多ISP接入
- BGP路由优化
6. 安全设计
DDoS防护
- 流量清洗
- 限流和黑名单
- CDN防护
访问控制
- IP白名单/黑名单
- 地理位置限制
- 基于签名的访问控制
SSL/TLS配置
- 使用强加密算法
- 定期更新证书
- 启用HSTS
监控与运维
关键监控指标
1. 流量指标
- QPS（每秒查询数）
- 并发连接数
- 网络带宽使用率
- 请求/响应字节数
2. 性能指标
- 响应时间（平均、P50、P95、P99）
- 请求成功率
- 错误率（4xx、5xx）
3. 后端服务器指标
- 服务器健康状态
- 服务器连接数
- 服务器响应时间
- 服务器负载
4. 负载均衡器指标
- CPU使用率
- 内存使用率
- 网络连接数
- 新建连接速率
告警策略
| 指标 | 告警阈值 | 严重级别 |
|---|---|---|
| 服务器不健康 | > 1台 | 警告 |
| 服务器不健康 | > 50% | 严重 |
| 错误率 | > 5% | 警告 |
| 错误率 | > 10% | 严重 |
| 响应时间P99 | > 1秒 | 警告 |
| 响应时间P99 | > 3秒 | 严重 |
| QPS突增 | > 2倍正常值 | 警告 |
日志管理
访问日志
记录每个请求的详细信息：
$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"
错误日志
记录错误信息：
[error] 12345#0: *123456 upstream timed out (110: Connection timed out) while reading response header from upstream
日志分析
- 使用ELK（Elasticsearch、Logstash、Kibana）栈
- 实时监控和告警
- 趋势分析和容量规划
容量规划
评估方法
- 基准测试：测量单台服务器最大处理能力
- 峰值预估：根据业务增长预估峰值流量
- 冗余设计：预留30-50%的冗余容量
- 弹性扩展：支持自动扩缩容
扩容策略
- 水平扩展：增加服务器数量
- 垂直扩展：提升服务器配置
- 混合扩展：结合水平和垂直扩展
故障排查
常见问题
-
后端服务器响应慢
- 检查服务器负载
- 检查数据库性能
- 检查网络延迟
-
负载不均
- 检查负载均衡算法
- 检查服务器权重配置
- 检查会话保持设置
-
连接超时
- 检查超时配置
- 检查防火墙设置
- 检查网络连接
-
健康检查失败
- 检查健康检查配置
- 检查后端服务状态
- 检查网络连通性
排查工具
- tcpdump：抓包分析
- netstat/ss：连接状态
- curl：接口测试
- ab/wrk：压力测试
总结
服务器负载均衡是现代分布式系统的核心组件，对于保证系统的高可用性、高性能和可扩展性至关重要。
关键要点
- 选择合适的负载均衡层次：根据业务需求选择四层或七层负载均衡
- 选择合适的负载均衡算法：根据业务特点选择轮询、最少连接等算法
- 实现完善的健康检查：及时发现和处理故障节点
- 合理设计会话保持：在无状态设计和会话保持之间找到平衡
- 建立完善的监控体系：实时监控系统状态，及时发现问题
- 做好容量规划：预留足够的冗余容量，支持业务增长
- 制定应急预案：提前规划故障处理流程
技术选型建议
| 场景 | 推荐方案 |
|---|---|
| 小型应用 | Nginx |
| 中型应用 | HAProxy |
| 大型应用 | LVS + Nginx/HAProxy |
| 云原生应用 | Kubernetes Ingress + Service Mesh |
| 企业核心业务 | 硬件负载均衡器（F5等） |
| 跨云部署 | 云厂商负载均衡服务 |
负载均衡技术持续发展，随着云原生、微服务、边缘计算等新技术的兴起，负载均衡也在不断演进。
北京人形旗下天工造物具身智能开源社区，聚焦具身天工与慧思开物两大平台
更多推荐
11
0- 0
已为社区贡献16条内容
所有评论(0)