当前位置：首页 > news >正文

【插件式微服务架构系统分享】之解耦至上：gateway 网关与APISIX 网关的不同分工

news 2025/8/8 7:08:10

作者：朱元禄

APISIX 就像是一个专业的高速公路收费站，不属于你公司自己造的路，而是专门为所有车辆（流量）设计的，功能强大、扩展性好、可以插各种“插件”（比如限速、安检、计费、分流等）。
你项目里的 gateway（比如 Spring Cloud Gateway 或自研网关）就像是你公司门口的保安岗亭，主要负责自己公司的进出管理，和公司内部业务结合得很紧密。

对比点	APISIX（专业API网关）	项目内 gateway（如Spring Cloud Gateway）
定位	独立于业务的API流量入口，专注流量治理	业务系统自带的网关，和业务代码耦合较多
部署方式	独立服务，通常和业务解耦	项目代码里一部分，和业务服务一起维护
扩展能力	插件丰富（限流、鉴权、灰度、监控、WAF等）	插件能力有限，主要靠Spring生态
动态路由	支持热更新、动态注册、服务发现（如Nacos）	支持，但通常和Spring Cloud体系绑定
性能	高性能，专为大流量设计	性能较好，但受限于JVM和Spring生态
生态	支持多语言后端、K8s、云原生、OpenAPI等	主要服务于Java/Spring Cloud微服务
运维	独立运维，和业务服务分离	和业务服务一起运维
典型场景	多语言、多团队、插件化、商业化、SaaS平台	纯Spring Cloud微服务体系，业务耦合场景

最优做法：
- APISIX 作为最外层的“总入口”，负责所有外部流量的统一治理、插件化扩展、动态路由。
- 你项目的 gateway 作为内部微服务的“二级网关”，继续负责和业务强相关的路由、鉴权、内部限流等。
- 流量路径：
  用户/前端 → APISIX → 你项目的 gateway → 各业务服务/插件

用户请求
用户在前端点击“下单”，前端发起下单API请求（带JWT Token）。
APISIX网关
- 首先到达APISIX。
- APISIX执行JWT鉴权（校验Token是否合法、是否过期）。
- APISIX根据路由规则，将请求转发到内部gateway。
gateway（内部网关）
- gateway根据请求路径，将流量路由到core-service（商城核心服务）。
- gateway可做内部权限、限流等处理。
core-service（商城核心服务）
- 处理下单主流程。
- 检查用户是否有优惠券、会员资格等（需要用到插件）。
- 通过服务发现（Nacos），调用coupon-service和member-service等插件服务。
插件服务（如coupon-service/member-service）
- 插件服务收到请求，先校验调用方（如租户、用户）是否有授权（查License中心或本地授权表）。
- 返回优惠券/会员价等信息给core-service。
core-service
- 汇总所有信息，完成下单逻辑，返回下单结果。
gateway → APISIX → 前端
- 响应一路返回，最终到达用户前端。

用户请求
用户在前端点击“查看报表”，前端发起API请求（带JWT Token）。
APISIX网关
- 首先到达APISIX。
- APISIX执行JWT鉴权。
- APISIX根据路由规则，直接将请求转发到report-service（报表插件服务）。
report-service（插件服务）
- 校验用户/租户是否有授权（查License中心或本地授权表）。
- 查询报表数据，返回结果。
APISIX → 前端
- 响应返回到前端，展示报表。

core-service发起调用
- 通过Nacos服务发现，找到member-service的地址。
- 直接通过gateway（或Spring Cloud内部负载均衡）发起HTTP/RPC调用。
gateway（可选）
- 如果内部服务间流量也统一走gateway，则gateway做一次内部路由。
member-service（插件服务）
- 校验调用方（如租户、服务授权）。
- 返回会员信息。
core-service处理业务
- 使用会员信息完成业务逻辑。