微服務越多，前端越混亂。user service 在 port 8001、order service 在 8002、payment 在 8003——前端要記住每個服務的位址？出了新服務要改前端 config？這不是微服務的好處，這是微服務的代價。API Gateway 就是用來消除這個代價的。
先講結論
API Gateway 做四件事：統一路由（前端只認一個入口）、統一認證（JWT / API Key 在 gateway 驗完）、統一限流（不讓某個 client 打爆你的後端）、統一觀測（每條路由的 QPS、延遲、錯誤率）。不是「更複雜」，是「更可控」。
路由：一個入口對多個服務
前端只需要知道 api.example.com，Gateway 負責把 /users 送到 user-service、/orders 送到 order-service。服務怎麼拆、在哪台機器上，前端完全不用知道。
認證：統一驗，後端不用管
JWT 驗證放在 gateway，後端只需要讀 header 裡的 user info。不要每個服務各自寫一套認證 middleware——你有 10 個服務，就有 10 個地方可能寫錯。
Kong 範例：DB-less 模式
services:
kong:
image: kong:3.6
environment:
KONG_DATABASE: "off"
KONG_DECLARATIVE_CONFIG: /kong/kong.yml
ports:
- "8000:8000"
- "8443:8443"
volumes:
- ./kong.yml:/kong/kong.yml# kong.yml
_format_version: "3.0"
services:
- name: user-service
url: http://user-service:8000
routes:
- name: user-route
paths:
- /users
plugins:
- name: key-auth
- name: rate-limiting
config:
minute: 100
policy: local不想用 Kong？Nginx 也能當輕量 gateway：
server {
listen 443 ssl;
server_name api.example.com;
location /users/ {
proxy_pass http://user-service:8000/;
}
location /orders/ {
proxy_pass http://order-service:8000/;
}
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location / {
limit_req zone=api burst=20 nodelay;
}
}差別在於 Kong 有 plugin 生態（認證、限流、logging 都是 plugin），Nginx 要自己寫 config。小團隊用 Nginx 就夠了，服務多了再考慮 Kong。
版本管理：讓舊版活著
/v1/users 和 /v2/users 可以同時存在。新版上了但舊 client 還在用 v1？沒關係，gateway 把它們路由到不同的服務或不同的版本。
但版本不能無限累積。要有 sunset policy：公告 → 6 個月過渡期 → 下線。不然你會發現自己在維護 5 個版本的 API，每次改一個 bug 要改 5 次。
Gateway 的風險：它是單點
Gateway 掛了 = 所有 API 掛了。所以你需要 HA（至少兩台）或者至少有快速恢復的能力。
Gateway 也是最重要的觀測點：每條路由的 QPS、P95 latency、4xx/5xx 比例。把這些指標放在 Grafana 上，你就能在用戶回報之前知道哪條 API 出了問題。
API Gateway 就像機場的航廈。旅客不需要知道飛機停在哪個停機坪，只需要看登機門號碼。你的 gateway 就是那個登機門。