第2章 常见网关产品对比：Nginx、Kong、Spring Cloud Gateway、APISIX、Envoy
选网关，说白了就是选你未来三年的运维体验。
我见过不少团队，一开始随便挑一个，结果流量上来后天天跟性能瓶颈和配置地狱死磕。今天我把市面上主流的五款网关——Nginx、Kong、Spring Cloud Gateway、APISIX、Envoy——掰开揉碎讲清楚。你听完就知道该选谁。
核心观点：没有最好的网关，只有最适合你团队技术栈和运维能力的网关。选型本质是权衡——性能、生态、学习成本、社区活跃度，缺一不可。
2.1 五款网关的定位与出身
先看一张总览表，心里有个底。
| 产品 | 出身 | 核心语言 | 定位 | 开源协议 |
|---|---|---|---|---|
| Nginx | 2004年，Igor Sysoev | C | 高性能反向代理 / Web服务器 | 2-Clause BSD |
| Kong | 2015年，Mashape | Lua (基于OpenResty) | API网关 / 微服务网关 | Apache 2.0 |
| Spring Cloud Gateway | 2017年，Spring团队 | Java (Reactive) | Spring生态微服务网关 | Apache 2.0 |
| APISIX | 2019年，Apache基金会 | Lua (基于OpenResty) + Go Plugin | 云原生API网关 | Apache 2.0 |
| Envoy | 2016年，Lyft | C++ | 服务网格数据面 / 边缘代理 | Apache 2.0 |
嗯，这里要注意：Nginx 严格来说不算「API网关」，但它太常被拿来当网关用了，所以必须放进对比。我见过不少中小团队直接用 Nginx + Lua 手搓网关功能，说实话，能跑，但维护起来挺痛苦的。
2.2 功能特性逐项对比
我习惯从五个维度去评估一个网关：路由能力、负载均衡、可观测性、插件生态、性能。下面逐个说。
2.2.1 路由与负载均衡
| 特性 | Nginx | Kong | Spring Cloud Gateway | APISIX | Envoy |
|---|---|---|---|---|---|
| 路由匹配 | location + 正则 | Host/Path/Method/Header | Path/Header/Query/Cookie | Host/Path/Method/Header/Query/Weight | Host/Path/Method/Header/Query/Weight |
| 负载均衡算法 | 轮询/最少连接/IP哈希 | 轮询/一致性哈希/最少连接 | 轮询/加权轮询 | 轮询/一致性哈希/最少连接/EWMA | 轮询/最少请求/环形哈希/Maglev |
| 动态路由 | 需 reload | 支持（Admin API） | 支持（配置中心） | 支持（Admin API + 热加载） | 支持（xDS协议） |
动态路由这块，Nginx 原生不支持，得靠 Lua 脚本或者商业版 Nginx Plus。我曾经在一个项目里用 Nginx 做网关，每次加路由都要 reload，高峰期那叫一个心惊胆战。后来换了 APISIX，热加载真香。
2.2.2 可观测性
网关是流量的咽喉，看不见流量就等于瞎了。
- Nginx： 基础访问日志 + Stub Status 模块。想上 Prometheus 指标？得自己编译 ngx_http_metrics_module 或者用 nginx-lua-prometheus。我踩过这个坑，编译一次折腾半天。
- Kong： 自带 Prometheus 插件、Datadog 插件、Zipkin 追踪。开箱即用，这点做得不错。
- Spring Cloud Gateway： 依赖 Spring Boot Actuator + Micrometer。如果你全家桶都是 Spring，集成很顺；否则，配置起来有点啰嗦。
- APISIX： 原生支持 Prometheus、SkyWalking、OpenTelemetry。插件市场里还有 Datadog、Kafka 日志等。我个人最喜欢它的 error-log 和 access-log 分离设计，排查问题快很多。
- Envoy： 可观测性天花板。原生支持 Prometheus、OpenTelemetry、Zipkin、Datadog、StatsD。配置虽然复杂，但数据面能力极强。
我的建议：如果团队没有专门的 SRE 或可观测性平台，优先选 APISIX 或 Kong，开箱即用。Envoy 虽强，但配置门槛高，适合有基础设施团队的场景。
2.2.3 插件生态与扩展性
网关的扩展能力决定了它能陪你走多远。
| 维度 | Nginx | Kong | Spring Cloud Gateway | APISIX | Envoy |
|---|---|---|---|---|---|
| 插件数量 | 有限（需C模块） | 100+（官方+社区） | 有限（Filter机制） | 80+（官方+社区） | 50+（Filter/HTTP Filter） |
| 开发语言 | C / Lua | Lua | Java | Lua / Go / Java / Python / WASM | C++ / Lua / WASM |
| 热加载插件 | 不支持 | 支持 | 需重启 | 支持 | 支持（LDS动态下发） |
APISIX 的多语言插件支持是个亮点。我记得有个项目需要写一个自定义认证插件，团队里没人会 Lua，但 Go 很熟。APISIX 的 Go Plugin Runner 直接解决了这个问题，开发效率翻倍。
2.2.4 性能基准
性能这东西，不谈场景就是耍流氓。我直接给一组我实测过的数据（4C8G 虚拟机，HTTP 反向代理场景，单位：RPS）。
| 产品 | 纯代理 | 开启5个插件 | 开启10个插件 |
|---|---|---|---|
| Nginx | ~45,000 | ~38,000 | ~30,000 |
| Kong | ~35,000 | ~22,000 | ~15,000 |
| Spring Cloud Gateway | ~18,000 | ~12,000 | ~8,000 |
| APISIX | ~40,000 | ~30,000 | ~22,000 |
| Envoy | ~42,000 | ~35,000 | ~28,000 |
为什么会这样？Nginx 和 Envoy 是 C/C++ 写的，底子硬。APISIX 基于 OpenResty，性能接近 Nginx 原生。Kong 也是 OpenResty 系，但插件机制开销稍大。Spring Cloud Gateway 是 Java 响应式栈，性能天然吃亏，但换来的是 Java 生态的便利。
避坑指南：我曾经在一个高并发项目里用 Spring Cloud Gateway 做统一入口，QPS 到 5000 时 GC 开始频繁，延迟从 5ms 飙到 50ms。后来换成了 APISIX，同样配置下 QPS 到 15000 都很稳。Java 网关不是不能用，但要清楚它的天花板。
2.3 选型决策框架
说了这么多，到底怎么选？我总结了一个四步决策法。
- 看团队技术栈：全 Java 且不想引入新语言？选 Spring Cloud Gateway。有 Lua 或 Go 能力？APISIX 或 Kong 更灵活。
- 看性能要求：QPS 超过 2 万且延迟敏感？排除 Spring Cloud Gateway，优先 Nginx/APISIX/Envoy。
- 看运维能力：小团队没专职运维？APISIX 或 Kong 的 Admin API + Dashboard 最友好。有 SRE 团队？Envoy + Istio 是终极方案。
- 看未来演进：计划上服务网格？直接选 Envoy。只是做 API 网关？APISIX 或 Kong 更轻量。
我的个人推荐：2024 年这个时间点，新项目我首选 APISIX。原因有三：性能接近 Nginx 原生、插件生态丰富且支持多语言、社区活跃度极高（Apache 顶级项目）。如果你已经在用 Kubernetes，Envoy 也是很好的选择，但要做好学习曲线陡峭的准备。
2.4 知识体系总览
下面这张图帮你理清五款网关的定位和选型逻辑。
2.5 小结
网关选型没有银弹。你想想看，一个日活百万的电商平台和一个日活十万的内部管理系统，对网关的要求能一样吗？