API 閘道（API Gateway）是微服務架構中至關重要的基礎設施組件，作為系統的統一入口，承擔路由、安全、限流等關鍵職責。本章涵蓋 API 閘道的原理、功能與實作。

為什麼需要 API 閘道#

微服務架構的挑戰#

在微服務架構中，內部通常包含多個獨立的服務模組（如購物車服務、庫存服務、推薦服務、訂單服務等），這些服務由不同的團隊獨立維護。

對於外部用戶端而言：

• 不應該直接感知到後端複雜的服務拓撲結構
• 不應該需要知道每個服務的地址
• 不應該處理跨服務的通用邏輯（如認證、限流）

API 閘道的核心價值#

API 閘道對外提供一個「統一的介面」。無論後端有多少個微服務在運作，外部使用者面對的只是一個統一的服務入口。這不僅簡化了用戶端的呼叫邏輯，也保護了內部架構的隱私與安全。

flowchart TB
    subgraph Clients["外部用戶端"]
        C1["Web App"]
        C2["Mobile App"]
        C3["Third Party"]
    end

    Clients --> GW["API Gateway<br/>(統一入口)"]

    GW --> S1["用戶服務"]
    GW --> S2["訂單服務"]
    GW --> S3["商品服務"]

    style GW fill:#fff3e0

API 閘道的部署架構#

典型的請求鏈路#

從部署視圖來看，API 閘道通常位於負載均衡器與內部微服務之間：

flowchart TB
    L1["1. 用戶接入層<br/>無線設備、桌面應用、伺服器等"]
    L2["2. 負載均衡層<br/>接收外部流量並分發"]
    L3["3. API 閘道層<br/>處理路由、認證等邏輯"]
    L4["4. 微服務層<br/>實際的業務邏輯處理單元"]

    L1 --> L2 --> L3 --> L4

    style L1 fill:#e3f2fd
    style L2 fill:#e8f5e9
    style L3 fill:#fff3e0
    style L4 fill:#f3e5f5

高可用設計原則#

為了確保系統的高可用性，通常會在閘道前置一層負載均衡器。這要求閘道本身設計為「無狀態（Stateless）」的。

無狀態設計的優勢：

• 允許閘道進行水平擴展（Scale-out）
• 即使某一台閘道實例故障，流量可以無縫切換至其他存活節點
• 避免單點故障（SPOF）
• 保障整體系統的穩定性

API 閘道的四大核心功能#

1. 反向路由 (Reverse Routing)#

這是閘道最基本的功能。當外部請求進入時，閘道需要根據請求的特徵（如 URL 路徑），將其精準地「導航」並轉換為內部具體服務的呼叫。

路由組態示例：

routes:
  - path: /api/users/**
    service: user-service
  - path: /api/orders/**
    service: order-service
  - path: /api/products/**
    service: product-service

路由策略：

2. 安全認證 (Security Authentication)#

如同門衛負責識別訪客身份，閘道是防禦惡意攻擊的第一道防線。

主要職責：

認證流程示例：

flowchart TD
    A["1. 用戶端發送請求<br/>(攜帶 Token)"] --> B["2. 閘道提取並驗證 Token"]
    B -->|驗證失敗| C["返回 401 Unauthorized"]
    B -->|驗證成功| D["3. 提取用戶資訊"]
    D --> E["4. 將用戶資訊注入請求頭"]
    E --> F["5. 轉發請求到後端服務"]

    style C fill:#ffcdd2
    style F fill:#c8e6c9

3. 限流與熔斷 (Rate Limiting & Circuit Breaking)#

應對突發流量（如「雙 11」大促、秒殺活動）的關鍵機制。

限流 (Rate Limiting)：

當大流量洪峰湧入時，如果沒有防護措施，後端服務極易癱瘓。閘道需實施限流策略，拒絕超過系統負荷的請求。

常見限流演算法：

限流演算法的資料結構選型與實作細節詳見 微服務鑑權與限流。

熔斷 (Circuit Breaking)：

當後端某個服務出現不穩定時，閘道可快速切斷對該服務的呼叫，防止故障擴散導致雪崩效應。

stateDiagram-v2
    [*] --> Closed: 初始狀態
    Closed --> Open: 失敗率超過閾值
    Open --> HalfOpen: 經過一段時間
    HalfOpen --> Closed: 嘗試請求成功
    HalfOpen --> Open: 嘗試請求失敗

    note right of Closed: 正常狀態
    note right of Open: 快速失敗<br/>不呼叫後端服務
    note right of HalfOpen: 嘗試少量請求

4. 日誌監控 (Logging & Monitoring)#

由於所有外部流量都必須經過閘道，這使其成為資料採集的最佳位置。

主要功能：

閘道過濾器架構#

以 Netflix Zuul 為例#

Zuul 的請求處理流程通過一系列的過濾器來完成，主要分為三個階段：

flowchart TD
    A[請求進入] --> B[Pre-routing Filters<br/>前置過濾器]
    B --> |日誌處理<br/>路由決策<br/>參數校驗| C[Routing Filters<br/>路由過濾器]
    C --> |服務呼叫<br/>網路請求| D[Post-routing Filters<br/>後置過濾器]
    D --> |響應加工<br/>統計審計<br/>日誌記錄| E[響應返回]

    B -.-> |異常| F[Error Filters<br/>錯誤處理]
    C -.-> |異常| F
    D -.-> |異常| F
    F --> E

    style B fill:#e3f2fd
    style C fill:#fff3e0
    style D fill:#e8f5e9
    style F fill:#ffebee

在 Pre、Routing、Post 的任一環節中，若發生錯誤或拋出異常，流程會轉交給 Error Filters 進行全域的錯誤處理與訊息封裝，確保用戶端能收到格式統一的錯誤回應。

動態過濾器機制#

閘道作為流量入口，通常承受巨大的訪問壓力，不適合頻繁重啟。但業務需求往往需要頻繁調整閘道邏輯。

Zuul 的解決方案：使用 Groovy 腳本編寫過濾器，支援動態載入。

請求上下文共享#

由於請求會流經多級過濾器，需要在不同階段之間傳遞資料。

Request Context：

• 基於 ThreadLocal 實作
• 允許在單次請求的生命週期內，讓 Pre、Routing、Post 等各階段的過濾器共享狀態與資訊

閘道設計的權衡#

瘦閘道 vs 胖閘道#

在實際的架構演進中，關於閘道的職責邊界往往存在爭議：是否應該在 API 閘道層引入「業務邏輯」？

瘦閘道 (Thin Gateway) - 推薦：

胖閘道 (Fat Gateway)：

建議保持閘道「輕量化」。若需處理複雜的資料聚合，可考慮引入獨立的 BFF (Backend for Frontend) 層，而不是將邏輯塞入全域的 API 閘道中。

BFF 模式#

當需要為不同的前端（Web、iOS、Android）提供定製化的 API 時，可以採用 BFF 模式：

flowchart TB
    subgraph Apps["用戶端應用"]
        A1["Web App"]
        A2["iOS App"]
        A3["Android App"]
    end

    subgraph BFFs["BFF 層"]
        B1["Web BFF"]
        B2["iOS BFF"]
        B3["Android BFF"]
    end

    A1 --> B1
    A2 --> B2
    A3 --> B3

    B1 --> GW
    B2 --> GW
    B3 --> GW

    GW["API Gateway"] --> MS["後端微服務"]

    style BFFs fill:#e3f2fd
    style GW fill:#fff3e0

常見的 API 閘道實作#

實踐建議#

閘道設計清單#

常見問題與解決方案#

同步與非同步閘道架構#

閘道的底層 I/O 模型直接決定了其效能特性、程式設計複雜度與運維難度。以 Netflix Zuul 的兩代架構為例，可以清楚看到同步阻塞與非同步非阻塞兩種模型的根本差異。

阻塞式多執行緒模型（Zuul 1.x / Servlet）#

Zuul 1.x 基於 Servlet 建置，採用 Thread-per-Connection 模式：伺服器為每一個請求分配一個專屬執行緒，該執行緒負責請求的完整生命週期（讀取請求、執行過濾器、呼叫後端服務、接收響應、寫回用戶端）。當涉及 I/O 操作時，執行緒會進入阻塞狀態，直到操作完成。

flowchart LR
    subgraph ThreadPool["Servlet 執行緒池"]
        T1["Thread-1<br/>(處理 Request A)"]
        T2["Thread-2<br/>(處理 Request B)"]
        T3["Thread-3<br/>(阻塞等待後端回應)"]
        T4["Thread-N<br/>(空閒)"]
    end

    Client["用戶端請求"] --> ThreadPool
    ThreadPool --> Backend["後端微服務"]

    style T3 fill:#ffcdd2
    style T4 fill:#e8f5e9

非阻塞非同步模型（Zuul 2.x / Netty）#

Zuul 2.x 引入基於 Netty 的事件驅動架構，採用 Event Loop 模型：每個 CPU Core 對應少量事件環執行緒，請求進入後放入事件佇列，執行緒持續監聽並處理事件，前後端均透過非同步回撥機制處理。

flowchart LR
    subgraph EventLoop["Event Loop（少量執行緒）"]
        E1["Event Loop Thread 1"]
        E2["Event Loop Thread 2"]
    end

    Queue["事件佇列"] --> EventLoop
    Client["用戶端請求"] --> Queue
    EventLoop --> Backend["後端微服務<br/>(非同步回撥)"]

    style EventLoop fill:#e3f2fd

架構元件對映#

Zuul 2.x 在保留過濾器鏈（Filter Chain）整體流程的同時，對元件命名與底層實作進行了調整：

兩種模型的比較#

ThreadLocal 失效問題：許多監控工具（如 CAT）和框架（如 RequestContext）依賴 ThreadLocal 儲存上下文資訊。在非同步模型下，執行緒會頻繁切換，導致 ThreadLocal 機制失效，必須進行複雜的封裝改造。這是從同步遷移到非同步架構時最容易被忽略的陷阱。

Zuul 2.x 的新增特性#

除了底層模型變更，Zuul 2.x 還增強了以下功能：

• 協議支援：HTTP/2（更高效）、Mutual TLS（更安全）
• 彈性增強：自適應重試機制、來源併發保護（Origin Concurrency Protection，防止後端被沖垮）
• 運維特性：Request Passport（追蹤請求生命週期的時間戳，解決非同步除錯難題）、更細粒度的狀態碼與重試監控

選型建議：對於絕大多數日均請求量在億級到十億級的企業，Zuul 1.x（搭配 Async Servlet 優化）的效能已經綽綽有餘。為了 20% 的效能提升而承擔非同步模型帶來的開發與維護複雜度，在多數場景下並不划算。建議在測試環境進行 POC 驗證，重點關注與現有監控體系的相容性，以及團隊對非同步程式設計的運維能力。

閘道生產部署模式#

API 閘道作為流量入口，天然具備流量控制的能力。Netflix 利用這一特性，在閘道層實現了多種精密的部署與測試策略，串聯起從開發到正式上線的完整交付流程。

紅綠部署（Red-Green Deployment）#

本質上與「藍綠部署」相同，僅為 Netflix 內部的命名習慣。

flowchart LR
    GW["API Gateway"]

    subgraph Green["綠色叢集（舊版 V1）"]
        G1["Instance 1"]
        G2["Instance 2"]
    end

    subgraph Red["紅色叢集（新版 V2）"]
        R1["Instance 1"]
        R2["Instance 2"]
    end

    GW -->|"主要流量"| Green
    GW -.->|"灰度流量"| Red

    style Green fill:#c8e6c9
    style Red fill:#ffcdd2

• 綠色叢集（Green/Base）：執行舊版本（V1），承載主要生產流量
• 紅色叢集（Red/New）：執行新版本（V2），初期僅接收少量灰度流量
• 切換策略：若新版本無異常，逐步將全量流量切往紅色叢集；若發現問題，隨時將流量切回綠色叢集

金絲雀測試（Canary Testing）#

標準金絲雀#

將少量流量導向新版本（Canary），與舊版本（Baseline）進行健康指標對比。閘道根據預設的流量比例進行分配。

粘性金絲雀（Sticky Canary）#

在涉及前端改版或多步驟交易流程時，必須啟用粘性金絲雀。若使用者在操作過程中版本跳動（例如購物車邏輯在新舊版不同），極可能導致交易失敗或資料錯誤。

• 問題：標準金絲雀中流量隨機分配，使用者可能在請求間於新舊版本跳轉
• 解決方案：閘道記錄使用者 ID 或 IP，確保同一使用者的所有請求始終被路由到同一個版本

壓力測試 — 流量映像（Squeeze Testing）#

為了測試單一伺服器或叢集的極限承載力，利用閘道複製真實的生產流量。

flowchart LR
    GW["API Gateway"]

    GW -->|"正常流量"| Prod["生產叢集"]
    GW -->|"複製流量"| Squeeze["壓力測試叢集"]

    Prod --> Response["Response → 返回用戶端"]
    Squeeze --> Discard["Response → 直接丟棄"]

    style Squeeze fill:#fff3e0
    style Discard fill:#ffcdd2

• 流量映像：閘道複製一份真實的生產流量（Copy Traffic）
• 轉發與丟棄：複製的流量打入壓力測試叢集，處理後的 Response 直接丟棄，不返回用戶端

使用真實流量進行壓力測試（Traffic Shadowing），比人工生成的模擬資料更能反映系統在真實世界中的效能瓶頸與潛在問題。

除錯路由（Debug Routing）#

當生產環境出現難以復現的 Bug 時，閘道提供動態除錯能力：

• 操作：開發者在請求中加入特殊的 Header 或標記
• 路由：閘道識別後，將該請求轉發至專門部署的「除錯叢集」
• 目的：在隔離環境中進行斷點調試或日誌分析，完全不干擾正常生產流量

跨區域高可用（Cross-Region HA）#

在多區域部署架構中，閘道扮演著故障轉移的關鍵角色：

flowchart TB
    DNS["DNS / Global Load Balancer"]

    subgraph RegionA["區域 A（美西）"]
        ELB_A["ELB"] --> Zuul_A["Zuul 叢集"]
        Zuul_A --> Services_A["微服務叢集"]
    end

    subgraph RegionB["區域 B（美東）"]
        ELB_B["ELB"] --> Zuul_B["Zuul 叢集"]
        Zuul_B --> Services_B["微服務叢集"]
    end

    DNS --> ELB_A
    DNS --> ELB_B

    RegionA -.->|"故障轉移"| RegionB

    style RegionA fill:#e3f2fd
    style RegionB fill:#e8f5e9

• 多活架構：每個區域皆部署獨立的閘道叢集
• 故障轉移：若某區域的機房或服務發生故障，閘道能感知錯誤，並將流量自動切換至健康的區域
• 安全防護：閘道作為統一入口，識別並拒絕惡意流量、爬蟲或 DDoS 攻擊
• 健康檢查與遮蔽：主動監控後端微服務節點，發現延遲過高或無回應時自動從路由表中摘除

閘道生產最佳實踐#

以下是在生產環境中運維閘道的關鍵經驗總結，適用於基於 Servlet 同步模型的閘道（如 Zuul 1.x），但其核心原則對所有閘道架構同樣適用。

1. 啟用 Async Servlet 提升連線能力#

Zuul 1.x 本質上是同步阻塞模式，受限於執行緒池與連線數。在不切換到完全非同步架構的前提下，啟用 Async Servlet（Servlet 3.0） 是最實用的優化手段。

• 原理：釋放容器執行緒去處理其他連線，待後端處理完畢再回撥寫回
• 效果：雖然業務邏輯仍可能同步執行，但能顯著提升連線數的支撐能力，解決閘道連線耗盡的問題

啟用 Async Servlet 需要在 web.xml 中顯式開啟非同步支援（<async-supported>true</async-supported>），並在程式碼層面使用對應的非同步版本。

2. 整合 Hystrix — 使用訊號量隔離#

在閘道層面整合 Hystrix 時，必須使用「訊號量隔離（Semaphore Isolation）」而非「執行緒池隔離（Thread Pool Isolation）」。閘道本身已是執行緒模式，若再為每個後端服務設定獨立的執行緒池，將導致閘道內部執行緒數量激增，Context Switch 開銷劇烈膨脹，極易耗盡伺服器資源。使用訊號量限制併發數即可達到隔離效果，同時節省資源。

3. 精細化連線池管理#

對於後端數十甚至上百個微服務，不能使用統一的粗放管理，必須對 HTTP Client 的連線池進行逐服務的精細化控制：

• 預設限制：為每個後端服務設定基礎連線數上限（例如平均 20 個連線），防止單一服務故障耗盡所有閘道連線
• 動態調整：針對高流量的熱點服務，支援動態調大連線池
• 設定中心整合：將連線池參數接入設定中心（如 Apollo），實現不重啟閘道即可調整

連線池管理的核心思想是「資源隔離」。每個後端服務擁有獨立的連線配額，即使某個服務出現延遲導致連線佔滿，也不會影響其他服務的正常呼叫。

4. 監控體系建設#

閘道作為流量入口，必須具備全方位的可觀測性。建議採用多層次的監控組合：

沒有監控的閘道就是黑盒子。當 Hystrix Dashboard 顯示某服務熔斷（紅色）時，運維人員應能立即感知並介入處理。

5. 保持閘道輕量化#

閘道應定位為「透明代理」，嚴禁包含複雜的業務邏輯：

• 避免重操作：不要在閘道層解包 HTTP Body 進行繁重的業務處理，這會消耗大量 CPU 與記憶體
• 輕量級驗證：Token 驗證應儘可能簡單（如查詢快取），避免呼叫高延遲的後端服務
• 非同步優先：若必須進行外部呼叫，儘量採用非同步方式

6. 自助服務運維能力#

隨著業務線擴充（無線、H5、第三方合作），閘道叢集會變得複雜。應致力於將閘道「服務化」，降低運維團隊的瓶頸：

• 提供視覺化的路由管理工具與檔案
• 允許業務開發人員自助設定路由規則
• 支援自助上傳與管理過濾器
• 整合設定中心，讓限流閾值、連線池參數等可動態調整