Enter your search text in the box above

Select a result to preview

API 閘道 (API Gateway)

#infrastructure #api-gateway #system-design
一句話定位

API Gateway 是客戶端與後端服務之間的統一入口（single entry point）。所有外部請求先進 Gateway，由它路由到對應服務，並在中途集中處理所有橫切關注點（認證、限流、SSL、轉換）。
心法：Gateway 保證「你是你說的那個人」，服務決定「你能做什麼」。

為什麼需要 API Gateway

當單體拆成十個微服務，每個服務有自己的 IP、port、API 格式。沒有 Gateway 時：

沒有 Gateway 有 Gateway
客戶端認得每個服務 客戶端只認得一個地址
認證/限流每個服務各做一遍 集中在 Gateway 一次處理
內部拓撲外露 後端細節對客戶端透明

核心職責

1. 請求路由（Routing）— 最基本功能

依路徑、HTTP method、header 把請求轉發到對應後端：

GET  /users/{id}     → 用戶服務 (user-service:8001)
GET  /orders/{id}    → 訂單服務 (order-service:8002)
POST /orders         → 訂單服務 (order-service:8002)
GET  /products/{id}  → 商品服務 (product-service:8003)

服務拆分、合併、換地址，只改 Gateway 路由規則，客戶端完全不受影響。

2. 認證與授權（AuthN & AuthZ）

集中認證，後端服務不必各自實作：

Client ──Bearer <JWT>──► API Gateway ──驗 JWT 簽名+有效期──► 解析 user_id
                            │
                            └─► 後端服務 (帶 X-User-Id: 123, X-User-Roles: admin)
                                後端「信任」這個 header，不再自己解 JWT

3. 限流（Rate Limiting）— 所有請求都經過它，最自然的限流點

維度 範例
按 API key 免費 60/分、付費 1000/分
按 IP 防單一來源洪水（DDoS 第一道防線）
按 endpoint 登入 / 簡訊驗證碼比一般 API 更嚴
全域 整體上限，保護後端不被打垮

超過閾值 Gateway 直接回 429 Too Many Requests，後端完全不知道這個請求存在。

4. SSL 終止（SSL Termination）

Gateway 處理 TLS handshake / 加解密，與後端在內網用 HTTP 溝通。

5. 請求/回應轉換 + 請求聚合

GET /dashboard
  ├── 用戶服務:  GET /users/123               → 姓名、頭像
  ├── 訂單服務:  GET /users/123/orders        → 最近訂單
  └── 通知服務:  GET /users/123/notifications → 未讀通知
  → 聚合成單一 JSON 回傳
聚合讓 Gateway 開始「懂業務」

有架構師認為 Gateway 應該保持薄薄一層，不該做聚合。這是設計選擇 —— 面試時說出你的考量即可。

6. 快取（Caching）

讀多寫少、回應不常變的公開資料（商品目錄、公告）可在 Gateway 快取，後端完全不必處理。個人化回應（購物車）不適合在此快取。

API Gateway vs Load Balancer（面試常見混淆）

維度 Load Balancer API Gateway
工作層次 L4（TCP/UDP）/ L7 L7（理解 HTTP 語義）
主要職責 流量分散、高可用 路由、認證、限流、轉換
理解業務邏輯 ❌ 否 ✅ 是
典型場景 同一服務的多實例 不同服務的統一入口
代表產品 ALB / NLB、Nginx AWS API GW、Kong、Envoy

兩者通常一起用，不是互相替代：

Internet → Load Balancer → API Gateway 集群 → 各後端服務
           (分散到多個 GW 實例)   (依內容路由)

LB 把流量分散到多個 Gateway 實例（避免 Gateway 成為 SPOF）；Gateway 再依請求內容路由到後端。LB 是流量分發器，Gateway 是智慧路由器。

BFF（Backend for Frontend）模式

不同客戶端對 API 的需求差異變大時，為每類客戶端維護各自的 Gateway：

Web Browser  → Web BFF      ─┐
iOS App      → Mobile BFF   ─┼─► 後端微服務
Android App  → Mobile BFF   ─┘
Third-party  → Public API Gateway

代價是多個 Gateway 要維護。適合有多個差異明顯的客戶端、各前端團隊能自維 BFF 的場景；小團隊用一個統一 Gateway 就夠。

常見實作

產品 特性 適合
AWS API Gateway 全受管 Serverless、與 Lambda 緊密整合、按請求計費 Serverless、不想自管基礎設施
Kong 開源、基於 Nginx、插件系統擴展 需高度客製、有 Nginx 經驗
Envoy / Istio Service Mesh 核心、sidecar proxy（mTLS/熔斷/追蹤） K8s 內部服務間流量
Nginx / Traefik 輕量、Traefik 自動發現 K8s 服務 只要基本路由 + SSL

Ingress Gateway 處理外部流量，Service Mesh 處理內部服務間流量 —— 兩者功能重疊但通常分開。

面試話術

提到微服務就主動說明 Gateway

「系統拆成用戶/訂單/商品服務。對外有一個 API Gateway 負責路由、JWT 認證、限流。客戶端只認得 Gateway 地址，後端的拆分與部署對客戶端透明。」

常見情境：

常見 Deep Dive

別把 Gateway 塞成第二個 Monolith

把太多業務邏輯塞進 Gateway，它會變成難測試、難維護的大泥球。Gateway 應該是薄薄的、可預期的轉發層，請求聚合要謹慎使用。

自我測驗重點

問題 重點
Gateway vs LB L7 智慧路由（懂業務）vs L4/L7 流量分發
認證 vs 授權 Gateway 認證、服務授權（粗粒度可在 GW）
Gateway 是否 SPOF 多實例 + 前掛 LB（無狀態好水平擴展）
限流跨實例 計數器存共享 Redis
效能開銷 1–5ms（路由+JWT 本地運算）
Gateway 反模式 塞爆業務邏輯 → 第二個 monolith