在API 网关（API Gateway） ，Kong / APISIX 就是这一层常见的实现方案。
👉 API 网关 = 所有后端服务的统一入口
text
客户端 → 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 的调用情况
真实架构
text
用户 → CDN → WAF → API网关（Kong/APISIX） → 微服务 → 数据库或者更复杂一点：
text
用户 → 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 可以作为南向或业务内部网关，两者是可以分层协作的。
常见架构
text
用户 → Kong/APISIX → Spring Gateway → 微服务- Kong / APISIX：
- 对外入口
- 安全、限流、认证
- Spring Gateway：
- 内部逻辑路由
- 和业务深度耦合