API 网关技术选型

在API 网关（API Gateway） ，Kong / APISIX 就是这一层常见的实现方案。

👉 API 网关 = 所有后端服务的统一入口

客户端 → API网关 → 用户服务 / 订单服务 / 支付服务

它的作用不是简单转发，而是"统一管理接口"。

Kong

• 基于 Nginx 做的 API 网关
• 出现更早，生态成熟
• 插件体系很丰富（认证、限流等）

Apache APISIX

• Apache Software Foundation 旗下项目
• 更偏云原生（支持动态配置）
• 性能更高（很多公司宣传点）
• 国内公司用得比较多

API 网关比 Nginx / Envoy 多了一层"业务治理能力"

1️⃣ 统一认证

• JWT / Token 校验
• 登录态验证

2️⃣ 限流

• 防刷接口
• 防止被打挂

3️⃣ 路由转发

• /user → 用户服务
• /order → 订单服务

4️⃣ 协议转换

• HTTP → gRPC
• WebSocket 支持

5️⃣ 日志 & 监控

• 记录每个 API 的调用情况

真实架构

用户 → CDN → WAF → API网关（Kong/APISIX） → 微服务 → 数据库

或者更复杂一点：

用户 → CDN → WAF → API网关 → 服务A → Envoy → 服务B

当有这些需求时👇

• 多个服务（用户、订单、支付）
• 需要统一认证（比如所有接口都要登录）
• 要做限流 / 风控
• 想对外提供开放 API（给第三方）

👉 这时候 API 网关是必备的

👉 Kong / APISIX = 专门做"API 管理"的网关，比 Nginx 更高一层，比 Envoy 更偏业务入口

在现实生产环境中 Kong / APISIX 不太会一起用------它俩本质是"同一层、同一定位"的产品，通常是二选一，而不是叠加使用。

但是和 Spring Cloud Gateway 却不一样，它俩中的任何一个是可以和 Spring Cloud Gateway 进行协同使用的。

vs Spring Cloud Gateway

Kong / APISIX

• 独立服务（单独部署）
• 通过配置或管理后台控制
• 不用写业务代码

👉 更像：运维/平台提供的网关

Spring Cloud Gateway

• 写在 Java 项目里，比较灵活（想怎么写就怎么写），但很多功能要自己实现
• 需要自己开发、打包、部署

👉 更像：自己写的一个网关服务

Kong / APISIX 属于平台级网关，可以被独立部署，属于基础设施层，可以为多个服务提供统一的流量治理能力；而 Spring Gateway 是嵌在某个 Java 服务里的网关，更偏应用层。

对于一个"多服务系统"来说，需要统一入口，所有请求统一经过网关做鉴权和路由。这个时候 Kong / APISIX 就有优势了，因为它使得所有服务共用一套网关，不需要每个服务都写一套 Gateway；并且它提供需要开箱即用的能力，比如限流、认证、黑白名单，可以插件直接用，而不用自己开发。如果使用 Spring Gateway 的话，很多要自己写。并且 Kong / APISIX 拥有动态配置能力，修改路由或限流策略时不需要重启服务，但是 Spring Gateway 通常要改配置或代码再发布。

Kong / APISIX 支持多语言，如果系统不是纯 Java，比如还有 Go / Python 服务，Kong / APISIX 更适合做统一入口。Spring Gateway 强绑定 Spring / Java。

如果是一个小型系统，或者团队完全基于 Spring 技术栈，使用 Spring Gateway 会更简单，开发效率也更高。

整体来看，在需要统一治理、插件能力强、支持动态配置的微服务架构下，优先选择 Kong / APISIX ；如果是单体或轻量级 Java 系统，Spring Gateway 也是一个很好的选择。

在大型系统中，Kong / APISIX 通常作为北向流量入口，而 Spring Gateway 可以作为南向或业务内部网关，两者是可以分层协作的。

常见架构

用户 → Kong/APISIX → Spring Gateway → 微服务

• Kong / APISIX：
  • 对外入口
  • 安全、限流、认证
• Spring Gateway：
  • 内部逻辑路由
  • 和业务深度耦合