【架构实战】负载均衡架构:从四层到七层

一、为什么需要负载均衡

单机服务存在性能瓶颈和单点故障风险。负载均衡通过将请求分发到多台服务器,实现:

  • 水平扩展:通过增加机器提升整体处理能力
  • 高可用:某台服务器故障时自动剔除,不影响整体服务
  • 流量调度:根据服务器负载动态分配请求

二、负载均衡分层架构

复制代码
客户端请求
    ↓
DNS负载均衡(地理级别)
    ↓
四层负载均衡(IP+端口级别)
    ↓
七层负载均衡(应用层,基于URL/Cookie等)
    ↓
应用服务器集群

各层职责

层级 技术 调度维度 典型实现
DNS DNS轮询/智能解析 地理位置 DNSPod/Cloudflare
四层 L4 LB IP+端口 LVS/F5
七层 L7 LB URL/Header/Cookie Nginx/HAProxy

三、四层负载均衡详解

工作原理

四层负载均衡工作在传输层(TCP/UDP),根据IP和端口进行转发,不解析应用层协议。

复制代码
客户端 → L4 LB → 后端服务器
         (修改目标IP/端口)

LVS三种工作模式

1. NAT模式
复制代码
请求:Client → Director → RealServer
响应:RealServer → Director → Client

特点:请求和响应都经过Director,Director容易成为瓶颈

2. DR模式(Direct Routing)
复制代码
请求:Client → Director → RealServer
响应:RealServer → Client(直接返回)

特点:响应不经过Director,性能最好,但要求Director和RealServer在同一网段

bash 复制代码
# LVS DR模式配置示例
ipvsadm -A -t 192.168.1.100:80 -s wrr
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:80 -g -w 3
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g -w 2
3. TUN模式(IP隧道)

适用于跨网段场景,通过IP隧道封装实现。

四层调度算法

算法 说明 适用场景
rr 轮询 服务器性能相近
wrr 加权轮询 服务器性能不同
lc 最小连接数 长连接场景
wlc 加权最小连接数 综合考虑
sh 源地址哈希 会话保持

四、七层负载均衡详解

工作原理

七层负载均衡工作在应用层,可以解析HTTP/HTTPS协议,实现更精细的调度。

复制代码
客户端 → Nginx → 解析请求 → 选择后端 → 转发请求

Nginx配置实战

基础配置
nginx 复制代码
upstream backend {
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 backup;  # 备用服务器
    
    keepalive 32;  # 保持长连接数
}

server {
    listen 80;
    
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
基于URL的路由
nginx 复制代码
upstream api_servers {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

upstream static_servers {
    server 192.168.1.20:80;
    server 192.168.1.21:80;
}

server {
    listen 80;
    
    location /api/ {
        proxy_pass http://api_servers;
    }
    
    location /static/ {
        proxy_pass http://static_servers;
    }
}
基于Cookie的会话保持
nginx 复制代码
upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

map $cookie_route $backend_server {
    default backend;
    server1 192.168.1.10:8080;
    server2 192.168.1.11:8080;
}

server {
    listen 80;
    
    location / {
        proxy_pass http://$backend_server;
    }
}

健康检查

nginx 复制代码
upstream backend {
    server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
}

# 主动健康检查(需nginx-plus或tengine)
# health_check interval=5s fails=3 passes=2;

五、四层 vs 七层对比

维度 四层(L4) 七层(L7)
性能 高(内核态转发) 较低(用户态解析)
功能 简单(IP+端口) 丰富(URL/Header/Cookie)
健康检查 TCP连接检测 HTTP请求检测
SSL卸载 不支持 支持
适用场景 高并发入口 业务层路由

生产环境最佳实践

复制代码
客户端 → LVS(四层,高并发入口)
           ↓
        Nginx集群(七层,业务路由)
           ↓
        应用服务器集群

架构优势:

  • LVS处理高并发连接,性能极高
  • Nginx做业务路由、SSL卸载、健康检查
  • 各层各司其职,扩展性好

六、常见问题

Q1:为什么响应不经过LVS DR模式?

A:DR模式通过修改MAC地址转发,RealServer直接响应客户端,避免Director成为瓶颈。

Q2:七层负载均衡性能如何优化?

A:

  • 开启HTTP/2减少连接数
  • 使用连接池复用连接
  • 开启gzip压缩减少传输量
  • 使用缓存减少后端压力

Q3:如何实现跨机房负载均衡?

A:DNS智能解析 + 各机房独立LB集群 + 健康检查联动。

七、总结

负载均衡是分布式系统的基础设施:

  • 四层LB:高性能、简单转发,适合入口层
  • 七层LB:功能丰富、精细调度,适合业务层
  • 分层架构:四层+七层组合,发挥各自优势

选型建议:

  • 小规模:Nginx七层足够
  • 大规模:LVS + Nginx组合
  • 云环境:使用云厂商LB服务(ALB/CLB)

思考题:你的系统目前使用什么负载均衡方案?有没有遇到过性能瓶颈?


个人观点,仅供参考

相关推荐
mldong1 小时前
同一个节点接力办几轮,流程才往下走:jeeflow 的后加签
后端·架构
Z21-X1 小时前
云原生运维学习笔记:容器技术的演进、底层原理与 Docker 全生命周期管理
运维·笔记·学习·云原生
Decay__9 小时前
18_MySQL 智能巡检方案 —— 巡检项清单 / 一键巡检脚本 / 健康评分
运维·数据库·sql·mysql·架构
天远API14 小时前
零信任架构实战:基于天远运营商三要素详版V即时版构建自动化消费电子大促电商平台高价值权益秒杀与优惠券防羊毛高并发实名核验网关
运维·人工智能·架构·自动化
Android系统攻城狮14 小时前
Linux FFmpeg深度解析之avcodec_default_get_encode_buffer调用流程与实战(二十八)
linux·运维·服务器·ffmpeg·车载音视频·ffmpeg音视频
乐维_lwops15 小时前
案例解读:大型综合性科创产业园运维监控落地实践
运维·网络·人工智能·安全·it监控·国产运维智能体
这个DBA有点耶15 小时前
信创场景下数据同步软件怎么选?对比开源CDC与原生闭环工具的结构性差异
数据库·mysql·架构
番茄啊16 小时前
linux 开启xftp连接
linux·运维·服务器
IT利刃出鞘17 小时前
Docker Compose--解决修改配置后不生效的问题
运维·docker·容器
衡石科技17 小时前
衡石高性能分析架构:HQL、查询下推与多层加速的协同设计
架构·数据分析