启动一个新的微服务项目时，API 网关的选型是早期需要做出的关键决策之一。网关作为流量入口，承担了路由、认证、限流、监控等职责，直接影响后续系统的可维护性。
背景与需求
我们团队的技术背景：
- 主力语言：Java
- 技术框架：Spring Boot, Spring Cloud
- 部署环境：初期 Docker Compose，生产环境规划 Kubernetes
- 服务注册中心：Nacos
- 认证协议：OAuth2/OIDC（认证中心基于 Spring Authorization Server）
基于这个背景，我们梳理了三个核心需求：
- 动态性：与 Nacos 深度集成，支持服务自动发现和配置热更新
- 安全对接：无缝对接 OAuth2/OIDC 认证体系，处理 Token 验证
- 可扩展性：支持自定义插件，能够实现业务特定的准入控制和权限验证逻辑
候选方案
我们筛选了四个主流开源网关进行评估：
| 方案 | 底层技术 | 主要特点 |
|---|---|---|
| Kong | Nginx + Lua | 插件生态丰富，成熟度高 |
| Spring Cloud Gateway | Netty + Reactor | Spring 官方出品，与 Spring 生态深度集成 |
| Higress | Envoy | 阿里开源，拥抱 Wasm，适合服务网格场景 |
| Apache APISIX | Nginx | 云原生架构（etcd 存储），动态化设计，插件生态完善 |
对比分析
维度一：性能与架构
- Kong / APISIX：基于 Nginx，网络 I/O 性能优异，延迟低
- Higress：基于 Envoy，性能同样出色，与云原生生态结合紧密
- Spring Cloud Gateway：基于 Netty，性能良好，但在极限 QPS 场景下与 C++ 编写的 Nginx/Envoy 存在一定差距
结论：对性能要求较高的场景，Nginx 或 Envoy 方案更有优势。
维度二：服务发现与配置管理
- Spring Cloud Gateway / APISIX / Higress：与 Nacos 集成良好，支持动态发现配置热更新
- Kong：DB-less 模式下，服务发现和配置更新依赖第三方插件，动态性相对弱
结论：动态性是我们的刚需，Kong 在这个维度不占优。
维度三：插件开发与团队匹配度
这是最关键的维度，直接关系到开发效率和维护成本。
Spring Cloud Gateway：
- 对 Java 团队最自然的选择
- 使用 Spring Filter 模式编写插件，可以复用 Java 生态的所有工具
- 权衡：为了开发便利性，需要接受相对 Nginx/Envoy 的性能差距
Kong / APISIX：
- 插件使用 Lua 开发
- 对纯 Java 团队意味着引入新的语言栈，存在学习成本
- 但在 AI 辅助编程工具（如 GitHub Copilot、Cursor 等）的加持下，语言学习成本已大幅降低
- 关键是理解插件的生命周期和 API，具体语法实现可以借助 AI 快速完成
Higress：
- 插件模型基于 Wasm
- 技术前景好（多语言、安全沙箱），但工具链和生态还在发展，落地存在不确定性
决策
我们最终选择了 Apache APISIX。
理由：
- 满足性能要求（Nginx 内核）
- 与 Nacos 集成成熟，支持动态配置
- 插件生态完善，社区活跃
- 在 AI 辅助编程的加持下，Lua 开发成本可接受，不必因此放弃 Nginx 的高性能优势
总结
这次选型的几点体会：
- 先明确需求再比较：定义好自己的”标尺”，避免被技术热度左右
- 团队技能栈是重要考量，但不是绝对约束：在 AI 辅助编程工具普及的今天，跨语言开发的学习成本已大幅降低
- 关注”折衷”方案：像 APISIX 这样兼顾高性能底层和良好扩展性的方案，在特定场景下很实用
API 网关选型本质上是在多个维度之间做权衡：
- 性能 vs 开发效率：纯 Java 方案（SC Gateway）开发体验好但性能受限；Nginx 方案（Kong/APISIX）性能优异但需要学习 Lua，不过 AI 工具可以显著降低语言学习门槛
- 稳定性 vs 先进性：传统方案经过生产验证，新方案（Higress 的 Wasm）可能带来技术红利但也伴随不确定性
- 团队现状 vs 技术趋势：在 AI 辅助编程的加持下，不必过度纠结于技术栈的语言差异，更重要的是选择社区成熟、生态完善的方案
每个项目的需求和团队背景不同，选型没有标准答案。以上是我们的实际决策路径，供参考。