在現代分散式系統與微服務架構中，當一個 HTTP/TCP 請求從外部客戶端發送到後端資料庫時，通常會經過多個流量中介節點。
工程師在設計系統時，常會對這三個組件感到困惑：
- 負載均衡器（Load Balancer）
- 反向代理（Reverse Proxy）
- API 閘道（API Gateway）
它們都能轉發流量、都能做健康檢查、甚至都能做基礎的路由。既然 Nginx 也能做負載均衡與反向代理，為什麼微服務體系還需要引入 Envoy 或 Kong 這樣的 API Gateway？
本文基於 Envoy Proxy 架構手冊、Nginx 官方架構指南 與 ByteByteGo System Design 101，深入釐清三者的職責邊界、適用情境與核心限流演算法。
01. 流量調度
負載均衡器 (Load Balancer)
專注 L4/L7 網路封包分發、健康檢查與橫向擴展，不碰業務 Payload，最大化高併發吞吐。
↓ 邊緣防護與靜態快取
02. 邊緣代理
反向代理 (Reverse Proxy)
隱藏內部 IP、集中 TLS 憑證卸載、靜態資產快取與 Gzip 壓縮，以 Nginx 為典型代表。
↓ 業務治理與微服務管控
03. 業務治理中樞
API 閘道 (API Gateway)
微服務單一入口：承載 OAuth/JWT 鑑權、Token Bucket 權杖桶動態限流、gRPC/REST 協定轉換、BFF 聚合與熔斷防禦。
1. 負載均衡器（Load Balancer）：極致吞吐與高可用
負載均衡器的核心使命非常純粹：在多個後端伺服器節點之間均勻分發網路流量，防止單點過載，並提供自動故障轉移（Failover）。
L4 四層 vs. L7 七層負載均衡
- L4（傳輸層，TCP/UDP）：只根據 IP 地址與 Port 進行 NAT 轉發或 Direct Server Return（DSR），不檢查 HTTP 標頭與 Payload。延遲極低（微秒級），適用於超高併發的網路入口（如 AWS Network Load Balancer）。
- L7（應用層，HTTP/HTTPS）：完整解析 HTTP 協定，可根據請求路徑（如
/usersvs/orders）或 Header 中的授權資訊將流量導向不同集群。
主流負載均衡演算法
- 加權輪詢（Weighted Round Robin）：依伺服器硬體規格配置權重循環分發。
- 最小連線數（Least Connections）：優先分派給當前活躍 TCP 連線數最少的伺服器，適合長連線或耗時不均的業務。
- 一致性雜湊（Consistent Hashing）：依據 Client IP 或 UserID 進行雜湊，保證同一用戶的請求穩定路由至相同伺服器，提高快取命中率。
2. 反向代理（Reverse Proxy）：邊緣防護與靜態卸載
正向代理（Forward Proxy）代表客戶端發送請求（例如科學上網、公司內網出站代理）；而反向代理（Reverse Proxy）代表伺服器接收請求。
反向代理的四大核心能力（以 Nginx 為例）
- 隱藏內部拓撲與 IP 保護：外部用戶只能看到反向代理的公開 IP，後端真實伺服器部署在私有子網（Private Subnet），杜絕直接網路攻擊。
- TLS / SSL 集中卸載（TLS Termination）：在邊緣集中管理 SSL 憑證與加解密計算，減輕後端應用伺服器的 CPU 負擔。
- 靜態資源快取與壓縮：對 HTML、CSS、JS 與圖片提供記憶體/磁碟快取，並透過 Gzip 或 Brotli 演算法進行即時壓縮。
- 緩慢客戶端防護（Buffering & Slowloris 防禦）：反向代理以極快速度接收後端伺服器的回應並緩存，再慢慢發送給弱網客戶端，避免後端工作執行緒被慢客戶端長期佔用。
3. API 閘道（API Gateway）：現代微服務的治理大腦
如果說反向代理是「靜態的網路門衛」，那麼 API 閘道就是**「智慧的微服務控制面與業務中樞」**。
API Gateway 專門為解決微服務生態中的複雜通訊而生：
API Gateway 相比反向代理的躍遷
- 動態服務發現（Service Discovery）：與 Kubernetes、Consul 或 Eureka 聯動，後端 Pod 動態擴縮容時，閘道無需重載設定檔（No Reload）即可即時感知。
- BFF 介面聚合（Backend-for-Frontend）：手機端發起一次請求，閘道在內部並行呼叫 5 個微服務並組合為單一 JSON 回傳，大幅降低行動端延遲與電量消耗。
- 協定轉換（Protocol Translation）：外部統一暴露標準 HTTP/JSON，閘道內部自動轉換為高效的 gRPC / Thrift 二進位協定。
- 宣告式動態控制面（Dynamic Control Plane）：以 Envoy xDS API 為代表，路由與安全規則透過 gRPC 動態下發，秒級全域生效。
核心限流演算法深度對比（Rate Limiting）
在高併發場景下，API Gateway 與反向代理必須透過速率限制保護後端服務免於被流量沖垮。
1. 權杖桶演算法（Token Bucket）
- 原理：系統以固定速率
r向容量為b的桶中放入 Token。每個請求必須獲取 1 個 Token 才能被處理；桶滿時 Token 溢出丟棄。 - 特點：允許一定程度的突發流量（Traffic Burst）。只要桶內有累積 Token，突發請求可以立即被放行。
- 應用：Envoy、Guava RateLimiter、AWS API Gateway 主力演算法。
2. 漏桶演算法（Leaky Bucket）
- 原理：請求像水一樣隨意倒入桶中，桶底以絕對恆定的速率流出請求進行處理。若流入速率大於流出且桶滿，溢出的請求直接被拒絕。
- 特點：強制平滑輸出（Traffic Shaping），完全不允許突發流量。
- 應用：Nginx
limit_req模組底層機制。
3. 滑動窗口日誌 / 計數器（Sliding Window）
- 原理：將時間劃分為更細的網格（例如將 1 分鐘劃為 60 個 1 秒格子），動態滑動時間窗口統計請求總數。
- 特點：徹底解決了「固定窗口（Fixed Window）」在窗口交界處可能產生 2 倍流量峰值（Double Spurt）的邊界缺陷。
- 應用：Redis 分散式限流常見實作。
| 限流演算法 | 允許突發流量 (Burst) | 流量輸出平滑度 | 記憶體開銷 | 適用場景 |
|---|---|---|---|---|
| 固定窗口 | 差 (交界處 2x 突發) | 差 | 極低 (O(1)) | 粗粒度 API 配額限制 |
| 漏桶演算法 | 否 (嚴格恆定) | 極高 | 低 | 平滑發送訊息至第三方支付/簡訊服務 |
| 權杖桶演算法 | 是 (至桶上限) | 良好 | 低 | 微服務 API Gateway 首選 |
| 滑動窗口 | 是 | 良好 | 中等 | 精準防暴力破解與防刷介面 |
三大組件全景定位對比矩陣
| 評估維度 | 負載均衡器 (Load Balancer) | 反向代理 (Reverse Proxy) | API 閘道 (API Gateway) |
|---|---|---|---|
| 主要工作層級 | OSI L4 / L7 | OSI L7 | OSI L7 + 業務應用層 |
| 核心職責 | 流量負載分發、高可用 | 邊緣防護、TLS 卸載、快取 | 身份鑑權、BFF 聚合、微服務治理 |
| 服務發現能力 | 靜態 IP / DNS | 靜態設定檔為主 | 動態原生整合 (K8s / Consul) |
| 協定轉換能力 | 無 | 有限 (HTTP ➔ FastCGI) | 強 (HTTP ⇄ gRPC ⇄ GraphQL) |
| 限流與熔斷 | 基礎連線數限制 | 基礎 IP 頻率限制 (漏桶) | 細粒度業務限流、熔斷、自適應 |
| 代表技術 | AWS ALB/NLB, F5, HAProxy | Nginx, Caddy, Apache | Envoy, Apache APISIX, Kong, Spring |
系統架構師的選型建議
1. 現代雲原生標準拓撲
- 最外層用 L4 負載均衡器承載百萬級連線與 DDoS 攻擊；
- 內層由 API Gateway 負責身份鑑權、路由排程、BFF 聚合與指標監控。
2. 關鍵工程實踐
- 不要在 Nginx 裡寫複雜業務邏輯：如果你的 Nginx 開始引入大量複雜 Lua 腳本或查詢資料庫進行鑑權，說明你已經需要一個真正的 API Gateway。
- 根據流量特徵選擇限流：用戶面 API 優先使用權杖桶以容忍正常突發；對外調用第三方有嚴格 TPS 限制的接口使用漏桶強制平滑。