-DNS/GeoDNS、四层 / 七层负载均衡原理与应用)
流量入口层篇 (一)-DNS/GeoDNS、四层 / 七层负载均衡原理与应用
从事分布式架构设计的同学一定绕不开流量入口层这一块，不管是面试还是实际做系统设计，DNS 调度、四层 / 七层负载均衡都是高频考点。很多初学者刚接触时很容易把这些概念混为一谈：为什么有的资料说四层比七层快？Nginx 既能做四层又能做七层，为什么大厂还在大规模用 LVS？API 网关和负载均衡到底有什么区别？
本文作为流量入口层系列的第一篇，会从最基础的概念出发，结合实际配置案例和选型思路，帮你把这部分知识彻底捋顺。
一、DNS/GeoDNS：全局流量调度的第一道门
1.1 DNS 是什么
DNS（域名系统）本质上就是互联网世界的 “电话簿”：我们在浏览器输入www.example.com时，机器本身不认识这个域名，DNS 的作用就是把人类好记的域名翻译成服务器可识别的 IP 地址（比如192.0.2.1），只有拿到目标 IP，浏览器才能建立 TCP 连接发起请求。 作为最基础的基础设施，你需要重点掌握几个核心概念：
- 解析流程：包含递归查询（浏览器→本地 DNS 服务器）和迭代查询（本地 DNS 服务器→根域名服务器→顶级域名服务器→权威 DNS 服务器）两个阶段；
- TTL（缓存时间）：DNS 解析结果在本地缓存的有效时长，设置太短会加大 DNS 服务器压力，设置太长会导致故障切换时流量无法及时切换到备用节点，是实际运维中非常重要的调优点；
- 常见记录类型：A 记录（域名映射到 IPv4 地址）、AAAA 记录（映射到 IPv6 地址）、CNAME 记录（域名别名映射）、NS 记录（指定域名的权威解析服务器）。
1.2 GeoDNS 是什么
GeoDNS 是 DNS 的智能升级能力，它会根据用户请求的来源地理位置、所属运营商，返回距离用户最近、链路最优的机房节点 IP，而不是不管用户在哪都返回同一个全局地址。 比如一个部署了多地域机房的电商平台，海南的用户访问时 GeoDNS 会自动返回华南机房的 IP，美国纽约的用户访问时会自动返回美西机房的 IP，实现 “就近接入”。
1.3 实际应用场景
- 大促、直播等大流量场景下，通过就近接入降低跨网访问的延迟；
- 跨区域多活架构中，配合流量调度实现故障时的自动流量切换；
- 规避运营商跨网访问瓶颈：电信用户返回电信机房 IP，联通用户返回联通机房 IP，避免跨网卡顿。 目前主流的 GeoDNS 服务包括阿里云云解析 DNS、腾讯云 DNSPod、AWS Route53 等，配置时只需要选择对应的解析线路，即可实现按地域、运营商的智能调度。实际生产中还需要关注 DNS 劫持、缓存污染等风险，可通过 DoH/DoT 加密 DNS 方案提升安全性。
二、先搞懂基础：OSI 七层协议到底在讲什么
要理解四层负载、七层负载的差异，必须先搞清楚 OSI 七层模型的本质 ——这里一定要先澄清一个核心误区：OSI 的每一层都是对网络通信功能的逻辑抽象，是一组协议规则和要完成的任务总和，不是一个物理上的具体设备。 很多教材里写 “数据链路层对应交换机，网络层对应路由器”，容易让初学者误以为这些设备 “只属于某一层”，其实这是完全的误解：说交换机是二层设备，指的是它的核心转发逻辑主要工作在数据链路层，收到数据帧后只解析帧头里的 MAC 地址做端口转发，但交换机本身也必须实现物理层的电信号处理才能正常工作；同理路由器是三层设备，指的是它的核心逻辑是解析 IP 头部做路由选择，但它同样要实现数据链路层的帧封装 / 解封装功能。 我们自己的电脑发送一个网络包时，从应用层生成 HTTP 请求，到传输层加 TCP 头、网络层加 IP 头、数据链路层加以太网帧头，最后网卡把帧转成电信号发出去 —— 这整套封装流程完全是在本机的操作系统内核和网卡驱动里完成的，和外部的交换机、路由器没有关系；外部网络设备只是在数据包传输的路径上，按照自己的核心处理层级对数据包做转发操作而已。
从下到上，每一层的具体功能如下：
表格
| 层级 | 核心功能 | 数据单位 | 典型协议 / 实现 |
|---|---|---|---|
| 第 1 层 物理层 | 将二进制比特转换成电信号、光信号，通过网线、光纤、无线电等物理介质传输 | 比特 (bit) | 网线、光纤、网卡 PHY 芯片 |
| 第 2 层 数据链路层 | 将比特流组装成帧，通过 MAC 地址实现相邻节点间的可靠传输，做差错校验 | 帧 (Frame) | 以太网、VLAN、交换机、ARP 协议 |
| 第 3 层 网络层 | 负责跨节点的路由选择和转发，通过 IP 地址定位全网目标主机 | 数据包 (Packet) | IP 协议、ICMP、路由器、三层交换机 |
| 第 4 层 传输层 | 提供端到端的可靠 / 不可靠传输，通过端口号区分不同应用，实现流量控制和重传 | TCP 段 / UDP 数据报 | TCP、UDP 协议 |
| 第 5 层 会话层 | 建立、管理和终止应用程序之间的会话连接 | 报文 | RPC、NetBIOS（TCP/IP 模型中已合并） |
| 第 6 层 表示层 | 解决不同系统的数据格式差异，做编码转换、加密解密、压缩解压 | 报文 | SSL/TLS、JPEG/JSON 格式编码 |
| 第 7 层 应用层 | 直接面向用户提供网络服务，是所有应用层协议的载体 | 报文 | HTTP、HTTPS、DNS、FTP、SSH |
理解了分层的本质之后，我们再回头看 “四层负载”“七层负载” 的命名逻辑就非常清晰了：它指的是这个负载均衡设备，在转发请求时会解析到 OSI 模型的哪一层头部信息。
三、四层负载与七层负载的核心区别
3.1 四层负载均衡
四层负载均衡工作在 OSI 模型的传输层，转发时只看数据包的 IP 地址和端口号，完全不关心上层的应用协议内容 —— 不管你是 HTTP 请求、MySQL 连接还是游戏 TCP 长连接，它都一视同仁，把数据包转发给后端的某台服务器即可。 它的典型代表是 LVS（Linux Virtual Server）、F5 硬件负载均衡、云厂商的 NLB（网络型负载均衡）。
3.2 七层负载均衡
七层负载均衡工作在 OSI 模型的应用层，转发时会解析完整的应用层协议内容，比如 HTTP 请求的 URL 路径、Host 头、Cookie、请求方法，甚至是请求体里的 JSON 字段，再根据这些内容做更精细的流量路由。 它的典型代表是 Nginx 的 http 模块、HAProxy、云厂商的 ALB（应用型负载均衡）。
3.3 核心差异对比
表格
| 对比维度 | 四层负载均衡 | 七层负载均衡 |
|---|---|---|
| 工作层级 | OSI 第 4 层 传输层 | OSI 第 7 层 应用层 |
| 转发依据 | 源 / 目标 IP、端口、TCP/UDP 五元组 | URL、Host、HTTP Header、Cookie、协议内容 |
| 性能表现 | 极高（内核态处理，接近线速转发） | 较高（需解析应用层协议，CPU 开销更大） |
| 灵活性 | 低，仅支持简单的流量分发 | 高，支持 URL 路由、SSL 卸载、限流、缓存、内容改写 |
| 协议支持 | 任意 TCP/UDP 协议 | HTTP/HTTPS/gRPC 等应用层协议 |
| 典型技术 | LVS、F5 硬件 LB、阿里云 NLB | Nginx http 模块、HAProxy、阿里云 ALB |
四、实战篇：Nginx 四层 / 七层转发配置案例
Nginx 是目前生产环境最常用的负载均衡软件，它的http块用于实现七层转发，stream块（Nginx 1.9 + 版本支持，编译时需开启--with-stream参数）用于实现四层转发，我们通过两个典型场景展示具体配置。
4.1 七层负载实战：反向代理 Web 站点
场景：某电商网站统一入口为www.example.com，需要实现：
- 所有 HTTPS 请求统一在 Nginx 处完成 SSL 解密（SSL 卸载），后端业务服务器不需要配置证书；
/api/路径下的请求转发到后端 API 服务集群，按最少连接算法分发；/static/路径下的静态资源直接由 Nginx 本地磁盘返回，设置长缓存。 对应的配置片段：
http { # 定义后端API服务器组 upstream api_servers { least_conn; # 采用最少连接算法分发请求 server 10.0.0.11:8080 weight=5 max_fails=3 fail_timeout=30s; server 10.0.0.12:8080 weight=3 max_fails=3 fail_timeout=30s; server 10.0.0.13:8080 backup; # 备用节点，主节点全部故障时才接管 } server { listen 443 ssl http2; server_name www.example.com; # SSL证书配置 ssl_certificate /etc/nginx/certs/example.com.crt; ssl_certificate_key /etc/nginx/certs/example.com.key; # 七层路由：API请求转发到后端集群 location /api/ { proxy_pass http://api_servers; # 传递真实客户端信息给后端 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 5s; proxy_read_timeout 60s; proxy_buffering off; # 关闭缓冲，支持接口实时流式返回 } # 静态资源本地直接返回 location /static/ { alias /data/web/static/; expires 30d; add_header Cache-Control "public, immutable"; } } }效果：用户访问https://www.example.com/api/order/list时，Nginx 会解析 HTTP 请求的 URI 路径，匹配/api/规则，从api_servers组中选出当前连接数最少的一台服务器转发请求；用户访问静态资源时 Nginx 直接读本地文件返回，不需要经过后端业务服务器，大幅降低后端压力。
4.2 四层负载实战：Nginx stream 代理 MySQL 集群
场景：内网 MySQL 主从读写分离集群，应用程序需要通过统一入口连接数据库：写请求走主库，读请求走从库，同时保证同一个客户端的连接始终落到同一台从库上，避免会话不一致。 这里 Nginx 用 stream 模块做四层 TCP 转发，不解析 MySQL 协议内容，纯 IP + 端口转发：
stream { # 定义MySQL从库组（读请求入口） upstream mysql_replicas { hash $remote_addr consistent; # 基于客户端IP的一致性哈希，保证会话粘滞 server 10.0.0.31:3306 max_fails=3 fail_timeout=30s; server 10.0.0.32:3306 max_fails=3 fail_timeout=30s; server 10.0.0.33:3306 max_fails=3 fail_timeout=30s; } # 定义MySQL主库组（写请求入口） upstream mysql_master { server 10.0.0.100:3306; } # 监听3306端口，转发到从库组（读请求） server { listen 3306; proxy_pass mysql_replicas; proxy_connect_timeout 5s; proxy_timeout 600s; # 长连接超时设置，适配MySQL长连接场景 } # 监听3307端口，转发到主库（写请求） server { listen 3307; proxy_pass mysql_master; } }效果：应用程序连接 Nginx 的 VIP 地址 10.0.0.200 的 3306 端口时，Nginx 根据客户端源 IP 做一致性哈希，把 TCP 连接固定转发到某一台 MySQL 从库；连接 3307 端口则直接转发到主库。整个过程 Nginx 不解析 MySQL 的协议内容，纯 TCP 透传，转发性能极高，不会成为数据库访问的瓶颈。
五、技术选型：为什么有了 Nginx，还需要 LVS+Keepalived、云 SLB 和 API 网关
这部分是实际架构设计中最容易混淆的点，我们一个一个拆解清楚。
5.1 Nginx 能做四层和七层，为什么还要学 LVS+Keepalived？
很多同学会问：Nginx 已经支持四层 stream 转发了，为什么大厂生产架构里还在大量使用 LVS+Keepalived？本质上两者的性能天花板和高可用成熟度有量级上的差距： 第一，性能差距巨大。Nginx 不管是做 http 七层转发还是 stream 四层转发，都是运行在用户态的应用程序，每个连接都需要用户态和内核态的上下文切换，单机最大并发连接一般在几十万到百万级；而 LVS 是集成在 Linux 内核里的 IPVS 模块，直接在 netfilter 框架上做内核态转发，几乎零拷贝，单机可以支撑数百万甚至千万级的并发连接，转发延迟比用户态的 Nginx 低一个数量级。 第二，高可用方案更成熟。Nginx 自身没有高可用能力，一般需要配合 Keepalived 做主备 VIP 漂移，但 Keepalived 默认只能检测 Nginx 进程是否存活，没法做后端节点的精细健康检查；而 LVS+Keepalived 是经过十几年生产验证的经典组合，Keepalived 可以直接在内核层面完成 LVS 后端节点的健康检查、连接状态同步，主备切换时间在毫秒级，且不会中断已有的 TCP 连接，非常适合金融、游戏这类对连接稳定性要求极高的场景。 第三，架构分层互补，不是替代关系。生产环境的典型流量链路是：用户 -> LVS（四层入口） -> Nginx集群（七层反向代理） -> 后端应用服务。LVS 负责在最外层扛住海量的并发连接，把流量均匀散列到后面的 Nginx 集群上；Nginx 负责做七层的精细路由、SSL 卸载、限流缓存。如果直接把 Nginx 暴露在公网入口，哪怕部署多台 Nginx，也需要在前面再加一层四层负载做分发，否则单台 Nginx 的性能很快就会成为瓶颈。
5.2 第三方云厂商的 SLB，什么情况下用？
阿里、腾讯、华为等云厂商提供的 SLB 服务，本质上是把四层、七层负载均衡能力做成了托管云服务，不需要用户自己采购服务器、部署 LVS/Nginx、搭建高可用集群。 适合用云 SLB 的场景：
- 中小团队 / 初创项目，没有专门的运维团队负责基础设施建设，希望快速上线业务，不想花精力维护负载均衡集群；
- 业务快速迭代阶段，流量波动大，云 SLB 支持弹性扩缩容，按量付费，不需要提前预留硬件资源；
- 混合云 / 多区域部署场景，云 SLB 可以和云厂商的全球流量管理、DDoS 防护、WAF 能力无缝集成，快速实现跨区域多活和灾备。 而需要自建 LVS+Nginx 的场景包括：超大规模业务（比如电商大促峰值、直播平台），带宽和连接数极大，云 SLB 长期使用成本远高于自建；有极强定制化需求，需要深度修改转发逻辑、做内核级性能调优；有合规要求，所有网络流量必须在自有 IDC 机房内闭环，不能走公有云。简单总结：云 SLB 省心但单位成本高，自建 LVS+Nginx 省钱但需要专门的运维投入，架构师要根据团队规模和业务阶段做权衡。
5.3 API Gateway 和四 / 七层负载均衡怎么分工？
很多同学会觉得 Spring Cloud Gateway、Kong 这些网关也是做路由转发的，和 Nginx、LVS 的功能是不是重复了？用一个物流配送的类比就能说清楚：
- 四层负载（LVS / 云 NLB）：城市高速路口的收费站，只根据车牌（IP）和目的地城市（端口）放行，不管车里装的是什么货物，目标是快速疏导车流，不能堵；
- 七层负载（Nginx / 云 ALB）：物流园区的大门，根据货物面单上的仓库地址（URL 路径），把货车引导到对应的仓库卸货，目标是做粗粒度的分流；
- API Gateway：仓库内部的智能分拣机器人，打开包裹检查里面的具体商品（解析请求体、JWT 令牌），完成验货（鉴权）、贴价签（限流、熔断）、改包装（协议转换、参数聚合），甚至直接拒收不合格的包裹。 三者的分工是层层递进的：四层负载在最外层，负责抗 DDoS、扛住海量并发连接，绝不把业务逻辑耦合在这一层；七层负载在中间层，负责 SSL 卸载、静态资源缓存、粗粒度的路由分流，把对应微服务集群的流量转到 Gateway 集群；API Gateway 在最靠近业务的一层，负责微服务场景下的精细化治理：认证鉴权、限流熔断、灰度发布、请求聚合、协议转换。
结语
这篇文章我们从最基础的 DNS/GeoDNS 全局调度讲起，澄清了 OSI 七层模型是逻辑功能抽象而非物理设备的核心误区，对比了四层和七层负载均衡的本质差异，结合 Nginx 实战案例展示了两种转发模式的配置方法，最后梳理了从 Nginx、LVS+Keepalived、云 SLB 到 API Gateway 的技术选型逻辑和分工关系。 流量入口层是整个分布式系统的第一道防线，选对技术方案、理清各层职责，才能既扛住突发的大流量，又支撑业务的快速迭代。下一篇我们会专门深入 API Gateway 这一层，详细拆解 Spring Cloud Gateway 的核心概念、路由配置实战以及核心流程的源码解析，欢迎持续关注。
，本地轮毂翻新升级标杆门店推荐)
