负载均衡技术：从DNS到F5的全栈解析

大家好，我是你们的讲师。今天我们来聊聊负载均衡——这个在高并发系统里，几乎绕不开的核心话题。

说实话，我见过太多系统崩在流量洪峰下的案例了。有一次，一个电商平台搞大促，流量瞬间暴涨了10倍。结果呢？单点扛不住，整个服务挂了。事后复盘，发现他们连最基本的负载均衡都没配好。嗯，今天我们就来把这几种技术彻底讲透。

DNS负载均衡：最上层的分流

DNS负载均衡，说白了就是通过域名解析来做流量分发。你访问一个域名，DNS服务器会返回多个IP地址中的一个。这样，不同用户就会访问到不同的服务器。

我个人习惯把DNS负载均衡叫做「地理级别的分流」。为什么？因为它可以根据用户的地理位置，返回最近的服务器IP。比如，你在北京，DNS就给你返回北京机房的IP；你在上海，就返回上海机房的。

核心特点：

  • 实现简单，不需要额外硬件
  • 支持全球范围的流量调度
  • 可以结合健康检查，自动剔除故障节点

但这里有个坑。我曾经遇到过一个问题：DNS缓存时间太长。你改了DNS记录，但用户可能要等几个小时才能生效。所以，做DNS负载均衡时，TTL值一定要设得短一些，比如60秒。这样切换才够快。

避坑指南：我曾经因为DNS缓存问题，导致流量切不过去，线上故障持续了半小时。后来我学乖了，每次变更前先降低TTL，等生效后再改回正常值。

Nginx反向代理：七层负载均衡的王者

Nginx，大家应该都不陌生。它工作在应用层（七层），能根据HTTP请求的内容来做路由。比如，你可以根据URL路径、请求头、Cookie等，把请求转发到不同的后端服务。

我举个例子。你有个电商系统，商品详情页和订单页是两组不同的服务。用Nginx，你可以这样配置：

upstream product_backend {
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
}

upstream order_backend {
    server 192.168.1.20:8080;
    server 192.168.1.21:8080;
}

server {
    listen 80;
    
    location /product/ {
        proxy_pass http://product_backend;
    }
    
    location /order/ {
        proxy_pass http://order_backend;
    }
}

你看，这样配置后，商品请求走product_backend，订单请求走order_backend。而且，我还给product_backend的两个节点配了权重，3:2的比例分发流量。

Nginx还有一个很实用的功能——健康检查。它会定期检查后端服务是否存活。如果某个节点挂了，Nginx会自动把它踢出负载池。这个功能我建议一定要开启，不然流量打到挂掉的节点上，用户就会看到502错误。

小技巧：我个人习惯在Nginx里配一个「备用节点」。当所有主节点都挂了时，流量自动切换到备用节点。虽然性能差一点，但至少服务不中断。

LVS四层负载均衡：内核级别的性能怪兽

LVS（Linux Virtual Server）工作在传输层（四层），它直接在内核层面做流量转发。性能比Nginx高出一个数量级。你想想看，Nginx要解析HTTP协议，而LVS只看IP和端口，处理速度自然快得多。

LVS有三种工作模式：

模式 工作原理 适用场景
NAT模式 修改数据包的目标IP和端口 后端服务器数量较少
DR模式 直接路由，不修改数据包 高性能场景，最常用
TUN模式 IP隧道封装 跨机房部署

我在项目中用得最多的是DR模式。它性能最好，因为LVS只负责分发，不参与数据回传。后端服务器直接把响应返回给客户端，LVS的负载压力很小。

配置LVS其实不复杂。我给大家看一个简单的DR模式配置：

# 在LVS服务器上配置虚拟IP
ifconfig eth0:0 192.168.1.100 netmask 255.255.255.0 up

# 添加LVS规则
ipvsadm -A -t 192.168.1.100:80 -s rr
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.10:80 -g
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:80 -g

这里用的是轮询算法（rr）。实际生产环境中，我建议用加权最少连接（wlc），它能根据后端当前的连接数来分发，更均衡。

注意：LVS的DR模式要求后端服务器也配置虚拟IP，并且要抑制ARP响应。这个细节很多人会忽略，导致配置后不生效。我曾经在这个坑里爬了整整一天。

硬件负载均衡（F5）：钞能力的代表

说到硬件负载均衡，F5绝对是行业标杆。它是一台专用的硬件设备，集成了负载均衡、SSL卸载、防火墙、应用加速等功能。性能嘛，一个字——强。

我记得有一次给一个金融客户做方案。他们要求每秒处理10万并发连接，而且延迟不能超过1毫秒。软件方案根本做不到，最后上了两台F5做双机热备，问题才解决。

F5的优势很明显：

  • 性能极高，硬件加速处理
  • 功能丰富，内置多种高级特性
  • 稳定性好，企业级可靠性

但缺点也很突出——贵。一台F5少说十几万，高配的几十万上百万。所以，一般只有银行、证券、大型电商才用得起。

F5的配置通常通过Web界面或命令行完成。我给大家看一个简单的iRule（F5的脚本语言）示例：

when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/api/" } {
        pool api_pool
    } else {
        pool web_pool
    }
}

这个iRule的作用是根据请求路径，把流量分发到不同的后端池。和Nginx的location配置类似，但F5的处理性能要高得多。

我的建议：如果预算充足，核心业务用F5，非核心业务用Nginx或LVS。这样既保证了关键链路的稳定性，又控制了成本。

如何选择？一张表说清楚

讲了这么多，到底该用哪种？我整理了一张对比表，你一看就明白：

技术 工作层 性能 功能 成本 推荐场景
DNS 应用层 中等 简单 低 全局流量调度
Nginx 七层 较高 丰富 低 Web应用、API网关
LVS 四层 高 中等 低 高性能TCP/UDP
F5 四/七层 极高 极丰富 高 金融、核心交易

你想想看，如果你的系统只是一个小型网站，用Nginx就够了。但如果是千万级用户的大平台，那就要考虑多层负载均衡了——DNS做全局调度，LVS做四层分流，Nginx做七层路由，F5做核心链路保障。

好了，这一章的内容就到这里。负载均衡技术看似简单，但里面的门道不少。我建议大家在实际项目中多动手试试，踩过坑才能真正理解。

下一章，我们会聊聊缓存策略——如何用缓存把系统性能再提升一个台阶。到时候见。

← 上一章 📖 返回目录 下一章 →