共用方式為


具有工作區的同盟 APIM

適用於:進階版

本文提供 API 管理 工作區的概觀,以及其如何讓分散式 API 開發小組在一般服務基礎結構中管理和產品化其 API。

為什麼組織應該同盟 API 管理?

現今,組織在管理 API 激增方面越來越面臨挑戰。 隨著 API 和 API 開發小組的數目成長,管理 API 的複雜度也是如此。 這種複雜性可能會導致作業額外負荷增加、安全性風險,以及降低靈活度。 一方面,組織想要建立集中式 API 基礎結構,以確保 API 治理、安全性和合規性。 另一方面,他們希望其 API 小組能夠創新並快速響應商務需求,而不需要管理 API 平台的額外負荷。

API 管理的同盟模型可解決這些需求。 同盟 API 管理可讓開發小組以適當的控制和數據平面隔離進行分散式 API 管理,同時維護由 API 平臺小組管理的集中式治理、監視和 API 探索。 此模型克服了替代方法的限制,例如平臺小組的完全集中式 API 管理,或每個開發小組的孤立 API 管理。

同盟 API 管理提供:

  • 集中式 API 治理和可檢視性
  • 統一開發人員入口網站,適用於有效的 API 探索和上線
  • 在 API 小組之間隔離系統管理許可權,以提高生產力和安全性
  • 在 API 小組之間隔離 API 運行時間,改善可靠性、復原和安全性

工作區如何啟用同盟 API 管理

在 Azure API 管理 中,使用工作區來實作同盟 API 管理。 工作區在 APIM 服務內的功能如同「資料夾」:

  • 每個工作區都包含 API、產品、訂用帳戶、具名值和相關資源。 如需工作區中支援的資源和作業完整清單,請參閱 APIM REST API 參照
  • Teams 對工作區內資源的存取權是透過 Azure 的角色型訪問控制 (RBAC) 來管理,內建或自定義角色可指派給 Microsoft Entra 帳戶,並限定於工作區。
  • 每個工作區都會與一或多個 工作區網關 相關聯,以便將 API 流量路由傳送至工作區中的 API 後端服務。
  • 平臺小組可以在工作區中套用跨越 API 的 API 原則,並使用開發人員入口網站實作集中式 API 探索體驗。
  • 每個工作區小組都可以收集並分析網關資源記錄,以監視自己的工作區 API,而平臺小組可同盟存取 API 管理服務中所有工作區的記錄,提供其 API 生態系統的監督、安全性和合規性。

APIM 服務與工作區的概念性圖表。

注意

  • API 管理 REST API 版本 2023-09-01-preview 或更新版本中支援最新的工作區功能。
  • 如需定價考量,請參閱 API 管理定價

雖然工作區與 APIM 服務和其他工作區獨立管理,但依據設計可以參考選取的服務層級資源。 請參閱後文的工作區和其他 APIM 功能

範例案例總覽

使用 Azure API 管理管理 API 的組織可能會有多個開發小組開發、定義、維護及產品化不同的 API 集合。 工作區可讓這些小組分別使用 APIM 來管理、存取及保護其 API,並且獨立於管理服務基礎結構。

以下是用來建立和使用工作區的範例工作流程。

  1. 管理 API 管理執行個體的中央 API 平台小組會建立工作區,並使用 RBAC 角色將權限指派給工作區共同作業者,例如,在工作區中建立或讀取資源的權限。 工作區範圍的 API 閘道也會針對工作區建立。

  2. 中央 API 平台小組會使用 DevOps 工具來為該工作區中的 API 建立 DevOps 管線。

  3. 工作區成員會在工作區中開發、發佈、產品化及維護 API。

  4. 中央 API 平台小組會管理服務的基礎結構,例如監視、復原以及強制執行所有 API 原則。

工作區閘道

每個工作區都會設定一或多個 工作區閘道 ,以啟用工作區內受控 API 的運行時間。 工作區閘道是獨立的 Azure 資源(工作區閘道進階版),其核心功能與 API 管理服務中內建的閘道相同。

工作區閘道與 APIM 服務和其他閘道獨立管理。 它們允許隔離工作區或使用案例之間的運行時間、增加 API 可靠性、復原和安全性,以及啟用工作區運行時間問題的屬性。

將工作區與工作區閘道連結起來

視組織的需求而定,您可以將一個工作區或多個工作區與工作區網關建立關聯。

注意

將多個工作區與工作區網關建立關聯僅適用於 2025 年 4 月 15 日之後建立的工作區閘道。

  • 工作區閘道具有特定設定(例如虛擬網路、規模、主機名)和配置運算資源(CPU、記憶體、網路資源)。
  • 所有部署在閘道上的工作區都會共用設定和計算資源。
  • API 或異常流量中的 Bug 可能會導致這些資源耗盡,而影響該閘道上的所有工作區。 換句話說,在閘道上部署的工作區越多,來自工作區的 API 將遇到來自另一個工作區之 API 所造成的可靠性問題的風險就越高。
  • 使用內建的度量工具來監視閘道的效能,檢查 CPU 和記憶體的使用率。

選擇工作區的部署模型時,請考慮可靠性、安全性和成本。

  • 針對任務關鍵性工作負載使用專用閘道 - 若要將 API 可靠性和安全性最大化,請將每個任務關鍵性工作區指派給自己的網關,避免與其他工作區共用。
  • 平衡可靠性、安全性和成本 - 讓多個工作區與閘道產生關聯,以平衡非關鍵工作負載的可靠性、安全性和成本。 將工作區分散到至少兩個網關可以幫助防止某些問題,例如資源耗盡或配置錯誤,以免影響組織內的所有 API。
  • 針對不同的使用案例使用不同的閘道 - 根據使用案例或網路需求,將閘道上的工作區分組。 例如,您可以將它們指派給個別閘道,每個閘道都有自己的網路組態,以區分內部和外部 API。
  • 準備隔離有問題的工作區 - 在共用工作區閘道前使用 Proxy,例如 Azure 應用程式閘道或 Azure Front Door,以簡化將造成資源耗盡的工作區移至不同的閘道,以防止對共用閘道的其他工作區造成影響。

注意

  • 工作區閘道必須位於與 API 管理實例的主要 Azure 區域和相同訂用帳戶中的相同區域中
  • 與工作區閘道相關聯的所有工作區都必須位於相同的 API 管理實例中
  • 工作區閘道最多可與 30 個工作區相關聯(請連絡支援人員以增加此限制)

閘道主機名稱

每個工作區閘道都會為相關聯工作區中管理的 API 提供唯一的主機名。 預設主機名稱會遵循模式 <gateway-name>-<hash>.gateway.<region>.azure-api.net。 使用網關主機名稱,將 API 請求路由至工作區中的 API。

目前,工作區閘道不支援自訂主機名稱。 您可以使用工作區閘道前的自訂主機名來設定 Azure 應用程式閘道或 Azure Front Door。

網路隔離

工作區閘道可以選擇性地設定在私人虛擬網路中,以隔離輸入和/或輸出流量。 如果已設定,工作區閘道必須在虛擬網路中使用專用子網路。

如需詳細需求,請參閱工作區閘道的網路資源需求

注意

  • 工作區閘道的網路設定與 APIM 執行個體的網路設定無關。
  • 目前,只有在建立閘道時,才能在虛擬網路中設定工作區閘道。 您稍後無法變更閘道的網路設定或其他設定。

縮放容量

透過新增或移除擴展單位來管理閘道容量,這類似於某些服務層級中可新增至 API 管理實例的 單位 。 工作區閘道的成本取決於您選取的單位數目。

區域可用性

如需目前可用的工作區閘道區域清單,請參閱 v2 層和工作區閘道的可用性。

閘道條件約束

下列條件約束目前適用於工作區閘道:

  • 工作區無法與自我裝載閘道相關聯
  • 工作區閘道不支援輸入私人端點
  • 工作區閘道中的 API 無法指派自訂主機名稱
  • 適用於 API 的 Defender 未涵蓋工作區中的 API
  • 工作區閘道不支援 APIM 服務的認證管理員
  • 工作區閘道僅支援內部快取;不支援外部快取
  • 工作區閘道不支援合成的 GraphQL API
  • 工作區閘道不支援直接從 Azure 資源建立 API,例如 Azure OpenAI Service、App Service、Function Apps 等等
  • 要求計量無法依 Azure 監視器中的工作區分割;所有工作區計量都會在服務層級匯總
  • 工作區閘道不支援 CA 憑證
  • 工作區閘道不支援受控識別,包括在 Azure Key Vault 中儲存祕密和使用 authentication-managed-identity 原則等相關功能
  • 工作區閘道只能在 API 管理實例的主要 Azure 區域中建立

工作區的 RBAC 角色

Azure RBAC 可用來設定工作區共同作業者的權限,以讀取和編輯工作區中的實體。 如需角色清單,請參閱如何在 API 管理中使用角色型存取控制

若要管理工作區中的 API 和其他資源,工作區成員必須在 APIM 服務、工作區和工作區閘道的限定範圍中獲得角色指派 (或使用自訂角色的同等權限)。 服務範圍角色允許從工作區層級資源參考特定的服務層級資源。 例如,將使用者組織為工作區層級群組,以控制 API 和產品可見度。

注意

為了更容易管理,請設定 Microsoft Entra 群組,將工作區權限指派給多個使用者。

工作區和其他 API 管理功能

工作區設計成獨立式,以最大化系統管理存取和 API 執行階段的隔離。 有數個例外狀況可確保更高的生產力,並啟用全平台治理、可檢視性、再使用性和 API 探索。

  • 資源參考 - 工作區中的資源可以參考工作區中的其他資源,以及服務層級的選取資源,例如使用者、授權伺服器或內建使用者群組。 它們無法參考其他工作區的資源。

    基於安全性考量,您無法從工作區層級原則 (例如具名值) 或資源名稱 (例如 backend-id 原則中的) 參考服務層級資源。

    重要

    API 管理 服務中的所有資源(例如 API、產品、標籤或訂用帳戶)都必須有唯一的名稱,即使它們位於不同的工作區中也一樣。 在相同工作區、其他工作區或服務等級中,不能有相同類型且具有相同 Azure 資源名稱的任何資源。

  • 開發人員入口網站 - 工作區是系統管理概念,因此不會向開發人員入口網站取用者展示,包括透過開發人員入口網站 UI 和底層 API。 工作區內的 API 和產品可以發佈至開發人員入口網站,如同服務層級上的 API 和產品。

    注意

    APIM 支援將服務層級上定義的授權伺服器指派給工作區內的 API。

從預覽工作區移轉

如果您在 Azure APIM 中建立預覽工作區,並想要繼續使用這些工作區,請藉由將工作區閘道與每個工作區建立關聯,以移轉工作區至正式推出版本。

如需詳細資訊並了解可能會影響預覽工作區的其他變更,請參閱工作區中斷性變更 (2025 年 3 月)

刪除工作區

如果您使用 Azure 入口網站介面刪除工作區,則刪除工作區會刪除其所有子資源 (API、產品等) 及其相關聯閘道。 但不會刪除 APIM 執行個體或其他工作區。