API 閘道器與反向代理專家

API 閘道器與反向代理專家 是做什麼的？

設定並最佳化 API 閘道器與反向代理，以實現路由、認證、速率限制與流量管理。

決策點

認證策略選擇

流量模式與需求
├── 僅限內部服務
│   └── API Key 認證
│       ├── 低複雜度，快速驗證
│       └── Kong: key-auth 外掛，Traefik: forwardAuth
├── 面向客戶的 API，需要工作階段
│   └── JWT 認證
│       ├── 無狀態，包含用戶聲明
│       └── Kong: jwt 外掛，Nginx: lua-resty-jwt
├── 企業 B2B 整合
│   └── mTLS 認證
│       ├── 基於憑證，安全性最高
│       └── Kong: mtls-auth，Nginx: ssl_verify_client
└── 第三方 SaaS 整合
    └── OAuth2 流程
        ├── 令牌交換，委派認證
        └── Kong: oauth2 外掛，AWS API Gateway: authorizer

閘道器技術選擇

需求 → 選擇
├── 需要外掛生態系與 GUI
│   └── Kong Enterprise/OSS
├── Kubernetes 原生，支援自動發現
│   └── Traefik v3 或 Ingress-NGINX
├── 最大效能，最少功能
│   └── Nginx 或 Envoy
└── 雲端管理，無伺服器擴展
    └── AWS API Gateway 或 Azure Application Gateway

上游路由策略

服務架構 → 路由方法
├── 微服務搭配服務發現
│   └── 動態上游目標
│       ├── Consul/Eureka 整合
│       └── 基於健康檢查的負載平衡
├── 靜態後端服務
│   └── 固定上游池
│       ├── 輪詢或最少連接
│       └── 加權路由用於金絲雀部署
└── 多區域部署
    └── 地理路由
        ├── 基於延遲或地理 IP
        └── 容錯轉移至次要區域

故障模式

閘道器超時串聯

症狀： API 回應緩慢（>10 秒）於負載下
檢測： 回應時間飆升，而上游服務報告正常延遲
根本原因： 閘道器超時時間高於上游超時時間，導致請求排隊
修復： 設定閘道器讀取超時 < 上游超時（閘道器：30 秒，上游：25 秒）

認證繞過

症狀： 未經授權的請求到達後端服務
檢測： 後端日誌顯示缺少預期認證標頭的請求
根本原因： 路由順序允許寬鬆規則在認證規則之前匹配
修復： 將認證中介軟體移至全域層級，或確保特定路由在設定中優先出現

斷路器抖動

症狀： 流量高峰期間出現間歇性 503 錯誤
檢測： 斷路器快速開啟/關閉（每分鐘多次）
根本原因： 閾值過於敏感或健康檢查配置錯誤
修復： 調整故障閾值（5 次以上）與恢復時間（至少 30 秒）

SSL 憑證過期

症狀： HTTPS 握手失敗，瀏覽器憑證警告
檢測： SSL 憑證檢查顯示將在 30 天內過期
根本原因： 手動管理憑證，缺乏自動更新機制
修復： 實作 cert-manager (K8s) 或支援自動更新的 ACME 客戶端

資源耗盡

症狀： 閘道器停止接受連接，記憶體/CPU 使用率達 100%
檢測： 連接被拒錯誤，閘道器健康檢查失敗
根本原因： 未設定連接限制或外掛記憶體洩漏
修復： 設定 worker_connections (Nginx) 或連接池限制 (Kong)，重新啟動閘道器

實作範例

情境：電商 API 閘道器設定

背景： 為處理訂單、庫存、付款的微服務部署 Kong，並使用 JWT 認證

步驟 1：路由定義

# 首先識別服務端點
services:
  - orders: /api/v1/orders/* → http://orders:8080
  - inventory: /api/v1/inventory/* → http://inventory:8080  
  - payments: /api/v1/payments/* → http://payments:8080

步驟 2：應用決策樹

• 流量模式：面向客戶的 API → JWT 認證
• 架構：微服務 → 動態上游目標
• 需求：需要外掛生態系 → 選擇 Kong

步驟 3：外掛排序

# 按正確順序套用外掛
plugins:
  1. cors (預認證)
  2. jwt (認證) 
  3. rate-limiting (認證後)
  4. request-transformer (最後)

專家 vs 新手：

• 新手錯誤： 在認證前套用速率限制（匿名用戶消耗配額）
• 專家做法： 先認證，再根據已認證用戶進行速率限制
• 新手錯誤： 使用全域 CORS 策略
• 專家做法： 為不同路由設定不同 CORS（訂單路由允許管理員來源，付款路由限制僅限前端）

失敗情境：金絲雀部署出錯

情況： 將 20% 流量部署到新的訂單服務版本，出現 500 錯誤

檢測流程：

1. 檢查閘道器指標：500 錯誤率飆升與部署時間相關
2. 上游健康檢查：新版本健康檢查失敗
3. 閘道器日誌：上游連接超時

回滾步驟：

# 步驟 1：立即切換流量
kong:
  routes:
    - service: orders-v1
      weight: 100  # 原本是 80
    - service: orders-v2  
      weight: 0    # 原本是 20

# 步驟 2：驗證回滾
curl -H "Authorization: Bearer $JWT" \
  https://api.company.com/orders/health

# 步驟 3：移除失敗的上游
kubectl scale deployment orders-v2 --replicas=0

根本原因分析： 新版本資料庫連接池配置錯誤，導致負載下超時

品質閘門

• 所有路由皆使用明確路徑匹配（無 catch-all /* 路由）
• 在業務邏輯外掛前配置認證中介軟體
• 健康檢查在 5 秒內對健康上游回傳 2xx
• 斷路器閾值設定：60 秒視窗內 5 次失敗，恢復時間 30 秒
• TLS 憑證自動更新，到期前仍保有 30 天以上
• 速率限制根據已認證用戶套用，非全域
• CORS 策略僅限制為所需的來源網域
• 閘道器超時（30 秒）< 上游超時（25 秒），以防止串聯
• 存取日誌包含用於請求追蹤的關聯 ID
• 閘道器至少部署 2 個副本以實現高可用性

不處理範圍

此技能處理： 閘道器配置、路由規則、認證中介軟體、反向代理設定

不處理：

• 速率限制演算法設計 → 使用 api-rate-limiting-throttling-expert
• 服務網格資料平面配置 → 使用 service-mesh-microservices-expert
• API 規格與設計 → 使用 api-architect
• 資料庫連接池 → 使用 database-performance-expert
• 容器編排 → 使用 kubernetes-expert 或 docker-expert
• SSL 憑證產生 → 使用 security-infrastructure-expert

委派規則：

• 對於自訂速率限制演算法：「我會配置速率限制外掛，但對於自訂演算法，請使用 api-rate-limiting-throttling-expert」
• 對於服務發現設定：「我會配置上游目標，但對於服務網格設定，請使用 service-mesh-microservices-expert」