閘道器與反向代理

🎯 核心問題

在高併發的網際網路架構中，如何把流量安全、高效地送到正確的服務？ 反向代理解決「流量怎麼分發」，API 閘道器解決「請求怎麼處理」。本文透過真實案例（櫃檯接待、保全系統、智慧路由）深入理解閘道器的設計哲學和工程實務。

1. 為什麼要「閘道器」？

1.1 從一個真實案例說起：某電商的架構演進

某電商平台在業務快速成長時遇到了嚴重的架構問題：

場景還原：

階段一：直接暴露服務
客戶端 → 直接呼叫使用者服務、訂單服務、支付服務...
         ↓
問題1：服務 IP 暴露，存在安全隱患
問題2：無法統一做認證、限流
問題3：新增服務需要修改客戶端組態

⚠️ 直接暴露的致命問題

安全隱患：所有服務 IP 暴露，容易被攻擊
功能重複：每個服務都要做認證、限流、日誌
擴充困難：新增服務要修改所有客戶端
協定混亂：有的用 HTTP，有的用 gRPC，客戶端要適配

改進後的架構（引入閘道器）：

客戶端 → API 閘道器（Nginx/Kong） → 內部服務
         ↓
      統一認證、限流、路由
         ↓
      客戶端只知道閘道器位址

✨ 改進後的效果

安全：真實服務 IP 隱藏，只有閘道器對外
功能收斂：認證、限流、日誌在閘道器統一處理
擴充容易：新增服務只需閘道器組態路由
協定統一：對外 HTTP，內部可用 gRPC

1.2 閘道器的生活化比喻

櫃檯接待

想像你去一家大公司：

沒有櫃檯：訪客直接找各部門，不知道在哪，公司亂成一團
有櫃檯：訪客先到櫃檯，櫃檯問清楚來意，再引導到對應部門

API 閘道器就是系統的「櫃檯」：

反向代理：櫃檯，引導訪客到正確的部門
API 閘道器：智慧櫃檯，還能檢查訪客身分（認證）、限制存取人數（限流）

👤

用户 (浏览器)

→

访问域名

🛡️

反向代理 (Nginx)

代理服务器

→

负载均衡

⚙️

后端服务器集群

Web1 | Web2 | Web3

🛡️ 反向代理特点

客户端无感知，只需要访问域名
隐藏真实服务器架构，统一对外接口
提供负载均衡、安全防护、SSL卸载等功能
典型代表：Nginx、HAProxy、AWS ELB

💡 典型使用场景

网站需要承载高并发流量（负载均衡）
统一HTTPS证书管理（SSL卸载）
防护DDoS攻击和SQL注入
灰度发布、A/B测试、蓝绿部署

🧠 记忆口诀

"反向代理 = 代理服务器" —— 客户端不知道真实服务器，只知道域名

2. 什麼是反向代理？

2.1 正向代理 vs 反向代理

🤔 術語解釋

正向代理（Forward Proxy）：

部署在客戶端側
代替客戶端存取外部資源
典型應用：VPN、翻牆工具
例子：公司網路，你透過代理存取外網

反向代理（Reverse Proxy）：

部署在伺服器端
接收客戶端請求並轉發給內部服務
客戶端只知道代理存在，不知道真實伺服器
例子：Nginx、HAProxy

對比表：

維度	正向代理	反向代理
部署位置	客戶端側	伺服器端
服務對象	客戶端	伺服器
典型應用	VPN、翻牆	負載平衡、閘道器
透明性	伺服器看到代理 IP	客戶端看到代理 IP
目的	隱藏真實客戶端、加速存取	隱藏真實伺服器、負載平衡

2.2 反向代理的核心價值

價值一：負載平衡

將流量分發到多個後端伺服器，避免單點過載。

客戶端
  ↓
Nginx（反向代理）
  ↓
┌─────────┬─────────┬─────────┐
│ 伺服器1 │ 伺服器2 │ 伺服器3 │
└─────────┴─────────┴─────────┘

價值二：安全防護

隱藏真實伺服器 IP，防止直接攻擊。統一在代理層做安全防護。

客戶端 → 只能看到 Nginx 的 IP
真實伺服器 → 只在內網，外部無法直接存取

價值三：SSL 終結

在代理層處理 HTTPS 加密解密，後端服務用 HTTP，降低後端計算開銷。

HTTPS 客戶端 → Nginx（加密/解密） → HTTP 後端服務
                   ↑
              SSL 終結點

3. Nginx：為什麼能扛起百萬併發？

3.1 Master-Worker 行程模型

Nginx 採用多行程架構，而不是多執行緒：

Master 行程（管理者）：

負責讀取和驗證設定檔
管理 Worker 行程（啟動、停止、重新載入）
不處理具體請求

Worker 行程（工作者）：

實際處理 HTTP 請求
每個 Worker 是獨立的行程，相互隔離
數量通常設定為 CPU 核心數，避免上下文切換開銷

💡 優勢

隔離性好：一個 Worker 崩潰，不影響其他 Worker
充分利用多核：每個 Worker 獨立執行
避免多執行緒複雜性：無需處理鎖、競爭等問題

3.2 事件驅動 + 非同步非阻塞

這是 Nginx 高效能的核心秘密：

傳統 Apache（多行程/執行緒模型）：

一個連線 = 一個行程/執行緒
併發數受限於系統行程/執行緒數
大量連線時，行程切換開銷巨大

Nginx（事件驅動模型）：

使用 epoll（Linux）/ kqueue（macOS）等高效 I/O 多工機制
一個 Worker 行程可以同時處理數萬個連線
連線沒有資料時，不會佔用 CPU，有新資料時透過事件通知喚醒

生活化比喻

Apache：餐廳裡每個顧客配一個服務生（行程），顧客多需要大量服務生
Nginx：一個超級服務生，同時服務所有顧客，誰需要服務就去誰那裡，而不是一直站在某個顧客旁邊

Nginx 进程架构图

👑

Master 进程

管理所有 Worker，负责配置加载、平滑升级

4 个 Worker

⚙️

Worker 1

处理 0 请求

⚙️

Worker 2

处理 0 请求

⚙️

Worker 3

处理 0 请求

⚙️

Worker 4

处理 0 请求

📡 epoll (Linux) / kqueue (macOS)

事件驱动：一个 Worker 同时处理数万个连接

传统 Apache

一个连接 = 一个进程/线程

❌ C10K 问题

Nginx

事件驱动 + 异步非阻塞

✅ 百万并发

🎮 模拟请求处理

💡 生产环境建议

Worker 数量 = CPU 核心数（通常设置为 auto，让 Nginx 自动检测）
太多了上下文切换开销大，太少了无法利用多核性能。

4. 什麼是 API 閘道器？

4.1 為什麼需要 API 閘道器？

想像一個沒有閘道器的系統：

客戶端需要知道多個服務的位址（使用者服務、訂單服務、支付服務...）
每個服務都要自己做認證、限流、日誌
協定不統一，有的用 HTTP，有的用 gRPC
服務升級時，客戶端也需要跟著改

⚠️ 沒有閘道器的問題

客戶端複雜：需要組態多個服務位址
功能重複：每個服務都要實作認證、限流
協定混亂：客戶端要適配多種協定
升級困難：服務升級，客戶端也要改

有了 API 閘道器之後：

客戶端只需要知道閘道器位址，閘道器負責路由到正確服務
認證、限流、日誌等橫切邏輯統一在閘道器處理
閘道器可以做協定轉換，對外統一暴露 HTTP
後端服務升級，只需要改閘道器組態，客戶端無感知

客户端 (来访者)

📱 App

💻 Web

🔧 第三方

⬇️ 统一入口

🚪 API 网关 (前台)

🔐身份认证

⚡限流熔断

🧭路由转发

🔄协议转换

⬇️ 分发请求

⚙️ 后端服务 (各个部门)

👤

用户服务

/api/users

📦

订单服务

/api/orders

💳

支付服务

/api/pay

🔐身份认证

统一校验用户身份，无需每个后端服务都写登录逻辑。支持 JWT、OAuth2、API Key 等多种认证方式。

💡 实际场景

用户请求携带 JWT Token，网关校验签名和过期时间，通过后把用户ID添加到请求头转发给后端服务。

🤔 没有网关 vs 有网关的区别

功能需求	没有网关 (直接访问)	有 API 网关
身份认证	每个服务都要写一遍登录校验	✅ 统一在网关层校验 JWT
限流保护	每个服务自己实现限流	✅ 网关统一限流，保护后端
协议转换	HTTP、gRPC、WebSocket各自处理	✅ 网关统一对外暴露 HTTP
灰度发布	需要改负载均衡器配置	✅ 网关层按 Header 路由

4.2 API 閘道器的核心功能

功能	說明	典型場景
路由轉發	根據 URL、Header 等規則，將請求轉發到不同服務	`/api/users` → 使用者服務，`/api/orders` → 訂單服務
負載平衡	同一個服務有多執行個體時，分攤流量	使用者服務有 3 台執行個體，輪詢分發請求
認證鑑權	統一校驗 JWT、OAuth Token	未登入使用者無法存取 `/api/admin`
限流熔斷	控制流量上限，防止服務被壓垮	每秒最多 1000 請求，超過回傳 429
協定轉換	對外 HTTP，內部可轉 gRPC	客戶端用 HTTP，閘道器轉 gRPC 呼叫內部服務
灰度發布	按 Header 或比例，將部分流量導到新版本	5% 使用者體驗新版本，95% 用舊版本
日誌監控	統一記錄請求日誌，便於分析和排除故障	記錄每次請求的耗時、狀態碼、回傳大小

5. 閘道器實戰：如何構建完整的閘道器架構？

5.1 完整架構圖

┌───────────────────────────────────────────────────────────────────────┐
│                           客戶端（瀏覽器/APP）                               │
└───────────────────────────┬─────────────────────────────────────────┘
                                │ HTTPS
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        外層：CDN + WAF                                  │
│  ┌─────────────────────────────────────────────────────────────┐  │
│  │  CDN（內容分發網路）                                        │  │
│  │  - 靜態資源快取（圖片、CSS、JS）                           │  │
│  │  - 就近存取，降低延遲                                   │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  WAF（Web 應用防火牆）                                     │  │
│  │  - 防護 SQL 注入、XSS 攻擊                                │  │
│  │  - 攔截惡意 Bot、爬蟲                                  │  │
│  │  - CC 攻擊防護                              │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                     中層：API 閘道器（Nginx/Kong）                      │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第一層：SSL 終結 + 安全防護                              │  │
│  │  - HTTPS / TLS 1.3                                        │  │
│  │  - HSTS、安全回應頭                                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第二層：認證與鑑權                                      │  │
│  │  - JWT Token 校驗                                         │  │
│  │  - OAuth 2.0 / SSO 整合                                     │  │
│  │  - API Key 管理                                         │  │
│  │  - 權限校驗（RBAC）                                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第三層：流量控制                                        │  │
│  │  - 限流 - 令牌桶/漏桶演算法                             │  │
│  │  - 熔斷 - 防止故障擴散                                 │  │
│  │  - 降級 - 服務不可用時的備用方案                         │  │
│  │  - 灰度發布 - 按比例分配流量                          │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第四層：路由與負載平衡                                    │  │
│  │  - 路徑路由 - Path-based Routing）                          │  │
│  │  - 域名路由 - Host-based Routing）                           │  │
│  │  - Header 路由 - Header-based Routing）                             │  │
│  │  - 負載平衡演算法 - 輪詢/加權/最少連線/IP 雜湊）             │  │
│  │  - 服務發現 - Service Discovery）整合                        │  │
│  └───────────────────────────────────────────────────────────────┘  │
│  ┌───────────────────────────────────────────────────────────────┐  │
│  │  第五層：協定轉換與資料處理                                 │  │
│  │  - SSL 終結 - HTTPS ↔ HTTP）                                   │  │
│  │  - 協定轉換 - HTTP ↔ gRPC / WebSocket）                         │  │
│  │  - 請求/回應轉換 - JSON ↔ XML）                               │  │
│  │  - 資料壓縮 - Gzip / Brotli）                                   │  │
│  │  - 快取 - Cache）- 靜態資源和 API 回應                          │  │
│  └───────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌───────────────────────────────────────────────────────────────────────┐
│                        內層：微服務叢集                             │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐      │
│  │  使用者服務    │ │  訂單服務    │ │  商品服務    │ │  支付服務    │      │
│  │  User Svc   │ │  Order Svc  │ │ Product Svc │ │ Payment Svc │      │
│  │             │ │             │ │             │ │             │      │
│  └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘      │
│         │                │                │                │               │
│         └────────────────┴────────────────┴────────────────┘               │
│                                       │                              │
│                    服務發現與組態中心 / etcd）                          │
│                    - 服務註冊與發現                                      │
│                    - 健康檢查                                              │
│                    - KV 組態儲存                                              │
└───────────────────────────────────────────────────────────────────────┘

5.2 路由與負載平衡

閘道器的核心職責之一，就是把請求送到正確的地方。這涉及兩個關鍵能力：路由（去哪台伺服器）和負載平衡（怎麼分配流量）。

路由規則：從 URL 到服務

想像一個電商系統，不同的 URL 對應不同的服務：

/api/users/* → 使用者服務
/api/orders/* → 訂單服務
/api/products/* → 商品服務
/api/pay/* → 支付服務

Nginx 組態範例：

nginx

server {
    listen 80;
    server_name api.example.com;

    # 使用者服務
    location /api/users/ {
        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 訂單服務
    location /api/orders/ {
        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 商品服務
    location /api/products/ {
        proxy_pass http://product-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 支付服務（需要更高安全級別）
    location /api/pay/ {
        # 限制 IP 存取
        allow 10.0.0.0/8;
        deny all;

        proxy_pass http://payment-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

負載平衡：四種策略對比

當同一個服務有多個執行個體時，如何選擇？

策略	原理	適用場景	優點	缺點
輪詢	按順序依次分配給每台伺服器	伺服器效能相近	簡單公平	不考慮伺服器當前負載
加權輪詢	按權重比例分配，權重高的分配更多	伺服器效能不均	充分利用高效能伺服器	需要合理設定權重
最少連線	分配給當前連線數最少的伺服器	長連線場景、影片串流	動態適應負載變化	需要即時統計連線數
IP 雜湊	根據客戶端 IP 計算雜湊，同一 IP 永遠分配到同一台伺服器	需要工作階段保持	保證工作階段一致性	某個 IP 流量大時會造成單點壓力

Nginx 組態範例：

nginx

# 加權輪詢
upstream backend_weighted {
    server 10.0.1.10:8080 weight=3;  # 效能好，承擔更多流量
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;  # 效能差，承擔較少流量
}

# 最少連線
upstream backend_least_conn {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# IP 雜湊（工作階段保持）
upstream backend_ip_hash {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

选择负载均衡策略

🎮 负载均衡模拟器

💡

轮询 - 挨个分发，雨露均沾

按照服务器列表的顺序，依次将请求分配给每台服务器。就像银行叫号，1号窗口完事了到2号，2号完事了到3号，轮着来。

🏢 后端服务器集群

服务器数量:4 台

🖥️

Server-A

10%

请求数:0

权重:2

最近请求:

🖥️

Server-B

33%

请求数:0

权重:3

最近请求:

🖥️

Server-C

48%

请求数:0

权重:4

最近请求:

🖥️

Server-D

40%

请求数:0

权重:1

最近请求:

📨 请求队列

总请求: 0待处理: 0

📊 负载分布统计

33%

平均负载

48%

最高负载

14.2

负载标准差

Server-C

最忙服务器

6. 閘道器安全：如何守護系統大門？

6.1 認證與鑑權

傳統方式（每個服務各自認證）：

使用者服務、訂單服務、支付服務...每個都要校驗 JWT
程式碼重複，維護困難
secret 分散在各個服務，洩露風險高

閘道器統一認證：

客戶端攜帶 Token 存取閘道器
閘道器校驗 Token 合法性（簽章、過期時間）
校驗通過後，將使用者資訊（如 user_id）新增到請求頭，轉發給後端服務
後端服務無需校驗，直接從 Header 取得使用者資訊

💡 核心思想

認證在閘道器，鑑權在服務：

認證：你是誰？（校驗 Token，取得使用者身分）
鑑權：你能做什麼？（根據使用者角色判斷權限）

就像公司櫃檯：櫃檯認證你的身分（身分證），但具體權限由各部門判斷。

JWT (JSON Web Token) 认证流程

用户

输入用户名密码，点击登录

↓

网关/Nginx

转发登录请求到认证服务

↓

认证服务

验证密码，生成 JWT Token（包含 Header、Payload、Signature）

↓

用户/客户端

保存 Token（LocalStorage 或 Cookie）

↓

后续请求

在 HTTP Header 中携带: Authorization: Bearer <Token>

↓

网关/Nginx

校验 Token 签名和过期时间，通过后转发请求

↓

后端服务

从 Token 中解析用户信息，处理业务逻辑

🔑 JWT Token 结构（Base64编码）

PAYLOAD

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022 }

SIGNATURE

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)

🛠️ 三种方案实现对比

对比维度	Session + Cookie	JWT	OAuth2.0
存储位置	服务端存储 Session，客户端存 Cookie	客户端存储 Token，服务端无状态	授权服务器存储，客户端存 Access Token
扩展性	❌ 需要共享 Session，扩展复杂	✅ 无状态，易于水平扩展	✅ 分布式架构，支持大规模系统
安全性	⚠️ Cookie 可能被窃取，需要 CSRF 防护	⚠️ Token 泄露风险，需 HTTPS + 短期有效	✅ 行业最佳实践，支持多种安全机制
实现复杂度	🟢 简单，开箱即用	🟡 中等，需要 Token 管理	🔴 复杂，需要授权服务器
适用场景	传统 Web 应用、后台管理系统	SPA、移动端 API、微服务	第三方登录、开放平台、SSO

🔒 网关层认证最佳实践

统一在网关层验证

不要在每个微服务里重复写认证逻辑，统一在网关层校验 JWT 或 Session

HTTPS 强制

网关层强制 HTTPS，防止 Token 在传输过程中被窃取（中间人攻击）

Token 过期策略

Access Token 短期有效（15分钟），配合 Refresh Token 实现无感知续期

黑名单机制

用户登出或 Token 泄露时，将 Token 加入黑名单（Redis 存储）

6.2 HTTPS 與 SSL 終結

為什麼需要 HTTPS？

安全：防止資料在傳輸過程中被竊取
合規：現代瀏覽器對 HTTP 網站顯示「不安全」警告
SEO：搜尋引擎優先收錄 HTTPS 網站

SSL 終結方案：

只在閘道器層組態 HTTPS 和憑證
閘道器負責 TLS 握手和加解密
閘道器和後端服務之間使用 HTTP 明文傳輸（內部網路可信）
後端服務專注於業務邏輯，無需處理 TLS

💡 SSL 終結的優勢

簡化管理：憑證只在閘道器組態，後端無需組態
降低開銷：後端服務不需要處理 TLS 握手
統一更新：憑證更新只需在閘道器操作

🔐 HTTPS 流量解密流程

👤

客户端 (浏览器)

发起 HTTPS 请求

🔒TLS 加密连接

证书: *.example.com

算法: TLS 1.3

加密: AES-256-GCM

🚪

Nginx (SSL 终结)

📜 校验证书

🔓 解密流量

📝 添加 X-Forwarded-*

🔓HTTP 明文

X-Forwarded-For: 203.0.113.42

X-Forwarded-Proto: https

X-Real-IP: 203.0.113.42

⚙️

后端服务集群

专注于业务逻辑，无需处理 TLS

📜 SSL 证书管理

生成私钥

使用 OpenSSL 生成 RSA 私钥，这是证书的基础

openssl genrsa -out private.key 2048

创建 CSR

生成证书签名请求，包含域名和组织信息

openssl req -new -key private.key -out csr.pem

域名验证

CA 机构验证域名所有权（DNS 记录或 HTTP 文件）

# 添加 DNS TXT 记录或上传验证文件到 /.well-known/

签发证书

验证通过后，CA 签发证书文件

# 下载 certificate.crt 和 chain.crt

部署配置

将证书配置到 Nginx 并测试

nginx -t && systemctl reload nginx

✨ SSL 终结的核心优势

🚀

性能提升

TLS 握手和加密解密是 CPU 密集型操作，集中在 Nginx 处理，后端服务专注业务逻辑，整体吞吐量提升 2-5 倍

🔧

简化运维

证书统一管理，只需在 Nginx 配置一次，无需在每个后端服务重复配置，证书续期、更换一键完成

🛡️

集中安全

SSL/TLS 配置统一管控，强制使用最新协议版本和密码套件，统一添加安全响应头（HSTS、CSP 等）

📊

统一监控

所有 HTTPS 流量经过 Nginx，可以统一记录访问日志、分析 SSL 握手性能、监控证书有效期，便于审计和排障

7. 限流與熔斷：如何防止系統被「流量洪水」沖垮？

7.1 限流演算法對比

演算法	核心思想	突發流量	適用場景	實作複雜度
令牌桶	桶裡裝令牌，有令牌才能通過	允許一定程度的突發	API 限流、頻寬控制	中等
漏桶	請求進桶，勻速流出處理	強制平滑，突發會被快取或拒絕	需要嚴格勻速處理的場景	中等
滑動視窗	統計時間視窗內的請求數	嚴格按視窗計數，超出一律拒絕	精確統計（如「1 分鐘內最多 100 次」）	較高

7.2 Nginx 限流組態實戰

nginx

# 定義限流區域（放在 http 塊中）

# 1. 基於 IP 的限流（漏桶演算法）
# zone=mylimit:10m - 區域名稱和記憶體大小（10MB 約可儲存 16 萬 IP）
# rate=10r/s - 每秒允許 10 個請求
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

# 2. 基於 IP 的連線數限制（防止單個 IP 建立過多連線）
limit_conn_zone $binary_remote_addr zone=addr:10m;

# 3. 基於服務端點的限流（不區分 IP，保護後端整體）
limit_req_zone $server_name zone=server_limit:10m rate=100r/s;

server {
    listen 80;
    server_name api.example.com;

    # 使用者服務 - 普通限流
    location /api/users/ {
        # 應用限流
        # burst=20 - 桶容量，允許突發 20 個請求
        # nodelay - 不延遲處理突發請求（立即處理或拒絕）
        limit_req zone=mylimit burst=20 nodelay;

        # 限制單個 IP 的連線數
        limit_conn addr 10;

        proxy_pass http://user-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 訂單服務 - 更嚴格的限流
    location /api/orders/ {
        # 更嚴格的限流：每秒 5 個請求
        limit_req_zone $binary_remote_addr zone=order_limit:10m rate=5r/s;
        limit_req zone=order_limit burst=10 nodelay;

        proxy_pass http://order-service;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # 限流後的處理
    # 當請求被限流時，回傳 429 Too Many Requests
    error_page 429 /429.html;
    location = /429.html {
        internal;
        return 429 '{"error": "Too Many Requests", "message": "Rate limit exceeded. Please try again later."}';
        add_header Content-Type application/json;
    }
}

💡 限流策略建議

普通介面：每秒 10 個請求，允許突發 20 個
重要介面（支付、訂單）：每秒 5 個請求，允許突發 10 個
全域保護：所有請求總和不超過每秒 100 個

选择限流算法

🪙 令牌桶算法可视化

令牌桶

🪙

5 / 10 令牌

⏰ 令牌产生器 (2/秒)

🪙

📥 请求队列

📊 三种算法对比

维度	令牌桶 (Token Bucket)	漏桶 (Leaky Bucket)	滑动窗口 (Sliding Window)
核心思想	桶里装令牌，有令牌才能通过	请求进桶，匀速流出处理	统计时间窗口内的请求数
突发流量	✅ 允许一定程度的突发（桶里有令牌）	❌ 强制平滑，突发会被缓存或拒绝	❌ 严格按窗口计数，超出一律拒绝
适用场景	API 限流、带宽控制（允许突发）	需要严格匀速处理的场景（如消息队列）	精确统计（如"1分钟内最多100次"）
实现复杂度	中等	中等	较高（需要记录每个时间窗口的请求）
Nginx 配置	limit_req_zone (漏桶)	limit_req_zone (漏桶)	需第三方模块或 Lua

📝 Nginx 限流配置示例

# 定义限流区域
# $binary_remote_addr: 按 IP 限流
# zone=mylimit:10m: 区域名称和大小
# rate=10r/s: 每秒最多10个请求
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

server {
    listen 80;
    server_name api.example.com;

    location / {
        # 应用限流
        # burst=20: 桶容量，允许突发20个请求
        # nodelay: 不延迟处理突发请求
        limit_req zone=mylimit burst=20 nodelay;

        proxy_pass http://backend;
    }
}

💡 配置说明

limit_req_zone: 在 http 块中定义限流区域
$binary_remote_addr: 使用二进制 IP 地址作为限流键（省内存）
zone=mylimit:10m: 区域名称 mylimit，分配 10MB 内存
rate=10r/s: 每秒允许 10 个请求（漏桶算法）
burst=20: 桶的容量为 20，允许一定程度的突发流量
nodelay: 不延迟处理突发请求（立即处理或拒绝）

7.3 熔斷：防止故障擴散

熔斷器的工作原理：

關閉狀態：正常轉發請求，同時統計錯誤率
開啟狀態：當錯誤率超過閾值，熔斷器開啟，直接回傳錯誤，不再轉發請求
半開狀態：經過一段時間後，允許少量請求通過試探，如果成功則關閉熔斷器

💡 核心思想

熔斷就像電路保險絲：電流過大時，保險絲自動熔斷，保護整個電路不被燒毀。

類似地，當後端服務出現大量錯誤時，熔斷器「跳閘」，快速失敗，防止故障擴散到整個系統。

8. 總結：閘道器設計的核心思維

8.1 核心原則回顧

原則	含義	實務要點
路由	把請求送到正確的地方	路徑路由、域名路由、Header 路由
負載平衡	分攤流量到多台伺服器	輪詢、加權、最少連線、IP 雜湊
安全	守護系統大門	認證鑑權、HTTPS、WAF
限流	防止被流量沖垮	令牌桶、漏桶、滑動視窗
熔斷	防止故障擴散	快速失敗、降級方案
可觀測	監控和排除故障	日誌、指標、鏈路追蹤

8.2 技術選型建議

💡 選型決策樹

選擇閘道器：
│
├─ 只需要反向代理、負載平衡？
│  ├─ 是 → Nginx（首選）
│  └─ 否 → 繼續
│
├─ 需要豐富的外掛生態？
│  ├─ 是 → Kong（基於 Nginx）
│  └─ 否 → 繼續
│
├─ Spring Cloud 全家桶？
│  ├─ 是 → Spring Cloud Gateway
│  └─ 否 → Nginx

9. 名詞速查表

名詞	英文	解釋
反向代理	Reverse Proxy	部署在伺服器端，接收客戶端請求並轉發給內部服務的代理服務。客戶端只知道反向代理的存在，不知道真實伺服器位址。
正向代理	Forward Proxy	部署在客戶端側，代替客戶端存取外部資源的代理服務。伺服器端看到的是代理的 IP，不知道真實客戶端。典型應用：VPN、翻牆工具。
API 閘道器	API Gateway	位於客戶端和後端服務之間的中間層，提供路由、認證、限流、日誌等功能，是微服務架構的「統一大門」。
負載平衡	Load Balancing	將請求流量分配到多台伺服器，避免單台伺服器過載，提高系統可用性和效能。
SSL 終結	SSL Termination	在閘道器層處理 HTTPS 加密解密，後端服務使用 HTTP，降低後端計算開銷，簡化憑證管理。
限流	Rate Limiting	限制單位時間內的請求數量，防止系統被突發流量壓垮。常用演算法：令牌桶、漏桶、滑動視窗。
熔斷	Circuit Breaking	當依賴服務出現故障時，自動切斷呼叫，防止故障擴散，並提供降級方案。
工作階段保持	Session Persistence	確保同一客戶端的請求始終路由到同一台後端伺服器，用於需要保持工作階段狀態的場景。
健康檢查	Health Check	定期檢查後端服務的健康狀態，自動剔除故障節點，保證流量只發送到健康的服務執行個體。
灰度發布	Canary Release	將少量流量導到新版本，驗證穩定性後逐步擴大比例，降低發布風險。
WAF	Web Application Firewall	Web 應用防火牆，防護 SQL 注入、XSS、CC 攻擊等 Web 安全威脅。
CDN	Content Delivery Network	內容分發網路，在全球部署邊緣節點，加速靜態資源存取。

閘道器與反向代理 ​

1. 為什麼要「閘道器」？ ​

1.1 從一個真實案例說起：某電商的架構演進 ​

1.2 閘道器的生活化比喻 ​

2. 什麼是反向代理？ ​

2.1 正向代理 vs 反向代理 ​

2.2 反向代理的核心價值 ​

3. Nginx：為什麼能扛起百萬併發？ ​

3.1 Master-Worker 行程模型 ​

3.2 事件驅動 + 非同步非阻塞 ​

4. 什麼是 API 閘道器？ ​

4.1 為什麼需要 API 閘道器？ ​

4.2 API 閘道器的核心功能 ​

5. 閘道器實戰：如何構建完整的閘道器架構？ ​

5.1 完整架構圖 ​

5.2 路由與負載平衡 ​

6. 閘道器安全：如何守護系統大門？ ​

6.1 認證與鑑權 ​

6.2 HTTPS 與 SSL 終結 ​

7. 限流與熔斷：如何防止系統被「流量洪水」沖垮？ ​

7.1 限流演算法對比 ​

7.2 Nginx 限流組態實戰 ​

7.3 熔斷：防止故障擴散 ​

8. 總結：閘道器設計的核心思維 ​

8.1 核心原則回顧 ​

8.2 技術選型建議 ​

9. 名詞速查表 ​

閘道器與反向代理

1. 為什麼要「閘道器」？

1.1 從一個真實案例說起：某電商的架構演進

1.2 閘道器的生活化比喻

2. 什麼是反向代理？

2.1 正向代理 vs 反向代理

2.2 反向代理的核心價值

3. Nginx：為什麼能扛起百萬併發？

3.1 Master-Worker 行程模型

3.2 事件驅動 + 非同步非阻塞

4. 什麼是 API 閘道器？

4.1 為什麼需要 API 閘道器？

4.2 API 閘道器的核心功能

5. 閘道器實戰：如何構建完整的閘道器架構？

5.1 完整架構圖

5.2 路由與負載平衡

6. 閘道器安全：如何守護系統大門？

6.1 認證與鑑權

6.2 HTTPS 與 SSL 終結

7. 限流與熔斷：如何防止系統被「流量洪水」沖垮？

7.1 限流演算法對比

7.2 Nginx 限流組態實戰

7.3 熔斷：防止故障擴散

8. 總結：閘道器設計的核心思維

8.1 核心原則回顧

8.2 技術選型建議

9. 名詞速查表