Integrerad API-hantering med arbetsytor

GÄLLER FÖR: Basic v2 | Standard v2 | Premium | Premium v2

Den här artikeln innehåller en översikt över API Management-arbetsytor och hur de ger decentraliserade API-utvecklingsteam möjlighet att hantera och produktisera sina API:er i en gemensam tjänstinfrastruktur.

Varför ska organisationer federera API-hantering?

Idag står organisationer i allt högre grad inför utmaningar när det gäller att hantera en spridning av API:er. I takt med att antalet API:er och API-utvecklingsteam växer ökar även komplexiteten i hanteringen av dem. Den här komplexiteten kan leda till ökade driftkostnader, säkerhetsrisker och minskad flexibilitet. Å ena sidan vill organisationer upprätta en centraliserad API-infrastruktur för att säkerställa API-styrning, säkerhet och efterlevnad. Å andra sidan vill de att deras API-team ska förnya och svara snabbt på affärsbehoven, utan att behöva hantera en API-plattform.

En federerad modell för API-hantering tillgodoser dessa behov. Federerad API-hantering möjliggör decentraliserad API-hantering av utvecklingsteam med lämplig isolering av kontroll- och dataplan, samtidigt som centraliserad styrning, övervakning och API-identifiering hanteras av ett API-plattformsteam. Den här modellen övervinner begränsningarna för alternativa metoder, till exempel fullständigt centraliserad API-hantering av plattformsteamet eller siloed API-hantering av varje utvecklingsteam.

Federerad API-hantering tillhandahåller:

• Centraliserad API-styrning och observerbarhet
• En enhetlig utvecklarportal för effektiv API-identifiering och registrering
• Åtskilda administrativa behörigheter mellan API-team, förbättrad produktivitet och säkerhet
• Segregerad API-körning mellan API-team, förbättra tillförlitlighet, återhämtning och säkerhet

Så här aktiverar arbetsytor federerad API-hantering

I Azure API Management använder du arbetsytor för att implementera federerad API-hantering. Arbetsytor fungerar som "mappar" i en API Management-tjänst:

• Varje arbetsyta innehåller API:er, produkter, prenumerationer, namngivna värden och relaterade resurser. Se API Management REST API-referensen för en fullständig lista över resurser och åtgärder som stöds i arbetsytor.
• Teams åtkomst till resurser på en arbetsyta hanteras via Azures rollbaserade åtkomstkontroll (RBAC) med inbyggda eller anpassade roller som kan tilldelas Till Microsoft Entra-konton och begränsas till en arbetsyta.
• Varje arbetsyta är associerad med en eller flera gatewayer för att dirigera API-trafik till serverdelstjänsterna för API:er på arbetsytan. Beroende på tjänstnivå och dina krav kan en arbetsyta använda tjänstens standardhanterade gateway eller en eller flera arbetsytegatewayer.
• Plattformsteamet kan tillämpa principer som omfattar API:er och produkter på arbetsytor för att styra API-körning i hela organisationen. Med en inbyggd Azure Policy-definition (API Management policies should inherit parent scope policies using <base/>) kan du granska eller framtvinga att dessa principer tillämpas på alla arbetsyteresurser.
• Plattformsteamet kan implementera en centraliserad API-identifieringsupplevelse med en utvecklarportal.
• Varje arbetsyteteam kan samla in och analysera gatewayresursloggar för att övervaka sina egna API:er för arbetsytor, medan plattformsteamet har federerad åtkomst till loggar över alla arbetsytor i API Management-tjänsten, vilket ger tillsyn, säkerhet och efterlevnad i api-ekosystemet.

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.

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. Genom att använda 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 arbetsflöde visar en exempelprocess 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. Du kan till exempel tilldela behörigheter för att skapa eller läsa resurser på arbetsytan. Teamet skapar eller associerar antingen en API-gateway med arbetsytan för att dirigera API-trafik.

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.

Arbetsyta-gateway

Varje arbetsyta konfigureras med en eller flera gatewayer för att aktivera körning av API:er som hanteras på arbetsytan. Beroende på tjänstnivå och dina krav kan du använda tjänstens standardhanterade gateway och/eller en eller flera arbetsytegatewayer (separata gatewayresurser).

Förvald hanterad gateway

På v2-nivåerna kan du konfigurera en arbetsyta för att dirigera API-trafik via tjänstens standardhanterade gateway, förutom en eller flera separata resurser för arbetsytans gateway. När en arbetsyta använder den standardhanterade gatewayen:

• API-trafik dirigerar via tjänstens standardvärdnamn (till exempel <service-name>.azure-api.net).
• Arbetsytan delar gatewayens kapacitet och konfiguration med andra arbetsytor och API:er på tjänstnivå.

Arbetsyta-gateway

En arbetsytegateway är en fristående Azure-resurs (workspace gateway premium) som har samma grundläggande funktioner som den standardhanterade gatewayen.

Du hanterar arbetsytegatewayer oberoende av API Management-tjänsten och från varandra. De möjliggör isolering av körning mellan arbetsytor eller användningsfall, vilket ökar API:s tillförlitlighet, återhämtning och säkerhet. De gör det också möjligt att koppla körningsproblem till arbetsytor.

• För information om kostnader för arbetsplatsgatewayer, se Prissättning för API Management.
• En detaljerad jämförelse av API Management-gatewayer finns i Översikt över API Management-gatewayer.

Associera arbetsytor med en arbetsytegateway

Beroende på organisationens behov kan du associera en arbetsyta eller flera arbetsytor med en arbetsytegateway.

• En arbetsytegateway har vissa konfigurationsinställningar, till exempel virtuellt nätverk, skalning och värdnamn, samt allokerade beräkningsresurser, inklusive processor-, minnes- och nätverksresurser.
• Alla arbetsytor som distribueras på en gateway delar konfigurations- och beräkningsresurserna.
• Buggar i ett API eller avvikande trafik kan orsaka överbelastning av dessa resurser, vilket påverkar alla arbetsytor på den gatewayen. Med andra ord, ju fler arbetsytor du distribuerar på en gateway, desto högre är risken att ett API från en arbetsyta upplever tillförlitlighetsproblem som orsakas av ett API från en annan arbetsyta.
• Övervaka din arbetsytegateways prestanda med hjälp av inbyggda mått för processor- och minnesanvändning.

Överväg tillförlitlighet, säkerhet och kostnad när du väljer en distributionsmodell för arbetsytor.

• Tilldela en arbetsyta till en egen dedikerad arbetsytegateway för verksamhetskritiska arbetsbelastningar – För att maximera API:ets tillförlitlighet och säkerhet tilldelar du varje verksamhetskritisk arbetsyta till en egen gateway och undviker delad användning med andra arbetsytor.
• Balansera tillförlitlighet, säkerhet och kostnad – Associera flera arbetsytor med en arbetsytegateway (eller, om tillämpligt, standardhanterad gateway) för att balansera tillförlitlighet, säkerhet och kostnad för icke-kritiska arbetsbelastningar. Distribuera arbetsytor över minst två gatewayer för att förhindra att problem, till exempel resursöverbelastning eller konfigurationsfel, påverkar alla API:er i organisationen.
• Använd distinkta gatewayer för olika användningsfall – Gruppera arbetsytor på en arbetsytegateway baserat på användningsfall eller nätverkskrav. Du kan till exempel skilja mellan interna och externa API:er genom att tilldela dem till separata gatewayer, var och en med sin egen nätverkskonfiguration.
• Prepare för att placera problemfyllda arbetsytor i karantän – Använd en proxy, till exempel Azure Application Gateway eller Azure Front Door, framför delade arbetsytegatewayer för att förenkla flytten av en arbetsyta som orsakar resursöverbelastning till en annan gateway. Den här metoden förhindrar påverkan på andra arbetsytor som delar gatewayen.

Värdnamn för arbetsytans gateway

Varje arbetsytegateway ger ett unikt värdnamn för API:er som hanteras på en associerad arbetsyta. Standardvärdnamn följer mönstret <gateway-name>-<hash>.gateway.<region>.azure-api.net. Använd gatewayens värdnamn för att dirigera API-begäranden till din arbetsytas API:er.

För närvarande stöder inte arbetsytegatewayer anpassade värdnamn. Du kan konfigurera Azure Application Gateway eller Azure Front Door med ett anpassat värdnamn framför en arbetsytegateway.

Nätverksisolering för arbetsytegatewayer

Du kan valfritt konfigurera en arbetsytegatewayresurs i ett privat virtuellt nätverk för att isolera inkommande och utgående trafik. Om du konfigurerar den här isoleringen måste arbetsytegatewayen använda ett dedikerat undernät i det virtuella nätverket.

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

Skala upp kapaciteten för arbetsytegatewayar

Hantera kapaciteten för en arbetsytegateway genom att lägga till eller ta bort skalningsenheter, ungefär som de enheter som du kan lägga 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 för arbetsytegatewayer

En aktuell lista över regioner där arbetsytegatewayer är tillgängliga finns i Tillgänglighet för v2-nivåer och arbetsytegatewayer.

Begränsningar för arbetsyta och arbetsytegateway

Begränsningar för arbetsytor

• En arbetsyta kan inte associeras med en gateway med egen värd
• API:er i arbetsytor omfattas inte av Defender för API:er
• Arbetsytor har inte stöd för autentiseringshanteraren
• Arbetsytor stöder endast intern cache. extern cache stöds inte
• Arbetsytor stöder inte syntetiska GraphQL-API:er
• Arbetsytor har inte stöd för att skapa API:er direkt från Azure resurser som Azure OpenAI Service, App Service, Funktionsappar och så vidare i Azure-portalen
• Arbetsytor stöder inte MCP-servrar
• 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å
• Arbetsytor stöder inte CA-certifikat
• Arbetsytor stöder inte hanterade identiteter, inklusive relaterade funktioner som att lagra hemligheter i Azure Key Vault och använda principen authentication-managed-identity

Begränsningar för gatewayen för arbetsytan

Följande begränsningar gäller för gatewayresursen för hanterade arbetsytor. De gäller inte när du använder arbetsytor på tjänstens standardhanterade gateway.

• Arbetsplatsportar stöder inte inkommande privata anslutningspunkter.
• Workspace-gatewayer stöder inte anpassade värdnamn
• Arbetsytor kan bara associeras med arbetsytegatewayer som finns i samma region och prenumeration som API Management-resursen

Global principarv i arbetsytegatewayer

Arbetsytegatewayer kör hela principkedjan, inklusive den globala principen på tjänstnivå (global.policy.xml). Det här beteendet innebär att alla principer som definierats i det globala omfånget utvärderas och körs för API-anrop som bearbetas av arbetsytegatewayer, precis som de är för standardgatewayen. Det här beteendet är avsiktligt och överensstämmer med utvärderingsmodellen för principer i API Management, där du tillämpar principer hierarkiskt i följande omfattningar: global (tjänst) > arbetsyta > produkt > API > åtgärd.

Rekommendationer för globala policyer med arbetsplatsportar

• Granska din globala princip för att se till att den endast innehåller principer som är avsedda att tillämpas på alla gatewayer, inklusive arbetsytegatewayer.

• Om du behöver olika beteende per gateway ska du använda choose-principen med context.Deployment.Gateway.Id för att villkorligt tillämpa principer baserat på den gateway som bearbetar begäran.

• Om du definierar en autentiseringshanterad identitet i det globala omfånget men token inte ska vara tillgänglig för API:er med arbetsyteomfattning flyttar du principen till ett smalare omfång (till exempel produkt- eller API-nivå) i stället för den globala 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 tilldelar du roller till medlemmar i arbetsytan (eller motsvarande behörigheter via anpassade roller) som är begränsade till API Management-tjänsten och arbetsytan. Med en tjänstomfattad roll kan du referera till vissa resurser på tjänstenivå 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.

Om arbetsytan använder en dedikerad arbetsytegateway bör medlemmar som hanterar gatewayen också tilldelas en roll som är begränsad till arbetsytans gatewayresurs.

Arbetsytor och andra API Management-funktioner

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

• 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 kan du inte 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 .

  Important

  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. Du kan inte ha 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. Du kan publicera API:er och produkter på en arbetsyta till utvecklarportalen, precis som API:er och produkter på tjänstnivå.

  Note

  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.

För mer information om andra ändringar som kan påverka dina förhandsgranskningsarbetsytor, se Betydande ändringar i arbetsytor (mars 2025).

Ta bort en arbetsyta

När du tar bort en arbetsyta med hjälp av Azure portalgränssnittet tar du även bort alla underordnade resurser (API:er, produkter och så vidare) och en dedikerad arbetsytegateway om en är associerad. Den tar inte bort API Management-instansen eller andra arbetsytor.

Relaterat innehåll

• Skapa en arbetsyta
• Ändringar i arbetsytors funktion – juni 2024
• Stora förändringar för arbetsytor – mars 2025
• Gränser – API Management-arbetsytor