API 网关与反向代理有什么区别
API 网关和反向代理都位于客户端与后端之间，但定位不同：反向代理解决负载均衡、SSL 卸载、缓存；API 网关面向 API 管理，提供鉴权、限流、协议转换、版本治理。本文给出对比表与选型建议。
一句话回答：反向代理是通用的流量转发层，负责把请求分发给后端并做好负载均衡、SSL 终止、缓存等"体力活"；API 网关是反向代理的"API 管理加强版"，在转发之上增加认证鉴权、限流配额、请求转换、版本管理、可观测分析等面向 API 生命周期的能力。管理微服务对外 API 用网关，单纯给 Web 服务做分流用反向代理即可。
职责对比
| 维度 | 反向代理 | API 网关 |
|---|---|---|
| 核心定位 | 通用流量入口 | API 入口策略；生命周期管理范围因产品而异 |
| 负载均衡 | ✅ 核心能力 | ✅ 有，但非重点 |
| SSL/TLS 终止 | ✅ | ✅ |
| 缓存/压缩/静态资源 | 常见，需配置 | 缓存/压缩也可能支持，静态资源通常交给专门服务 |
| 认证鉴权（JWT/OAuth） | 可通过内置模块、外部鉴权或扩展实现 | 常提供策略/插件，支持范围依产品与版本而定 |
| 限流/配额 | 简单支持 | ✅ 精细化（按用户/应用/API） |
| 请求/响应转换 | 可改写 URL、Header；Body/协议转换取决于扩展 | 常有转换插件，具体协议与载荷支持需核实 |
| API 版本管理 | 可按路径/Header 路由不同版本 | 常提供相应路由与策略，完整生命周期治理可能依赖管理平台 |
| 多服务聚合 | 需扩展或应用层实现 | 部分支持插件/编排，并非所有网关开箱即有 |
| 分析与计量 | 基础日志 | ✅ 调用量、租户维度的统计分析 |
典型产品
- 反向代理：Nginx、HAProxy、Traefik、Envoy
- API 网关：Kong、APISIX、Spring Cloud Gateway、AWS API Gateway、云厂商网关
有趣的是，很多 API 网关底层就是反向代理（Kong/APISIX 基于 Nginx/OpenResty，不少网关基于 Envoy）——网关 = 反向代理 + API 管理层。
什么时候用哪个
只用反向代理就够了：
- 单体应用或少数几个 Web 服务，需要负载均衡和 HTTPS
- 静态资源缓存、压缩、简单转发
- 内网服务的简单分流
需要 API 网关：
- 微服务架构，几十上百个 API 需要统一入口
- 对外开放 API 给第三方，需要密钥管理、配额计费
- 要求统一鉴权、统一限流策略、统一灰度发布
- 需要 API 级别的用量统计与版本治理
两者共存也很常见： 最外层 Nginx/云 LB 做 SSL 终止和基础分发，第二层 API 网关做 API 管理，后面才是微服务。
增加一层入口后，用相同请求对比延迟与错误率，并检查两层访问日志中的请求标识。观测云的 Nginx 集成可用于采集入口连接和请求指标；先确认启用的是基础状态接口、VTS 还是 Plus，再选择对应指标，不把基础连接统计当成上游耗时。
常见问题（FAQ）
Q：用了云厂商的负载均衡（如 ALB），还需要反向代理吗？
A：云 LB 本身就是在做反向代理的工作（分发 + SSL 终止）。多数场景下不需要再叠一层 Nginx，除非你有 LB 满足不了的需求（复杂路由规则、缓存、自定义逻辑）。
Q：服务网格（Service Mesh）和 API 网关什么关系？
A：API 网关管"南北向"流量（外部进集群），服务网格管"东西向"流量（集群内服务间）。两者职责互补，网关侧重 API 管理与对外开放，网格侧重服务间通信的可靠性与安全。
Q：Kong、APISIX 这类网关性能损耗大吗？
A：没有通用的延迟保证。TLS、载荷大小、插件、外部鉴权、连接复用与机器资源都会影响开销；应在目标配置下测量吞吐和尾延迟。本文未进行性能测试。
核查依据
本文依据官方文档核对，示例未在实际业务环境运行；上线前请按部署版本、权限与数据范围验证。
