负载均衡与流量分发：从DNS到硬件的全链路解析
说到交易系统的高可用，负载均衡绝对是绕不开的核心话题。我做了这么多年金融系统，见过太多因为流量分配不均导致雪崩的案例。说白了，负载均衡就是让流量“走对路”，别让某一台服务器累死，其他服务器闲得发慌。
今天咱们聊聊四种主流的负载均衡方案：DNS、硬件负载均衡（F5）、软件负载均衡（Nginx、HAProxy），以及四层和七层的区别。嗯，这里面的坑不少，我一个个说。
一、DNS负载均衡：最“懒”的方案
DNS负载均衡，说白了就是域名解析的时候，给你返回不同的IP地址。比如你访问 api.trade.com，DNS服务器可能给你返回 10.0.0.1，下次返回 10.0.0.2。
优点：部署简单，成本低，不需要额外硬件。
缺点：DNS缓存问题严重，无法感知后端服务器健康状态。
我在项目中遇到过一个问题：某次大促，DNS解析到一台已经宕机的服务器，结果大量用户请求超时。为什么？因为DNS缓存还没刷新。你想想看，客户端和中间DNS服务器都可能缓存，TTL设置再短也扛不住瞬间流量。
避坑指南：我曾经因为DNS TTL设置过长，导致故障恢复后用户依然访问旧IP。建议TTL设置在60秒以内，关键业务甚至可以用30秒。
二、硬件负载均衡（F5）：贵但稳
F5这类硬件负载均衡器，在金融行业用得特别多。为什么？因为稳定、性能高、功能全。一台F5能扛住几十万并发连接，而且内置了SSL卸载、健康检查、会话保持等功能。
我记得有一次帮某券商做架构升级，他们原来的软件负载均衡在峰值时CPU飙到90%，换成F5后直接降到20%。硬件加速确实不是吹的。
| 特性 | F5硬件负载均衡 | 软件负载均衡 |
|---|---|---|
| 性能 | 极高（专用芯片） | 中等（依赖CPU） |
| 成本 | 高（几十万起步） | 低（开源免费） |
| 功能 | 丰富（内置脚本、iRules） | 基础功能为主 |
| 运维 | 需要专业认证工程师 | 普通运维即可 |
个人经验：如果预算充足，核心交易链路建议用F5。但非核心业务，比如日志收集、报表查询，用Nginx完全够用。
三、软件负载均衡：Nginx vs HAProxy
软件负载均衡里，Nginx和HAProxy是两大主流。很多人问我选哪个，我的答案是：看场景。
Nginx：七层之王
Nginx擅长七层负载均衡，也就是HTTP/HTTPS层面。它能解析URL、Cookie、Header，做精细化路由。比如根据用户ID哈希到固定后端，或者根据请求路径分发到不同服务。
# Nginx七层负载均衡配置示例
upstream trade_backend {
ip_hash; # 基于IP的会话保持
server 10.0.0.1:8080 weight=5;
server 10.0.0.2:8080 weight=3;
server 10.0.0.3:8080 backup;
}
server {
listen 443 ssl;
location /api/ {
proxy_pass http://trade_backend;
proxy_set_header Host $host;
}
}
HAProxy：四层更稳
HAProxy在四层（TCP/UDP）负载均衡上表现更出色。它的健康检查机制更灵活，支持主动和被动检查。我习惯用HAProxy做数据库或Redis的负载均衡。
# HAProxy四层负载均衡配置
frontend mysql_front
bind *:3306
mode tcp
default_backend mysql_back
backend mysql_back
mode tcp
balance leastconn
server db1 10.0.0.1:3306 check inter 3s fall 2 rise 3
server db2 10.0.0.2:3306 check inter 3s fall 2 rise 3
我的建议：HTTP/HTTPS场景用Nginx，TCP/UDP场景用HAProxy。两者也可以配合使用，Nginx在前端做七层分发，HAProxy在后端做四层转发。
四、四层与七层负载均衡的区别
这个问题面试常问，但很多人理解得不够深。我简单说下核心区别：
- 四层（L4）：工作在传输层，基于IP和端口转发。不解析应用层协议，性能高，延迟低。
- 七层（L7）：工作在应用层，能解析HTTP、HTTPS、WebSocket等协议。功能丰富，但性能略低。
举个例子：四层负载均衡就像快递分拣中心，只看包裹上的地址（IP+端口），不管里面装的是什么。七层负载均衡则像海关检查，会打开包裹看看内容（URL、Cookie），再决定送到哪里。
| 对比维度 | 四层负载均衡 | 七层负载均衡 |
|---|---|---|
| 工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS等） |
| 性能 | 高（无协议解析） | 中等（需解析协议） |
| 功能 | 基础转发、会话保持 | URL路由、Cookie处理、SSL卸载 |
| 典型产品 | F5（L4模式）、HAProxy | Nginx、F5（L7模式） |
| 适用场景 | 数据库、Redis、游戏 | Web应用、API网关 |
注意：七层负载均衡虽然功能强，但会引入额外的延迟。在交易系统中，核心订单链路建议用四层，非核心业务（如查询、报表）可以用七层。
五、整体架构图
下面这张图展示了从DNS到后端服务的完整负载均衡链路。我习惯把DNS作为第一层，硬件负载均衡作为第二层，软件负载均衡作为第三层，层层递进，互相兜底。
六、选型建议与避坑指南
最后总结一下我的经验：
- DNS负载均衡适合做全局流量调度，比如按地域分流。但别依赖它做高可用，TTL和缓存问题会让你头疼。
- F5硬件负载均衡适合核心交易链路，尤其是对延迟敏感的场景。预算够就上，别犹豫。
- Nginx适合七层场景，比如API网关、微服务网关。配置灵活，社区活跃。
- HAProxy适合四层场景，比如数据库、Redis、MQ。性能稳定，健康检查机制完善。
避坑指南：我曾经在项目中只用了一层Nginx做负载均衡，结果Nginx挂了整个系统瘫痪。后来我改成DNS + F5 + Nginx三层架构，任何一层出问题都能自动切换。记住：单点故障是架构设计的大忌。
好了，关于负载均衡与流量分发，今天就聊到这儿。记住一句话：没有最好的方案，只有最合适的方案。根据你的业务场景、预算、团队能力，选择最匹配的负载均衡策略。