2、网关分类：商业网关、开源网关（Kong、Zuul、Spring Cloud Gateway）对比
聊到网关选型，我见过不少团队一上来就纠结「用哪个」。其实说白了，你得先搞清楚一个核心问题：你的网关到底要扛多重的活？
我个人习惯把网关分成三大类：商业网关、开源网关、以及云厂商自带的网关。今天咱们重点聊前两类，顺便拿三个典型开源产品——Kong、Zuul、Spring Cloud Gateway——做个深度对比。
2.1 商业网关：花钱买省心
商业网关，说白了就是「你出钱，厂商帮你搞定一切」。典型代表有：
- Kong Enterprise（Kong 的商业版）
- NGINX Plus（NGINX 的商业版）
- Apigee（Google 的 API 管理平台）
- Amazon API Gateway（AWS 的托管网关）
我在项目中遇到过一家金融客户，他们直接买了 Kong Enterprise。为什么？因为合规要求太严了——安全审计、流量加密、API 密钥管理，这些功能商业版开箱即用。你想想看，如果自己拿开源版去拼，光安全模块就得折腾好几个月。
商业网关的核心优势：
- 开箱即用，功能完整
- 有官方技术支持
- 安全合规方面更省心
- 性能调优通常已经做过
注意：商业网关的坑也不少。我曾经见过一个团队买了 Apigee，结果发现它的定价是按 API 调用次数算的。业务量一上来，账单直接翻了好几倍。所以选商业网关前，一定把计费模型算清楚。
2.2 开源网关：免费但需要动手
开源网关嘛，好处是免费、灵活、社区活跃。但坏处也很明显——你得自己搭、自己配、自己修 bug。我接触最多的三个开源网关是：Kong、Zuul、Spring Cloud Gateway。
咱们一个一个来看。
2.2.1 Kong：基于 Nginx 的高性能网关
Kong 的核心是 OpenResty（Nginx + Lua）。所以它的性能天生就强，特别适合高并发场景。
我记得有一次帮一个电商团队做压测，Kong 在 4 核 8G 的机器上轻松扛住了 5 万 QPS。Zuul 在同配置下，跑到 1 万 QPS 就开始抖了。
Kong 的架构是这样的：
请求 → Kong（Nginx 核心） → 插件链（认证、限流、日志...） → 上游服务它的插件机制很灵活。官方有 100+ 插件，你也可以用 Lua 自己写。嗯，这里要注意：Lua 的学习成本不低，团队里得有懂 Lua 的人。
我的建议：如果你的团队有 Nginx 运维经验，或者业务对性能要求极高（比如每秒几万请求），Kong 是首选。但如果你团队全是 Java 工程师，那就要慎重了——Lua 的坑不少。
2.2.2 Zuul：Netflix 的 Java 网关
Zuul 是 Netflix 开源的，基于 Servlet 架构。说白了，它就是一堆 Filter 串起来的请求处理链。
Zuul 1.x 的问题很明显：它是阻塞式的。每个请求都会占用一个线程，直到响应返回。高并发下，线程池很容易被打满。
我曾经在一个项目中用 Zuul 1.x 做网关，上线第一天就被流量打挂了。后来一查，线程池满了，请求全排队，最后超时。那叫一个惨。
Zuul 2.x 改成了异步非阻塞，性能好了不少。但说实话，它来得太晚了。Spring Cloud Gateway 已经成了主流。
// Zuul 1.x 的 Filter 示例
public class MyFilter extends ZuulFilter {
@Override
public String filterType() {
return "pre"; // 前置过滤
}
@Override
public Object run() {
// 这里做鉴权、限流等操作
return null;
}
}避坑指南：如果你还在用 Zuul 1.x，我建议尽快迁移。它已经停止维护了。Zuul 2.x 虽然还在更新，但社区活跃度远不如 Spring Cloud Gateway。
2.2.3 Spring Cloud Gateway：Spring 生态的首选
Spring Cloud Gateway 是 Spring 官方推出的网关，基于 Spring WebFlux（响应式编程）。它的核心是路由 + 过滤器链。
我个人最喜欢它的地方是：配置简单，和 Spring Boot 无缝集成。你只要在 application.yml 里写几行配置，就能搞定路由转发。
spring:
cloud:
gateway:
routes:
- id: user-service
uri: lb://user-service
predicates:
- Path=/user/**
filters:
- StripPrefix=1你看，这段配置的意思是：所有 /user/ 开头的请求，都转发到 user-service 服务，并且去掉路径前缀。
Spring Cloud Gateway 的性能比 Zuul 1.x 好很多，和 Kong 比的话，单机性能略低一些，但胜在生态好。如果你团队全是 Spring 技术栈，那选它准没错。
三个开源网关的对比总结：
| 特性 | Kong | Zuul | Spring Cloud Gateway |
|---|---|---|---|
| 底层技术 | Nginx + Lua | Servlet（1.x）/ Netty（2.x） | Spring WebFlux（Netty） |
| 性能 | 极高 | 一般（1.x）/ 较好（2.x） | 高 |
| 学习成本 | 中（需懂 Lua） | 低（Java 即可） | 低（Spring 生态） |
| 插件生态 | 丰富（100+ 插件） | 一般 | 中等（可自定义 Filter） |
| 社区活跃度 | 高 | 低（1.x 已停更） | 高 |
| 适用场景 | 高并发、API 管理 | 遗留系统、小规模 | Spring 微服务生态 |
2.3 怎么选？我的经验之谈
你可能会问：「那我到底该选哪个？」
嗯，这个问题没有标准答案。但我可以给你几个判断依据：
- 看团队技术栈：如果全是 Java/Spring，无脑选 Spring Cloud Gateway。如果团队有 Nginx 运维经验，Kong 更合适。
- 看性能要求：QPS 超过 2 万，优先考虑 Kong。低于 2 万，Spring Cloud Gateway 完全够用。
- 看功能需求：需要丰富的插件（认证、限流、日志、监控），Kong 的插件生态最成熟。如果只是简单的路由转发，Spring Cloud Gateway 更轻量。
- 看预算：有钱且不想折腾，直接上商业版。没钱但有人力，开源版也能玩得转。
一个小建议：我个人习惯先拿 Spring Cloud Gateway 做原型验证。如果性能瓶颈了，再考虑迁移到 Kong。这样前期开发快，后期也有兜底方案。
好了，这一章就聊到这儿。下一章咱们深入讲讲网关的路由策略——怎么配、怎么调、怎么避坑。到时候见。