一、核心功能对比（架构视角）
| 能力维度 | 反向代理 | 负载均衡器 | API网关 |
|---|---|---|---|
| 核心目标 | 隐藏后端，安全缓冲 | 流量分发，提升可用性 | API全生命周期管理 |
| 流量路由 | 基础URL/路径匹配 | 算法分发（轮询/最小连接） | 高级路由（Header/参数） |
| 安全能力 | SSL卸载，IP黑白名单 | 基础DDoS防护 | JWT/OAuth2，WAF集成 |
| 协议支持 | HTTP/HTTPS，WebSocket | L4(TCP/UDP)到L7(HTTP) | REST/gRPC/GraphQL |
| 性能优化 | 静态缓存 | 连接复用 | 请求聚合，响应压缩 |
| 可观测性 | 基础访问日志 | 健康检查指标 | 全链路追踪，指标可视化 |
| 扩展性 | 有限（模块化架构） | 中等（硬件/软件方案） | 高（插件生态） |
典型代表工具：
- 反向代理：Nginx、Caddy
- 负载均衡器：F5 BIG-IP、AWS ELB、HAProxy
- API网关：Kong、Apigee、AWS API Gateway
二、工作层次与流量处理差异
1. 反向代理：应用层（L7）安全屏障
# Nginx配置示例：缓存+SSL卸载
server {
listen 443 ssl;
server_name api.example.com;
ssl_certificate /path/to/cert.pem;
location /static/ {
proxy_cache my_cache; # 静态资源缓存
proxy_pass http://backend;
}
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://gateway; # 转发到API网关
}
}
核心价值：
- 终止TLS连接降低后端压力
- 缓存静态内容（减少30%~60%后端请求）
- 屏蔽后端服务器信息（防扫描攻击）
2. 负载均衡器：传输层（L4）到应用层（L7）流量调度
算法类型：
- L4层：IP哈希、最小连接数（适合TCP/UDP）
- L7层：内容感知路由（如按URL路径分流）
健康检查机制：
# HAProxy健康检查配置
backend web_servers
option httpchk GET /health
server srv1 10.0.0.1:80 check inter 10s
server srv2 10.0.0.2:80 check backup # 备用节点
3. API网关：应用层（L7）API治理中枢
graph TB
subgraph API网关
A[请求] --> B[认证鉴权]
B --> C[限流熔断]
C --> D[协议转换 gRPC→JSON]
D --> E[请求聚合]
end
E --> F[微服务]
核心能力：
- 身份治理：OAuth2客户端凭证流
- 流量管控：令牌桶限流（如1000req/s/用户）
- 转换引擎：gRPC转REST、XML转JSON
- 聚合编排：合并多个微服务响应
三、应用场景与典型架构
场景1：传统Web应用（高并发读）
技术栈：
- 负载均衡器：AWS ALB（处理百万QPS）
- 反向代理：Nginx（缓存静态HTML/CSS）
- 为何不用API网关：无复杂API治理需求
场景2：微服务架构（混合协议）
技术栈：
- API网关：Kong（插件：JWT校验+请求转换）
- 负载均衡器：Kubernetes Service（ClusterIP内部负载）
- 反向代理角色：由API网关内置Nginx引擎承担
场景3：全球分布式系统
技术栈：
- 边缘网关：Cloudflare Workers（JS逻辑处理）
- 区域网关：AWS API Gateway + Lambda
- 负载均衡：GCP Global Load Balancer
四、架构选型决策树
graph TD
A{需求分析}
A --> B[是否需要高级API治理？]
B -->|是| C[API网关]
B -->|否| D[是否需要流量分发？]
D -->|是| E[负载均衡器]
D -->|否| F[是否需要安全缓冲？]
F -->|是| G[反向代理]
F -->|否| H[直连服务]
C --> I{微服务数量>5？}
I -->|是| J[Kong/Apigee]
I -->|否| K[轻量网关如Spring Cloud Gateway]
E --> L{流量规模}
L -->|>10Gbps| M[硬件负载均衡 F5]
L -->|<10Gbps| N[软件负载均衡 HAProxy]
五、性能与成本对比
| 指标 | 反向代理 | 负载均衡器 | API网关 |
|---|---|---|---|
| 最大吞吐量 | 50万RPS（Nginx） | 100万RPS（F5） | 10万RPS（Kong） |
| 延迟增加 | 0.5-2ms | 0.1-1ms(L4)/3-5ms(L7) | 5-15ms |
| 典型部署成本 | $0（开源） | $5K-$50K/年 | $10K-$100K/年 |
| 运维复杂度 | 低 | 中 | 高 |
注：测试环境：4核8G VM，1KB响应体，HTTP/1.1
六、协同架构模式
现代云原生架构示例
组件分工：
- 全局负载均衡：GSLB实现地理路由
- API网关：认证/限流/聚合
- Ingress：反向代理 + TLS终止
- Service：K8s内部负载均衡
七、避坑指南
过度网关化
问题：所有流量经网关导致单点瓶颈
方案：- 静态内容直连CDN
- 实时音视频走专用通道
多层代理延迟叠加
问题：请求穿透3层代理增加50ms延迟
方案：- 使用Anycast减少跳数
配置漂移
问题：Nginx/HAProxy/Kong配置不一致
方案：- 基础设施即代码（Terraform管理配置）
- 统一配置中心（Consul + Vault）
总结：架构师决策原则
关注核心需求：
- 安全隔离 → 反向代理
- 水平扩展 → 负载均衡
- API治理 → API网关
分层协同：
演进式设计：
- 初创项目：Nginx（反向代理+负载均衡）
- 微服务转型：增加API网关（如Kong）
- 全球规模：引入全局负载+边缘网关
真实案例：某电商平台架构演进：
- V1.0：Nginx反向代理（单体应用）
- V2.0：HAProxy + Nginx（服务分离）
- V3.0：Kong网关 + AWS NLB（微服务化）
结果：API故障率下降76%，部署效率提升3倍