第 2 章 · 架构与分层

生活类比：快递分拣中心有两种分拣方式——
按邮编分拣（只看信封外面） = 四层负载均衡（L4）
拆开看包裹里写的是衣服还是生鲜（看内容决定走冷链还是普快） = 七层负载均衡（L7）

---

2.1 学习目标

1. 讲清 OSI 模型中「第 4 层」和「第 7 层」指什么
2. 对比 L4 LB 与 L7 LB 的优缺点和典型产品
3. 了解 DNS LB、硬件 LB、软件 LB、客户端 LB 四类形态
4. 能根据场景做初步选型

---

2.2 先搞懂：LB 在哪一层工作？

网络通信按 OSI 七层模型 分层（初学记住两层就够）：

第 7 层 应用层   HTTP、HTTPS、gRPC、WebSocket  ← 你能看到的 URL、Header、Cookie
第 6 层 表示层   加密、压缩（TLS 部分逻辑在这）
第 5 层 会话层   会话管理
第 4 层 传输层   TCP、UDP                        ← IP + 端口号
第 3 层 网络层   IP 路由
...

类型	看什么信息做决定	生活类比
L4（四层）	源/目标 IP、端口号、协议（TCP/UDP）	快递只看邮编，不拆包裹
L7（七层）	HTTP 路径、Header、Cookie、Host、方法等	拆开看包裹内容再分拣

---

2.3 四层负载均衡（L4 LB）

工作原理

客户端 ──TCP 连接──► L4 LB ──新建 TCP 连接──► 后端某台
         (只见到 LB 的 IP)              (LB 维护两张表的映射)

L4 LB 通常做 连接级别的转发：

1. 收到客户端的 TCP SYN
2. 按算法选一台后端
3. 与后端建立连接，之后 双向转发字节流
4. 不解析 HTTP 内容（甚至不知道这是 HTTP 还是 MySQL 协议）

优点

优点	说明
极快	不看应用层，CPU 开销小
协议无关	TCP、UDP、MySQL、Redis 都能转发
连接数高	硬件 LB 可达百万级并发连接

缺点

缺点	说明
路由能力弱	不能按 URL /api vs /static 分到不同后端
看不到 HTTP	不能做基于 Cookie 的会话路由、Header 改写
TLS 麻烦	HTTPS 加密后 L4 看不到 Host，需要 SNI 或 TLS 终结在前置 L7

典型产品

• Linux LVS（DR / NAT / TUN 模式）
• F5 BIG-IP（硬件，也支持 L7）
• 云厂商 NLB / CLB 四层模式（腾讯云 CLB 四层、AWS NLB）
• HAProxy 的 mode tcp

生活案例：游戏服务器

王者荣耀匹配服用 UDP，只需要把「同一局玩家的包」引到同一台游戏逻辑服——看 IP/端口就够了，不需要看包里的英雄 ID 字符串，L4 最合适。

---

2.4 七层负载均衡（L7 LB）

工作原理

客户端 ──HTTP 请求──► L7 LB ──解析请求──► 按规则选后端 ──► 转发（可改 Header）

L7 LB 终止或解析应用层协议，能读懂 HTTP：

GET /api/v1/orders HTTP/1.1
Host: shop.example.com
Cookie: session_id=abc123
Authorization: Bearer eyJ...

于是可以做：

• /api/* → 订单微服务集群
• /static/* → CDN 或静态资源服务器
• Host: admin.example.com → 管理后台
• 没带 Token 的请求 → 直接 401，不打到后端
• 按 X-User-Id 做一致性哈希

优点

优点	说明
路由灵活	路径、Header、Cookie 任意组合
安全与治理	WAF、限流、鉴权、灰度发布
可观测	能记 access log、统计 API 级 QPS

缺点

缺点	说明
更吃 CPU	要解析 HTTP，TLS 解密更耗资源
协议绑定	主要服务 HTTP/gRPC，其它协议要额外支持
延迟略高	多一层解析，通常多 0.x～几 ms（可接受）

典型产品

• Nginx / OpenResty
• HAProxy mode http
• Envoy / Istio Ingress
• APISIX / Kong（API 网关，本质是 L7 LB + 插件）
• 云 ALB / 七层 CLB

生活案例：外卖 App

• 下单接口 /order → 订单服务（要鉴权、限流）
• 店铺图片 /img → 对象存储
• 客服聊天 /chat → WebSocket 长连接集群

不同 URL 不同处理方式，必须 L7。

---

2.5 L4 vs L7 对比表（面试必背）

维度	L4	L7
决策依据	IP + 端口	URL、Header、Cookie 等
性能	更高	略低，但一般够用
功能	纯转发	路由、鉴权、改写、缓存
协议	任意 TCP/UDP	主要是 HTTP/gRPC
TLS	通常透传或终结在前置	常在此层终结 HTTPS
典型场景	数据库代理入口、游戏、超高 QPS	Web API、微服务网关
生活类比	邮局按邮编分拣	快递按内件类型分拣

大厂常见组合：L4 + L7 串联

用户 ──► [L4：扛连接数、DDoS 清洗] ──► [L7：业务路由、鉴权] ──► 微服务

L4 挡住海量连接，L7 做精细路由——各司其职。

---

2.6 四种 LB 部署形态

① DNS 负载均衡

用户查询 shop.com
    │
    ▼
DNS 服务器返回多个 A 记录（轮询）：
  1.2.3.4
  5.6.7.8
  9.10.11.12

生活类比：百度地图给你推荐 3 条路线，你选一条——DNS 把用户「解析」到不同机房。

优点	缺点
零额外组件	TTL 缓存导致切换慢
地理就近（GeoDNS）	无法感知后端健康
适合多机房入口	不是真正的「实时」调度

常用于 多机房、多地域入口，常与真正的 LB 配合使用。

② 硬件负载均衡

F5、A10、Array 等专用设备。

生活类比：银行总部买的 专业叫号系统，贵但稳，能扛大流量。

• 优点：性能极强、功能全、有厂商支持
• 缺点：贵、扩容慢、配置偏传统

金融、运营商、超大流量入口常见。

③ 软件负载均衡（主流）

Nginx、HAProxy、LVS、Envoy、云 LB 实例。

生活类比：用 iPad + 叫号 App 自己搭一套——灵活、便宜、云原生友好。

互联网公司的默认选择。

④ 客户端负载均衡

调用方进程内嵌服务列表和选择逻辑。

# 伪代码：服务 A 调用服务 B
instances = registry.get("order-service")  # [10.0.1.1, 10.0.1.2, 10.0.1.3]
target = pick_one(instances, algorithm="round_robin")
response = http.post(f"http://{target}/orders", data=...)

生活类比：老顾客 自己记得 哪家分店人少，直接去——不经过大堂经理。

优点	缺点
减少一跳网络	每个客户端都要实现/维护
可与注册中心联动	语言/框架各异，一致性难

常见于 微服务 RPC（gRPC、Dubbo、Spring Cloud）。

---

2.7 选型决策树（实用版）

开始
 │
 ├─ 需要按 URL/Header 路由？ ──是──► L7（Nginx / APISIX / ALB）
 │
 ├─ 纯 TCP/UDP、追求极致吞吐？ ──是──► L4（LVS / NLB）
 │
 ├─ 跨地域、多机房入口？ ──是──► DNS/GSLB + 机房内 LB
 │
 ├─ 服务间内部调用？ ──是──► 客户端 LB + 注册中心（或 Service Mesh）
 │
 └─ 小项目、单机多实例？ ──是──► Nginx upstream 足够

---

2.8 手绘练习（建议真画一遍）

在纸上画：

[用户]
   │
   ▼
[DNS] ── GeoDNS 解析到广州/上海
   │
   ▼
[广州机房 L4 LB]  VIP: 203.0.113.1
   │
   ├──► [L7 Nginx] ── /api ──► [API 服务 ×3]
   │                 └── /static ──► [OSS]
   │
   └──► 健康检查探针每 5s ping 后端

画完对照检查：每一跳是 L4 还是 L7？健康检查在哪一层做？

---

2.9 面试速记卡

问：四层和七层负载均衡的区别？

四层基于 IP 和端口转发，不解析应用协议，性能高、功能少；七层解析 HTTP 等应用协议，能按 URL、Header 路由，能做鉴权限流，功能强、开销略大。生产常 L4 前置扛连接，L7 后置做业务路由。

问：为什么 Web 场景多用七层？

需要按路径分流、HTTPS 终结、会话保持、灰度发布——这些都要看懂 HTTP。

---

2.10 一句话总结

L4 像邮局按邮编分拣，快但粗；L7 像快递按内件分拣，慢一点点但聪明得多。 选型没有绝对答案，看你要「多快」还是「多灵活」。

下一章 → 03 · 调度算法大全：轮询、加权、最少连接、一致性哈希——配生活例子逐个攻破。