【插件式微服务架构系统分享】之解耦至上：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. 用户访问商城下单（涉及插件）

场景说明

• 用户在商城下单，可能会用到优惠券、会员价等插件功能。
• 需要鉴权、插件授权校验、服务间调用。

详细流程

1. 用户请求
   用户在前端点击“下单”，前端发起下单API请求（带JWT Token）。

2. APISIX网关

   • 首先到达APISIX。
   • APISIX执行JWT鉴权（校验Token是否合法、是否过期）。
   • APISIX根据路由规则，将请求转发到内部gateway。

3. gateway（内部网关）

   • gateway根据请求路径，将流量路由到core-service（商城核心服务）。
   • gateway可做内部权限、限流等处理。

4. core-service（商城核心服务）

   • 处理下单主流程。
   • 检查用户是否有优惠券、会员资格等（需要用到插件）。
   • 通过服务发现（Nacos），调用coupon-service和member-service等插件服务。

5. 插件服务（如coupon-service/member-service）

   • 插件服务收到请求，先校验调用方（如租户、用户）是否有授权（查License中心或本地授权表）。
   • 返回优惠券/会员价等信息给core-service。

6. core-service

   • 汇总所有信息，完成下单逻辑，返回下单结果。

7. gateway → APISIX → 前端

   • 响应一路返回，最终到达用户前端。

流程图

2. 用户查看报表插件

场景说明

• 用户想看报表（如销售统计），报表是一个插件服务。

详细流程

1. 用户请求
   用户在前端点击“查看报表”，前端发起API请求（带JWT Token）。

2. APISIX网关

   • 首先到达APISIX。
   • APISIX执行JWT鉴权。
   • APISIX根据路由规则，直接将请求转发到report-service（报表插件服务）。

3. report-service（插件服务）

   • 校验用户/租户是否有授权（查License中心或本地授权表）。
   • 查询报表数据，返回结果。

4. APISIX → 前端

   • 响应返回到前端，展示报表。

流程图

3. 内部服务间调用（无需APISIX）

场景说明

• core-service（商城核心）需要在业务流程中调用member-service（会员插件），比如下单时判断会员价。

详细流程

1. core-service发起调用

   • 通过Nacos服务发现，找到member-service的地址。
   • 直接通过gateway（或Spring Cloud内部负载均衡）发起HTTP/RPC调用。

2. gateway（可选）

   • 如果内部服务间流量也统一走gateway，则gateway做一次内部路由。

3. member-service（插件服务）

   • 校验调用方（如租户、服务授权）。
   • 返回会员信息。

4. core-service处理业务

   • 使用会员信息完成业务逻辑。

流程图

也可以C直接调用M（如果不强制走gateway），当然我个人认为这个不是重要场景也不是对外，直接调用就行