【插件式微服务架构系统分享】之解耦至上：gateway 网关与APISIX 网关的不同分工
作者：朱元禄
一、一个比方
- APISIX 就像是一个专业的高速公路收费站，不属于你公司自己造的路，而是专门为所有车辆（流量）设计的，功能强大、扩展性好、可以插各种“插件”（比如限速、安检、计费、分流等）。
- 你项目里的 gateway（比如 Spring Cloud Gateway 或自研网关）就像是你公司门口的保安岗亭，主要负责自己公司的进出管理，和公司内部业务结合得很紧密。
二、技术对比（为啥一定要有 APISIX 这一层）
| 对比点 | APISIX（专业API网关） | 项目内 gateway（如Spring Cloud Gateway） |
|---|---|---|
| 定位 | 独立于业务的API流量入口，专注流量治理 | 业务系统自带的网关，和业务代码耦合较多 |
| 部署方式 | 独立服务，通常和业务解耦 | 项目代码里一部分，和业务服务一起维护 |
| 扩展能力 | 插件丰富（限流、鉴权、灰度、监控、WAF等） | 插件能力有限，主要靠Spring生态 |
| 动态路由 | 支持热更新、动态注册、服务发现（如Nacos） | 支持，但通常和Spring Cloud体系绑定 |
| 性能 | 高性能，专为大流量设计 | 性能较好，但受限于JVM和Spring生态 |
| 生态 | 支持多语言后端、K8s、云原生、OpenAPI等 | 主要服务于Java/Spring Cloud微服务 |
| 运维 | 独立运维，和业务服务分离 | 和业务服务一起运维 |
| 典型场景 | 多语言、多团队、插件化、商业化、SaaS平台 | 纯Spring Cloud微服务体系，业务耦合场景 |
三、结合项目实际
1. 项目里的 gateway
- 目录：
jeecg-server-cloud/jeecg-cloud-gateway/ - 作用：作为Spring Cloud微服务的统一入口，负责路由、鉴权、限流等，和JEECG-Boot业务体系深度集成。
- 适合：内部微服务调用、业务相关的流量管理。
2. 如果引入 APISIX
- 作为独立的API网关，放在所有流量最前面，负责所有外部/第三方/前端流量的统一入口。
- 可以和Nacos结合，自动发现你所有的微服务（包括主系统和插件）。
- 适合：插件化、商业化、SaaS多租户、对外API开放、流量治理、灰度发布等场景。
3. 两者如何配合？
- 最优做法：
- APISIX 作为最外层的“总入口”，负责所有外部流量的统一治理、插件化扩展、动态路由。
- 你项目的 gateway 作为内部微服务的“二级网关”，继续负责和业务强相关的路由、鉴权、内部限流等。
- 流量路径：
用户/前端 → APISIX → 你项目的 gateway → 各业务服务/插件
四、最简单的落地实践
- 不动现有 gateway，直接在前面加一层 APISIX，负责插件市场、商业化、对外API等流量治理。
- 插件服务、主系统都注册到Nacos，APISIX自动发现并路由。
- 这样既保留了你项目原有的微服务体系，又获得了APISIX的强大流量治理和插件化能力。
五、业务流量场景说明
1. 用户访问商城下单（涉及插件）
场景说明
- 用户在商城下单，可能会用到优惠券、会员价等插件功能。
- 需要鉴权、插件授权校验、服务间调用。
详细流程
用户请求
用户在前端点击“下单”，前端发起下单API请求（带JWT Token）。APISIX网关
- 首先到达APISIX。
- APISIX执行JWT鉴权（校验Token是否合法、是否过期）。
- APISIX根据路由规则，将请求转发到内部gateway。
gateway（内部网关）
- gateway根据请求路径，将流量路由到
core-service（商城核心服务）。 - gateway可做内部权限、限流等处理。
- gateway根据请求路径，将流量路由到
core-service（商城核心服务）
- 处理下单主流程。
- 检查用户是否有优惠券、会员资格等（需要用到插件）。
- 通过服务发现（Nacos），调用
coupon-service和member-service等插件服务。
插件服务（如coupon-service/member-service）
- 插件服务收到请求，先校验调用方（如租户、用户）是否有授权（查License中心或本地授权表）。
- 返回优惠券/会员价等信息给core-service。
core-service
- 汇总所有信息，完成下单逻辑，返回下单结果。
gateway → APISIX → 前端
- 响应一路返回，最终到达用户前端。
流程图
2. 用户查看报表插件
场景说明
- 用户想看报表（如销售统计），报表是一个插件服务。
详细流程
用户请求
用户在前端点击“查看报表”，前端发起API请求（带JWT Token）。APISIX网关
- 首先到达APISIX。
- APISIX执行JWT鉴权。
- APISIX根据路由规则，直接将请求转发到
report-service（报表插件服务）。
report-service（插件服务）
- 校验用户/租户是否有授权（查License中心或本地授权表）。
- 查询报表数据，返回结果。
APISIX → 前端
- 响应返回到前端，展示报表。
流程图
3. 内部服务间调用（无需APISIX）
场景说明
- core-service（商城核心）需要在业务流程中调用member-service（会员插件），比如下单时判断会员价。
详细流程
core-service发起调用
- 通过Nacos服务发现，找到member-service的地址。
- 直接通过gateway（或Spring Cloud内部负载均衡）发起HTTP/RPC调用。
gateway（可选）
- 如果内部服务间流量也统一走gateway，则gateway做一次内部路由。
member-service（插件服务）
- 校验调用方（如租户、服务授权）。
- 返回会员信息。
core-service处理业务
- 使用会员信息完成业务逻辑。
流程图
也可以C直接调用M（如果不强制走gateway），当然我个人认为这个不是重要场景也不是对外，直接调用就行