Dela via

Vad är arbetsytor i Azure API Management?

  • Artikel

GÄLLER FÖR: Premium

I API Management ger arbetsytor en ny nivå av autonomi till en organisations API-team, vilket gör det möjligt för dem att skapa, hantera och publicera API:er snabbare, mer tillförlitligt, säkert och produktivt i en API Management-tjänst. Genom att tillhandahålla isolerad administrativ åtkomst och API-körning kan arbetsytor ge API-team samtidigt som API-plattformsteamet kan behålla tillsynen. Detta omfattar central övervakning, tillämpning av API-principer och efterlevnad samt publicering av API:er för identifiering via en enhetlig utvecklarportal.

Arbetsytor fungerar som "mappar" i en API Management-tjänst:

  • Varje arbetsyta innehåller API:er, produkter, prenumerationer, namngivna värden och relaterade resurser.
  • Åtkomst till resurser på en arbetsyta hanteras via Azures rollbaserade åtkomstkontroll (RBAC) med inbyggda eller anpassade roller som kan tilldelas Till Microsoft Entra-konton.
  • Varje arbetsyta är associerad med en arbetsytegateway för att dirigera API-trafik till serverdelstjänsterna för API:er på arbetsytan.

Konceptdiagram över API Management-tjänsten med arbetsytor.

Kommentar

  • De senaste funktionerna för arbetsytor stöds i API Management REST API version 2023-09-01-preview eller senare.
  • Prisöverväganden finns i PRISSÄTTNING FÖR API Management.

Federerad API-hantering med arbetsytor

Arbetsytor lägger till förstklassigt stöd för en federerad modell för hantering av API:er i API Management, förutom centraliserade modeller som redan stöds. Se följande tabell för en jämförelse av dessa modeller.

Modell beskrivning
Centraliserad

Diagram över den centraliserade modellen för Azure API Management. 		Fördelar
• Centraliserad API-styrning och observerbarhet
• Enhetlig utvecklarportal för effektiv API-identifiering och registrering
• Infrastrukturens kostnadseffektivitet

Nackdelar
• Ingen uppdelning av administrativa behörigheter mellan team
• API-gatewayen är en felpunkt
• Oförmåga att tillskriva körningsproblem till specifika team
• Börda för plattformsteamet för att underlätta samarbete kan minska API-tillväxten
Siloed

Diagram över den siloade modellen för Azure API Management. 		Fördelar
• Uppdelning av administrativa behörigheter mellan team ökar produktiviteten och säkerheten
• Uppdelning av API-körning mellan team ökar API:s tillförlitlighet, återhämtning och säkerhet
• Körningsproblem är inneslutna och kan tillskrivas specifika team

Nackdelar
• Brist på centraliserad API-styrning och observerbarhet
• Brist på enhetlig utvecklarportal
• Ökade kostnader och hårdare plattformshantering
Federerad

Diagram över den federerade modellen för Azure API Management. 		Fördelar
• Centraliserad API-styrning och observerbarhet
• Enhetlig utvecklarportal för effektiv API-identifiering och registrering
• Uppdelning av administrativa behörigheter mellan team ökar produktiviteten och säkerheten
• Uppdelning av API-körning mellan team ökar API:s tillförlitlighet, återhämtning och säkerhet
• Körningsproblem är inneslutna och kan tillskrivas specifika team

Nackdelar
• Plattformskostnader och hanteringssvårigheter större än i den centraliserade modellen men lägre än i den siloade modellen

Exempelscenarioöversikt

En organisation som hanterar API:er med Hjälp av Azure API Management kan ha flera utvecklingsteam som utvecklar, definierar, underhåller och produktiserar olika uppsättningar API:er. Med arbetsytor kan dessa team använda API Management för att hantera, komma åt och skydda sina API:er separat och oberoende av att hantera tjänstinfrastrukturen.

Följande är ett exempelarbetsflöde för att skapa och använda en arbetsyta.

  1. Ett centralt API-plattformsteam som hanterar API Management-instansen skapar en arbetsyta och tilldelar behörigheter till arbetsytemedarbetare med hjälp av RBAC-roller – till exempel behörighet att skapa eller läsa resurser på arbetsytan. En dedikerad API-gateway skapas också för arbetsytan.

  2. Ett centralt API-plattformsteam använder DevOps-verktyg för att skapa en DevOps-pipeline för API:er på den arbetsytan.

  3. Medlemmar i arbetsytan utvecklar, publicerar, produktiserar och underhåller API:er på arbetsytan.

  4. Det centrala API-plattformsteamet hanterar tjänstens infrastruktur, till exempel övervakning, återhämtning och tillämpning av principer för alla API:er.

API-hantering på en arbetsyta

Teams hanterar sina egna API:er, produkter, prenumerationer, serverdelar, principer, loggare och andra resurser på arbetsytor. Se API Management REST API-referensen för en fullständig lista över resurser och åtgärder som stöds i arbetsytor.

Arbetsytor hanteras oberoende av API Management-tjänsten och andra arbetsytor, men de kan avsiktligt referera till valda resurser på tjänstnivå. Se Arbetsytor och andra API Management-funktioner senare i den här artikeln.

Arbetsytegateway

Varje arbetsyta kan associeras med arbetsytegatewayer för att aktivera körning av API:er som hanteras på arbetsytan. Arbetsytegatewayen är en fristående Azure-resurs med samma kärnfunktioner som gatewayen som är inbyggd i DIN API Management-tjänst.

Arbetsytegatewayer hanteras oberoende av API Management-tjänsten och från varandra. De säkerställer isolering av körning mellan arbetsytor, ökad API-tillförlitlighet, återhämtning och säkerhet och möjliggör tilldelning av körningsproblem till arbetsytor.

  • Information om kostnaden för arbetsytegatewayer finns i PRISSÄTTNING för API Management.
  • En detaljerad jämförelse av API Management-gatewayer finns i Översikt över API Management-gatewayer.

Gateway-värdnamn

Varje association av en arbetsyta till en arbetsytegateway skapar ett unikt värdnamn för API:er som hanteras på den arbetsytan. Standardvärdnamn följer mönstret <workspace-name>-<hash>.gateway.<region>.azure-api.net. För närvarande stöds inte anpassade värdnamn för arbetsytegatewayer.

Kommentar

Till och med oktober 2024 kan API:er på arbetsytor nås vid körning med hjälp av gatewayens värdnamn för din API Management-instans utöver värdnamnet för arbetsytegatewayen.

Nätverksisolering

En arbetsytegateway kan eventuellt konfigureras i ett privat virtuellt nätverk för att isolera inkommande och/eller utgående trafik. Om den är konfigurerad måste arbetsytegatewayen använda ett dedikerat undernät i det virtuella nätverket.

Detaljerade krav finns i Nätverksresurskrav för arbetsytegatewayer.

Kommentar

  • Nätverkskonfigurationen för en arbetsytegateway är oberoende av nätverkskonfigurationen för API Management-instansen.
  • För närvarande kan en arbetsytegateway bara konfigureras i ett virtuellt nätverk när gatewayen skapas. Du kan inte ändra gatewayens nätverkskonfiguration eller inställningar senare.

Skala kapacitet

Hantera gatewaykapacitet genom att manuellt lägga till eller ta bort skalningsenheter, ungefär som de enheter som kan läggas till i API Management-instansen på vissa tjänstnivåer. Kostnaderna för en arbetsytegateway baseras på antalet enheter som du väljer.

Regional tillgänglighet

Arbetsytegatewayer måste finnas i samma Azure-region och prenumeration som API Management-tjänsten.

Kommentar

Från och med augusti 2024 distribueras stöd för arbetsytegateway i följande regioner. Dessa regioner är en delmängd av dem där API Management är tillgängligt.

  • Västra USA
  • Norra centrala USA
  • USA, östra 2
  • Södra Storbritannien
  • Centrala Frankrike
  • Europa, norra
  • Asien, östra
  • Sydostasien
  • Australien, östra
  • Japan, östra

Gatewaybegränsningar

Följande begränsningar gäller för närvarande för arbetsytegatewayer:

  • En gateway kan endast associeras med en arbetsyta
  • En arbetsyta kan inte associeras med en gateway med egen värd
  • Arbetsytegatewayer stöder inte inkommande privata slutpunkter
  • API:er i arbetsytegatewayer kan inte tilldelas anpassade värdnamn
  • API:er i arbetsytor omfattas inte av Defender för API:er
  • Arbetsytegatewayer stöder inte API Management-tjänstens autentiseringshanterare
  • Arbetsytegatewayer stöder endast intern cache. extern cache stöds inte
  • Arbetsytegatewayer stöder inte syntetiska GraphQL-API:er och WebSocket-API:er
  • Arbetsytegatewayer stöder inte API:er som skapats från Azure-resurser som Azure OpenAI Service, App Service, Funktionsappar och så vidare
  • Det går inte att dela upp mått för begäranden efter arbetsyta i Azure Monitor. alla mått för arbetsytor aggregeras på tjänstnivå
  • Azure Monitor-loggar aggregeras på tjänstnivå. loggar på arbetsytenivå är inte tillgängliga
  • Arbetsytegatewayer stöder inte CA-certifikat
  • Arbetsytegatewayer stöder inte automatisk skalning
  • Arbetsytegatewayer stöder inte hanterade identiteter, inklusive relaterade funktioner som att lagra hemligheter i Azure Key Vault och använda authentication-managed-identity principen

RBAC-roller för arbetsytor

Azure RBAC används för att konfigurera arbetsytemedarbetares behörighet att läsa och redigera entiteter på arbetsytan. En lista över roller finns i Använda rollbaserad åtkomstkontroll i API Management.

Om du vill hantera API:er och andra resurser på arbetsytan måste arbetsytemedlemmar tilldelas roller (eller motsvarande behörigheter med anpassade roller) som är begränsade till API Management-tjänsten, arbetsytan och arbetsytegatewayen. Med den tjänstomfattande rollen kan du referera till vissa resurser på tjänstnivå från resurser på arbetsytans nivå. Du kan till exempel organisera en användare i en grupp på arbetsytenivå för att styra API:et och produktsynligheten.

Kommentar

För enklare hantering konfigurerar du Microsoft Entra-grupper för att tilldela arbetsytebehörigheter till flera användare.

Arbetsytor och andra API Management-funktioner

Arbetsytor är utformade för att vara fristående för att maximera uppdelningen av administrativ åtkomst och API-körning. Det finns flera undantag för att säkerställa högre produktivitet och möjliggöra plattformsomfattande styrning, observerbarhet, återanvändning och API-identifiering.

  • Resursreferenser – Resurser på en arbetsyta kan referera till andra resurser på arbetsytan och valda resurser från tjänstnivå, till exempel användare, auktoriseringsservrar eller inbyggda användargrupper. De kan inte referera till resurser från en annan arbetsyta.

    Av säkerhetsskäl går det inte att referera till resurser på tjänstnivå från principer på arbetsytenivå (till exempel namngivna värden) eller efter resursnamn, till exempel backend-id i principen set-backend-service .

    Viktigt!

    Alla resurser i en API Management-tjänst (till exempel API:er, produkter, taggar eller prenumerationer) måste ha unika namn, även om de finns på olika arbetsytor. Det kan inte finnas några resurser av samma typ och med samma Azure-resursnamn på samma arbetsyta, på andra arbetsytor eller på tjänstnivå.

  • Utvecklarportal – Arbetsytor är ett administrativt begrepp och visas inte som sådana för användare av utvecklarportalen, bland annat via utvecklarportalens användargränssnitt och det underliggande API:et. API:er och produkter på en arbetsyta kan publiceras på utvecklarportalen, precis som API:er och produkter på tjänstnivå.

    Kommentar

    API Management stöder tilldelning av auktoriseringsservrar som definierats på tjänstnivå till API:er på arbetsytor.

Migrera från förhandsgranskningsarbetsytor

Om du har skapat förhandsgranskningsarbetsytor i Azure API Management och vill fortsätta använda dem migrerar du dina arbetsytor till den allmänt tillgängliga versionen genom att associera en arbetsytegateway med varje arbetsyta.

Mer information och information om andra ändringar som kan påverka dina förhandsgranskningsarbetsytor finns i Ändringar som bryter mot arbetsytor (mars 2025).

Ta bort en arbetsyta

Om du tar bort en arbetsyta tas alla underordnade resurser (API:er, produkter och så vidare) och dess associerade gateway bort om du tar bort arbetsytan med hjälp av Azure-portalgränssnittet. Den tar inte bort API Management-instansen eller andra arbetsytor.

Relaterat innehåll