接入层的技术演进
本次要讲的是：用户请求进入机房后，如何从“业务服务器裸奔”逐步演进为高可用、高性能、可扩展的接入层架构。
核心主线
演进路径可以概括为：
1 | 业务服务器直接暴露公网 IP |
1. 为什么不能让业务服务器直接暴露公网
早期简单架构中，HTTP 业务服务器直接绑定公网 IP，DNS 直接把域名解析到业务服务器。
这种方式虽然简单，但不适合工业级互联网架构，主要问题有：
- 可用性低：业务实例宕机后，DNS 很难及时感知并摘除故障 IP，用户请求可能继续打到不可用机器。
- 可扩展性差：业务扩容需要修改 DNS，而 DNS 生效受缓存和 TTL 影响，不适合快速扩缩容。
- 安全风险高：所有业务服务器 IP 暴露在公网，攻击面大，内部服务缺乏保护。
解决思路是：在客户端和业务服务之间增加接入层中间件，由它统一承接外部流量、转发请求、屏蔽内部服务。
2. Nginx：七层反向代理与负载均衡
Nginx 的角色
Nginx 可以作为：
- HTTP 服务器；
- 反向代理服务器；
- 七层负载均衡器。
在接入层中，它更重要的角色是：对外承接 HTTP 请求，对内根据域名、URL 路径等应用层信息，把请求转发给不同业务服务实例。
正向代理 vs 反向代理
- 正向代理：代理客户端访问外部网络，例如 VPN。
- 反向代理：代理服务端接收客户端请求，客户端并不知道真实后端服务器是谁。
接入层使用的是反向代理。
Nginx 的关键配置概念
server：定义一个对外的 HTTP 服务，例如监听端口、匹配域名。location：根据 URL 路径定义转发规则，例如/feed、/like、/comment。upstream：定义后端服务池，包含多个业务服务实例地址。proxy_pass：指定某类请求要转发到哪个后端服务池。
常见负载均衡策略
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 轮询 | 默认策略，按顺序分发请求 | 后端实例能力相近 |
| 加权轮询 | 按权重分配流量 | 后端机器配置不同 |
ip_hash |
同一客户端 IP 尽量落到同一实例 | 需要会话粘滞，但负载可能不均 |
least_conn |
转发给连接数最少的实例 | 请求耗时差异较大 |
url_hash |
按 URL 哈希分发 | 提高缓存命中率 |
fair |
综合响应时间、失败数、请求量选择较空闲实例 | 更精细的动态负载均衡 |
Nginx 带来的收益
- DNS 只需指向 Nginx，业务服务器地址变化不影响 DNS。
- 业务服务只走内网，不再直接暴露公网 IP。
- Nginx 统一做流量调度，提升业务服务的可用性和可扩展性。
- 某个业务实例故障时，请求可以转移到其他实例。
- 结合服务注册中心、Lua 脚本、
ngx_http_dyups_module，Nginx 可以热更新upstream，准实时感知服务扩缩容。
3. LVS：四层负载均衡，用来扩展 Nginx 集群
为什么还需要 LVS
Nginx 性能高于业务服务器，但它仍是应用层软件，单台 Nginx 也有性能上限。
当流量继续增长时，需要多个 Nginx 组成集群，此时又需要一个更高性能的上层调度器来分发流量，这就是 LVS。
LVS 与 Nginx 的区别
| 对比项 | Nginx | LVS |
|---|---|---|
| 所在层次 | OSI 第七层，应用层 | OSI 第四层，网络层/传输层附近 |
| 核心动作 | 代理 | 转发 |
| 处理方式 | 与客户端、后端分别建立连接 | 修改数据包地址或链路层信息后转发 |
| 功能能力 | 能按域名、URL、Header 等做路由 | 更偏底层转发，不理解 HTTP 语义 |
| 性能 | 高 | 更高 |
| 典型用途 | 业务 HTTP 服务的七层负载均衡 | Nginx 集群的四层负载均衡 |
一句话：LVS 负责高性能入口转发，Nginx 负责灵活的应用层路由。
LVS 常用概念
- DS / Director Server：运行 LVS 的负载均衡节点。
- RS / Real Server：真实处理请求的后端服务器，这里通常是 Nginx。
- VIP：对外提供服务的虚拟 IP，也是客户端访问目标。
- DIP：DS 与 RS 通信使用的内网 IP。
- RIP：RS 的真实 IP。
- CIP：客户端 IP。
4. LVS 的 4 种转发模式
NAT 模式
DS 修改请求包的目标 IP 和端口，把请求转发给某个 RS；响应也必须回到 DS，再由 DS 改写后返回客户端。
特点：
- RS 不需要配置 VIP。
- DS 需要作为 RS 网关。
- 请求和响应都经过 DS，响应流量通常更大，DS 容易成为带宽瓶颈。
FULLNAT 模式
在 NAT 基础上，DS 同时修改请求的源 IP 和目标 IP，使 RS 响应能正常路由回 DS，而不要求 DS 是网关。
特点：
- RS 不需要配置 VIP。
- 对网络环境要求较低，适应性更强。
- 缺点是 RS 会丢失真实客户端 IP。
- 更推荐这种模式用于通用场景。
TUN 模式
DS 使用 IP 隧道把原请求包封装成新包发给 RS；RS 解包后处理请求，响应直接返回客户端。
特点：
- 响应不经过 DS，性能优于 NAT。
- DS 和 RS 不必处于同一网络。
- 网络环境需要支持 IP 隧道。
- RS 需要在本地配置 VIP。
DR 模式
DS 通过修改请求包的目标 MAC 地址，把请求转发给同一物理网络中的 RS；RS 处理后响应直接返回客户端。
特点：
- 响应不经过 DS，性能好。
- 不涉及 TUN 的隧道封装/解封装，性能通常优于 TUN。
- DS 和 RS 需要在同一物理网络。
- RS 需要配置 VIP。
模式选择
- 追求网络适应性：优先 FULLNAT。
- 追求极致性能：优先 DR。
5. LVS + Nginx 的最终接入层架构
基础组合
完整链路如下：
1 | 客户端 |
这种组合的分工是：
- LVS：扩展 Nginx 集群的吞吐能力。
- Nginx：根据 HTTP URL、域名等应用层信息，把请求路由到具体业务服务。
- 业务服务：专注业务逻辑处理，不直接暴露公网。
LVS 单点问题
如果只有一台 LVS，LVS 宕机会导致整个机房入口不可用。因此需要做 LVS 高可用。
常见方案是：Keepalived + VIP 主从热备。
工作方式：
- 主 LVS 节点持有 VIP，对外提供服务。
- 从 LVS 节点持续探活主节点。
- 主节点宕机后，从节点接管 VIP。
- 网络设备通过新的 ARP 响应把访问 VIP 的流量切到从节点。
LVS 水平扩展
单台 LVS 即使高可用，性能仍有上限。更进一步的做法是：
- 部署多组 LVS；
- 每组 LVS 通过 Keepalived 做主从高可用；
- 每组 LVS 绑定一个 VIP；
- 同一域名配置多个 VIP；
- 客户端通过 DNS 轮询访问不同 LVS。
最终达到：
- DNS 轮询扩展 LVS；
- Keepalived 保证 LVS 高可用；
- LVS 扩展 Nginx；
- Nginx 扩展业务 HTTP 服务。
6. 本节最重要的架构思想
- 不要让业务服务器直接暴露公网：公网入口应该尽量收敛到接入层。
- 用中间层解决可用性、扩展性和安全问题：接入层就是客户端与业务服务之间的关键中间层。
- 七层负载均衡负责“智能路由”：Nginx 理解 HTTP，可按 URL、域名等业务语义调度。
- 四层负载均衡负责“高性能转发”：LVS 更底层、更高性能，适合放在 Nginx 集群前面。
- 单点必须消除：LVS 自身也需要通过 Keepalived + VIP 做主从热备。
- 性能瓶颈要水平扩展：多组 LVS + DNS 轮询，让接入层具备横向扩展能力。
- 接入层最终目标：高可用、高性能、可扩展，同时保护内部业务服务。
一句话总结
大型互联网系统的接入层从业务服务器直连公网，逐步演进为“DNS → 多组高可用 LVS → Nginx 集群 → 业务服务集群”的分层负载均衡架构，其中 LVS 负责四层高性能转发，Nginx 负责七层灵活路由，共同提升系统的可用性、性能、安全性和扩展性。