【插件式微服務架構系統分享】之解耦至上：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），當然我個人認為這個不是重要場景也不是對外，直接調用就行