---
title: "API閘道（API Gateway）"
slug: api-gateway
language: zh-TW
source: https://aiterms.tw/terms/api-gateway
updated_at: 2026-04-29
tags: [AI基礎, 資訊安全]
ipas_term: false
---

# API閘道（API Gateway）

> **一個 App 背後有登入、付款、推薦三個服務，使用者進來時該先找誰？**
> 你可以把 API 閘道想成單一入口，它負責把請求分到對的後端服務。
> 它的價值在入口統一管理，驗證、限流、路由、紀錄都可以在同一層處理。
>
> 你可以把它想成一個把抽象概念拉回日常判斷的提示，先知道它解決什麼問題，再看技術細節。

### 容易混淆

> **API 閘道 vs 反向代理？**
> API 閘道：管理對外請求的入口層
> 反向代理：主要負責轉送與隱藏後端位置
> 最關鍵的區別：API 閘道比反向代理多了授權、轉換與限流等 API 管理能力
>
> **API 閘道 vs 負載平衡？**
> API 閘道：控制誰能進來、進來後去哪裡
> 負載平衡：把流量平均分給多台伺服器
> 最關鍵的區別：閘道看的是 API 管理，負載平衡看的是流量分配
>
> **API 閘道 vs 服務網格？**
> API 閘道：站在服務前面統一守門
> 服務網格：站在服務之間管理內部通訊
> 最關鍵的區別：閘道管外部入口，服務網格管內部東西向流量
### 記住這句就好

> 入口統一管，後端就不用各自亂守門
### 實際案例

> **電商 App**
> 登入、查庫存、結帳三個請求進來後，閘道先做驗證與限流，再把請求送到對應服務
>
> **合作夥伴串接**
> 外部夥伴只需要連到一個 API 入口，版本控管與權限也集中在閘道處理
### 算法與應用

> | 重點 | 你要看什麼 | 為什麼重要 |
> |---|---|---|
> | 路由 | 依 URL、版本、租戶分流 | 避免每個服務都自己處理入口邏輯 |
> | 安全 | 驗證、授權、金鑰管理 | 先在入口擋掉不合格請求 |
> | 保護 | 限流、配額、熔斷 | 避免下游服務被流量打垮 |
### 情境判斷

> **Q1：某服務突然被大量重試打爆，應該先看哪一層？**
> → 先看 API 閘道的限流與熔斷設定，因為入口層最容易集中控制
>
> **Q2：如果公司只有一個小服務，而且沒有多版本管理需求，還需要 API 閘道嗎？**
> → 不一定需要，規模很小時可以先用較簡單的反向代理；等到服務變多再補閘道
### 常見問題

> **Q：API 閘道和反向代理可以同時存在嗎？**
> 可以。很多系統會讓反向代理做基礎轉送，再由 API 閘道處理認證、版本與業務規則。
>
> **Q：閘道是不是一定要放在雲端？**
> 不一定。它可以是雲端服務，也可以是自建元件，重點是把入口管理集中起來。
>
> **Q：閘道會不會成為瓶頸？**
> 會，所以通常要搭配水平擴充、健康檢查與監控，避免它自己變成單點故障。
### 相關術語

> - **AI負載平衡**：閘道常和流量分配一起設計
> - **自動擴展**：流量變大時，後端資源要能跟著增加
> - **模型服務化**：AI 服務上線後常透過閘道對外提供 API

---

來源：https://aiterms.tw/terms/api-gateway
快查頁：https://aiterms.tw/terms/api-gateway
最後更新：2026/04/29
深度解說：https://aiterms.tw/learning/what-is-api-gateway