主流网关对比：Kong、APISIX、Envoy、Spring Cloud Gateway、Nginx
说到网关选型，我经常被问到：「到底该用哪个？」
说实话，没有银弹。每个网关都有自己的脾气。我在过去几年里，几乎把这几个主流网关都折腾了一遍。有的项目用Kong，有的用APISIX，还有的直接在Nginx上写Lua脚本。
今天我就把它们的底裤扒一扒。你想想看，选网关就像选车——有人要皮实耐造，有人要操控感，还有人只看油耗。咱们得先搞清楚自己要什么。
1. Nginx：老当益壮的基石
Nginx 其实不算严格意义上的API网关。它是个Web服务器。但为什么我把它列进来？因为很多网关底层就是它。
我记得2016年刚接触微服务时，团队直接用Nginx做反向代理。配置简单，性能炸裂。但问题也很明显——改配置要reload，动态性差。
核心特点：
- 事件驱动模型，性能极高
- 配置静态，不支持热更新
- 通过Lua扩展（OpenResty）可实现动态能力
- 生态成熟，社区庞大
说白了，Nginx是「硬汉」。你给它一份配置文件，它就老老实实干活。但如果你想动态增删路由、做灰度发布，那就得自己写Lua脚本了。我在一个金融项目中，就吃过这个亏——每次上线都要运维手动改配置，累死人。
我的建议：如果你团队有Lua高手，或者流量规模不大（日均百万级以下），Nginx+OpenResty完全够用。否则，还是看看下面几个吧。
2. Kong：企业级的老大哥
Kong 是基于OpenResty（Nginx+Lua）构建的。它把Nginx的静态配置变成了动态的，还加了一堆插件。
我最早用Kong是在2018年。当时觉得「哇，这玩意儿真香」。插件市场丰富，认证、限流、日志，开箱即用。
| 维度 | 评价 |
|---|---|
| 性能 | 中等偏上，底层是Nginx |
| 动态性 | 支持热更新，通过Admin API |
| 插件生态 | 非常丰富，官方+社区 |
| 学习曲线 | 中等，概念较多 |
| 企业版 | 收费，功能更强 |
但Kong有个坑——它的数据库依赖。默认用PostgreSQL，Cassandra也行。我曾经在生产环境遇到过数据库连接池爆满的问题，导致整个网关不可用。嗯，这里要注意，Kong的DB是单点故障风险。
避坑指南：我曾经因为Kong的DB连接数没配好，导致线上网关雪崩。建议生产环境一定要做DB的高可用，并且配置连接池上限。
3. APISIX：后起之秀，国产之光
APISIX 也是基于OpenResty。但它比Kong年轻，设计上更现代。
我个人习惯用APISIX做新项目。为什么？因为它性能更好，而且完全开源，没有企业版收费的顾虑。
APISIX 有几个让我眼前一亮的设计：
- 路由性能：用Radix Tree，比Kong的DB查询快很多
- 热加载：插件更新不需要reload
- 多语言支持：除了Lua，还能写Java、Go、Python插件
- 控制台：自带dashboard，可视化操作
我记得有一次帮客户做压测，APISIX的QPS比Kong高了30%左右。当然，这和具体配置有关，但APISIX在性能优化上确实下了功夫。
适用场景：对性能要求高、需要动态路由、希望完全掌控源码的团队。APISIX在金融、电商领域用得越来越多。
4. Envoy：云原生时代的C++猛兽
Envoy 是Lyft开源的，后来捐给了CNCF。它不是基于Nginx，而是用C++自研的。
你想想看，C++写的网关，性能能差吗？Envoy的架构设计非常先进——它把网络层、协议层、过滤层完全解耦。
Envoy 的核心优势：
- xDS协议：动态配置的标准，Istio等Service Mesh都用它
- 多协议支持：HTTP/1.1、HTTP/2、gRPC、TCP、WebSocket
- 可观测性：内置了非常完善的指标、日志、追踪
- 热重启：更新配置不丢连接
但Envoy也有门槛。它的配置是JSON/YAML，结构复杂。我刚开始接触时，光理解Listener、Cluster、Endpoint这几个概念就花了两天。
我的经验：如果你在用Kubernetes，并且打算上Service Mesh，那Envoy是绕不开的。但如果你只是需要一个简单的API网关，Envoy有点「杀鸡用牛刀」。
5. Spring Cloud Gateway：Java生态的宠儿
Spring Cloud Gateway 是Spring家族的一员。它基于Spring WebFlux，响应式编程。
如果你团队全是Java，那选它准没错。我见过很多Java团队，为了用Kong还得专门招个运维，太折腾了。
Spring Cloud Gateway 的特点：
- 纯Java：和Spring Boot无缝集成
- 响应式：基于Netty，性能不错
- 路由配置：支持Java DSL和YAML
- 过滤器链：和Spring WebFlux的Filter类似
但要注意，Spring Cloud Gateway 是阻塞还是非阻塞？它底层是Netty，非阻塞的。但如果你在过滤器中写了阻塞代码（比如JDBC查询），那就完蛋了。我曾经在一个项目中，看到同事在Gateway里直接查数据库，结果压测时线程池被打满。
避坑指南：在Spring Cloud Gateway中，千万不要写阻塞操作。如果需要调用外部服务，请用WebClient（响应式客户端），而不是RestTemplate。
6. 横向对比：一张表说清楚
| 特性 | Nginx | Kong | APISIX | Envoy | Spring Cloud Gateway |
|---|---|---|---|---|---|
| 底层语言 | C | Lua/OpenResty | Lua/OpenResty | C++ | Java |
| 动态配置 | ❌ | ✅ | ✅ | ✅ | ✅ |
| 性能 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 插件生态 | 需自研 | 丰富 | 丰富 | 中等 | 中等 |
| 学习成本 | 低 | 中 | 中 | 高 | 低（Java团队） |
| 云原生友好 | 一般 | 好 | 好 | 极好 | 好 |
| 典型场景 | 传统架构 | 企业级网关 | 高性能网关 | Service Mesh | Java微服务 |
7. 到底怎么选？
我个人的选型思路是这样的：
- 团队技术栈：Java团队无脑Spring Cloud Gateway。Lua/Go团队看APISIX。
- 性能要求：QPS超过10万，优先考虑APISIX或Envoy。
- 运维能力：运维强，选Envoy（配置复杂但灵活）。运维弱，选APISIX（自带dashboard）。
- 是否上Service Mesh：是的话，Envoy是必选项。
- 预算：Kong企业版收费，APISIX完全开源。
说白了，没有最好的网关，只有最合适的。我见过有人用Nginx硬扛百万QPS，也见过用Spring Cloud Gateway做简单路由。关键是你得清楚自己的场景。
最后说一句：不管选哪个，一定要先做压测。我曾经在项目上线前一周才发现Kong的某个插件有性能瓶颈，差点翻车。嗯，提前踩坑总比线上踩好。
下一章，我会深入讲APISIX的路由实现和插件开发。如果你对某个网关特别感兴趣，也可以留言，我后续单独展开。