什麼是 Azure API 管理?
適用於:所有 APIM 層
本文提供 Azure API 管理常見案例和重要元件的概觀。 Azure API 管理是跨所有環境適用於 API 的混合式多重雲端管理平台。 作為一種平台即服務,API 管理支援完整的 API 生命週期。
案例
API 可啟用數位體驗、簡化應用程式整合、支援新的數位產品,以及讓資料和服務可重複使用且可通用存取。 隨著 API 的激增和相依性的增加,組織必須在整個生命週期中將其作為第一級資產加以管理。
Azure API 管理可協助客戶滿足這些挑戰:
- 從 API 取用者提取後端架構多樣性和複雜度
- 安全地將裝載在 Azure 外部的服務公開為 API
- 保護、加速及觀察 API
- 啟用內部和外部使用者的 API 探索和使用
常見情況包括:
- 解除鎖定舊版資產 - API 可用來提取和現代化舊版後端,並使其可從新的雲端服務和新式應用程式進行存取。 API 允許創新,而沒有風險、成本和移轉延遲。
- 以 API 為中心的應用程式整合 - API 很容易使用、以標準為基礎,且自我描述機制可用來公開和存取資料、應用程式和流程。 這些可簡化並降低應用程式整合的成本。
- 多通道使用者體驗 - API 經常用來啟用使用者體驗,例如 Web、行動裝置、穿戴式或物聯網應用程式。 重複使用 API 來加速開發和 ROI。
- B2B 整合 - 向合作夥伴和客戶公開的 API 會降低整合商務流程並在商務實體之間交換資料的障礙。 API 可消除點對點整合固有的額外負荷。 特別是啟用自助式探索和上線功能時,API 是調整 B2B 整合的主要工具。
API 管理元件
Azure API 管理是由「API 閘道」、「管理平面」和「開發人員入口網站」所組成。 這些元件預設為 Azure 裝載且完全受控。 API 管理可用於容量和功能不同的各個階層。
API 閘道
來自用戶端應用程式的所有要求都會先到達 API 閘道,然後再將它們轉送至個別的後端服務。 API 閘道可作為後端服務的介面,讓 API 提供者能夠提取 API 實作,並演進後端架構,而不會影響 API 取用者。 閘道可讓您一致設定路由、安全性、節流、快取和可檢視性。
具體而言,閘道可以:
- 透過接受 API 呼叫並將其路由至適當的後端,作為後端服務的介面
- 驗證 API 金鑰和其他認證,例如透過要求呈現的 JWT 權杖和憑證
- 強制執行使用量配額和速率限制
- 選擇轉換原則陳述式中指定的要求和回應
- 如果已設定,則快取回應以改善回應延遲,並將後端服務上的負載降到最低
- 發出監視、報告和疑難排解的記錄、計量和追蹤
自我裝載閘道
透過自我裝載閘道,客戶可以將 API 閘道部署到裝載其 API 的相同環境,以最佳化 API 流量,並確保符合本地法規和指導方針。 自我裝載閘道可讓使用混合式 IT 基礎結構的客戶,透過 Azure 中的單一 API 管理服務,管理裝載於內部部署與跨雲端裝載的 API。
自我裝載閘道會封裝為以 Linux 為基礎的 Docker 容器,通常會部署到 Kubernetes,包括 Azure Kubernetes Service,以及已啟用 Azure Arc 的 Kubernetes。
其他資訊:
管理平面
API 提供者會透過管理平面與服務互動,以提供 API 管理服務功能的完整存取權。
客戶透過 Azure 工具與管理平面互動,包括 Azure 入口網站、Azure PowerShell、Azure CLI、Visual Studio Code 延伸模組、REST API,或數種熱門程式設計語言的用戶端 SDK。
使用管理平面可以:
- 佈建及設定 API 管理服務設定
- 從各種來源定義或匯入 API 架構,包括 OpenAPI、WSDL 和開放式資料通訊協定、Azure 計算服務和 WebSocket、 GraphQL 後端和 gRPC 後端
- 將 API 封裝至產品
- 設定原則,例如 API 的配額或轉換
- 從分析取得見解
- 管理使用者
開發人員入口網站
開放原始碼開發人員入口網站是自動產生、可完全自訂的網站,其中包含您的 API 文件。
透過新增入自訂內容、自訂樣式和加入自己的品牌,API 提供者即可自訂開發人員入口網站的介面及操作。 透過自我裝載,進一步擴充開發人員入口網站。
應用程式開發人員會使用開放原始碼開發人員入口網站來探索 API、上線以使用 API,以及了解如何在應用程式中取用這些。 (API 也可以匯出至 Power Platform 以供公民開發者探索和使用。)
使用開發人員入口網站,開發人員可以:
- 閱讀 API 文件
- 透過互動式主控台呼叫 API
- 建立帳戶並訂閱以取得 API 金鑰
- 存取其自身使用量分析資料
- 下載 API 定義
- 管理 API 金鑰
APIM 層級
API 管理 提供各種定價層,以滿足不同客戶的需求。 每一層提供不同案例的功能、效能、容量限制、延展性、SLA 和定價的不同組合。 階層會依下列方式分組:
- 傳統 - 原始 API 管理 供應專案,包括開發人員、基本、標準和進階層。 進階層是專為需要存取私人後端、增強安全性功能、多區域部署、可用性區域,以及高延展性的企業所設計。 開發人員層是非生產環境使用的經濟選項,而基本、標準和進階層則是生產就緒層。
- V2 - 提供快速布建和調整的新層集,包括用於開發和測試的基本 v2,以及生產工作負載的標準 v2。 標準 v2 支援對網路隔離後端的簡化連線。
- 取 用 - 取用層是無伺服器閘道,可用來管理根據需求調整的 API,並按每個執行計費。 它專為具有無伺服器計算的應用程式、微服務架構,以及具有可變流量模式的應用程式所設計。
更多資訊
Azure 服務整合
API 管理與許多互補的 Azure 服務整合以建立企業解決方案,其中包括:
- Azure API 中心 可針對 API 探索、重複使用和治理,在組織中建置完整的 API 清查,不論其類型、生命週期階段或部署位置為何
- Azure 中的 Copilot 可協助撰寫 API 管理 原則或說明已設定的原則
- Azure Key Vault,用於安全保護和管理用戶端憑證和祕密
- 適用於管理作業、系統事件和 API 要求的記錄、報告和警示的 Azure 監視器
- 即時計量、端對端追蹤和疑難排解的 Application Insights
- 用於網路層級保護的虛擬網路、私人端點、應用程式閘道 和 Azure Front Door
- 適用於 API 的 Azure Defender和執行階段的Azure DDoS 保護,以防範惡意攻擊
- Microsoft開發人員驗證和要求授權的 Entra 識別碼
- 用於串流事件的事件中樞
- 數個通常用來在 Azure 上建置和裝載 API 的 Azure 計算供應專案,包括 Functions、Logic Apps、Web Apps、Service Fabric,以及其他包括 Azure OpenAI 服務在內的其他服務。
更多資訊
重要概念
API
API 是 API 管理服務執行個體的基礎。 每個 API 都代表可供應用程式開發人員使用的一組「作業」。 每個 API 都包含會實作 API 之後端服務的參考,而其作業會與後端作業相對應。
API 管理中的作業可設定度相當高,並可控制 URL 對應、查詢和路徑參數、要求和回應內容,以及作業回應快取。
更多資訊
Products
產品是將 API 呈現給開發人員的方式。 API 管理中的產品有一或多個 API,而且可為「開放的」或「受保護」。 受保護的產品需要訂閱金鑰,而開放產品則可以免費取用。
當產品可供開發人員使用時,即可將產品發佈。 發佈後,開發人員可以使用開發人員入口網站檢視或訂閱產品。 訂閱核准是在產品層級設定,可能需要管理員核准,或是可自動核准。
更多資訊
群組
群組可用來管理開發人員對產品的可見度。 API 管理具有下列內建群組:
系統管理員 - 管理 API 管理服務執行個體,並建立開發人員所使用的 API、作業和產品。
Azure 訂閱管理員是此群組的成員。
開發人員 - 使用 API 建置應用程式的已驗證開發人員入口網站使用者。 開發人員獲授與開發人員入口網站的存取權,並建置呼叫 API 作業的應用程式。
來賓 - 未經驗證的開發人員入口網站使用者,例如,造訪開發人員入口網站的潛在客戶。 他們可獲得特定唯讀存取權限,例如他們可檢視 API 但無法進行呼叫。
管理員也可以建立自訂群組,或使用相關聯的 Microsoft Entra 租用戶中的外部群組,讓開發人員能夠看見並存取 API 產品。 例如,為合作夥伴組織中的開發人員建立自訂群組,以存取產品中的特定 API 子集。 使用者可隸屬於多個群組。
更多資訊
開發人員
開發人員代表 API 管理服務執行個體中的使用者帳戶。 開發人員可由管理員建立或邀請加入,也可以透過開發人員入口網站註冊。 每個開發人員都是一或多個群組的成員,並可訂閱這些群組有權查看的產品。
開發人員訂閱產品時,將可獲得呼叫產品的 API 時使用的產品主要和次要金鑰。
更多資訊
工作區
工作區可讓分散式 API 開發小組管理及產品化自己的 API,而集中式 API 平台小組則維護 API 管理基礎結構。 每個工作區都包含僅供工作區共同作業者存取的 API、產品、訂用帳戶和相關實體。 存取權是透過 Azure 角色型存取控制來控制 (RBAC) 來控制。
更多資訊
原則
使用原則,API 發行者可以透過設定來變更 API 的行為。 原則是陳述式的集合,會因 API 的要求或回應循序執行。 常見的陳述式包括從 XML 至 JSON 的格式轉換,以及利用呼叫速率限制來限制開發人員傳入的呼叫數量。 如需完整清單,請參閱 API 管理原則。
如果原則不另行指定,則可以在任何 APIM 原則中,使用原則運算式做為屬性值或文字值。 某些原則是以原則運算式為基礎,例如控制流程和設定變數原則。
視您的需求而定,原則可以套用到不同的範圍:全域 (全部 API)、工作區、產品、特定 API 或 API 作業。
更多資訊
下一步
完成下列快速入門,並開始使用 Azure API 管理:
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應