Dela via

Använda Azure API Management i en lösning med flera klientorganisationer

  • Artikel

Azure API Management är en omfattande API-gateway och omvänd proxy för API:er. Den innehåller många funktioner, inklusive cachelagring, svarsförakt och en utvecklarportal som är användbar för API-fokuserade program. Den här artikeln sammanfattar några av de viktigaste funktionerna i API Management som är användbara för lösningar med flera klientorganisationer.

Kommentar

Den här artikeln fokuserar på hur du kan använda API Management när du har egna program med flera klienter som är värdar för API:er för intern eller extern användning.

En annan form av multitenancy är att tillhandahålla API Management-gatewayen som en tjänst till andra team. En organisation kan till exempel ha en delad API Management-instans som flera programteam distribuerar till och använder. Den här artikeln beskriver inte den här typen av fleraktivering. Överväg att använda arbetsytor som hjälper dig att dela en API Management-instans mellan flera team som kan ha olika åtkomstnivåer.

Isoleringsmodeller

API Management distribueras vanligtvis som en delad komponent med en enda instans som hanterar begäranden för flera klienter. Men baserat på din innehavarmodell finns det många sätt att distribuera API Management. Den här artikeln förutsätter att du distribuerar din lösning med hjälp av distributionsstämplar.

Normalt är sättet du använder API Management på liknande sätt, oavsett isoleringsmodell. Det här avsnittet fokuserar på skillnaderna i kostnad och komplexitet mellan isoleringsmodellerna och hur varje metod dirigerar begäranden till dina serverdels-API-program.

Att tänka på Delad instans med serverdelar med en klientorganisation Delad instans med delad serverdel för flera klientorganisationer Instans för varje klientorganisation
Antal klienter som stöds Många Nästan obundna En för varje instans
Kostnad Lower Lower Högre
Distributionskomplexitet Låg: Enskild instans att hantera för varje stämpel Låg: Enskild instans att hantera för varje stämpel Hög: Flera instanser att hantera
Konfigurationskomplexitet för routning Högre Lower Lower
Känslighet för problem med bullriga grannar Ja Ja Nej
Nätverksisolering på klientnivå Nej Nej Ja
Exempelscenario Anpassade domännamn för varje klientorganisation Stor lösning för flera klientorganisationer med en delad programnivå Klientspecifika distributionsstämplar

Isoleringsmodeller för delad instans

Det är vanligt att dela en API Management-instans mellan flera klienter, vilket bidrar till att minska kostnaderna och distributionen och hanteringskomplexiteten. Information om hur du kan dela en API Management-instans beror på hur du tilldelar klientorganisationer till serverdels-API-program.

Serverdelsprogram för en klientorganisation

Om du distribuerar distinkta serverdelsprogram för varje klientorganisation kan du distribuera en enda API Management-instans och dirigera trafik till rätt klientdel för varje begäran. Den här metoden kräver att du konfigurerar API Management med serverdelsvärdnamnen för varje klientorganisation eller har ett annat sätt att mappa en inkommande begäran till rätt klientorganisations serverdel.

Eftersom det kräver en extra sökning kanske den här metoden inte skalas till ett stort antal klienter som delar en enda API Management-instans. Det kan också finnas vissa prestandakostnader när du letar upp klientorganisationens serverdel. Storleken på prestandakostnaderna beror dock på hur du utformar en sådan sökning.

Delat serverdelsprogram för flera klientorganisationer

I scenarier där dina klienter delar ett vanligt serverdelsprogram förenklas API Management-routningsprocessen eftersom du kan dirigera alla begäranden till en enskild serverdel. Om du använder jokerteckendomäner eller providerutgivna domäner kanske du kan uppnå nästan obundna skalningar med den här metoden. Eftersom begäranden inte behöver mappas till en klientorganisations serverdel påverkas inte heller prestandan av anpassade routningsbeslut.

Instans för varje klientorganisation

I vissa situationer kan du distribuera en instans av API Management för varje klientorganisation. Vi rekommenderar den här metoden endast om du har ett litet antal klienter eller om du har strikta efterlevnadskrav som hindrar dig från att dela någon infrastruktur mellan klienter. Om du till exempel distribuerar ett dedikerat virtuellt nätverk för varje klientorganisation måste du förmodligen också distribuera en dedikerad API Management-instans för varje klientorganisation.

Dricks

Om din enda anledning till att distribuera flera instanser är att stödja användare i olika geografiska regioner kanske du vill överväga om multiregiondistributionsfunktionen i API Management uppfyller dina krav.

När du distribuerar en instans av API Management måste du överväga tjänstgränserna, inklusive eventuella begränsningar som kan gälla för antalet API Management-instanser i en Azure-prenumeration eller region.

Instanser med en klientorganisation har vanligtvis minimal routningskonfiguration eftersom du kan dirigera alla begäranden till en enskild serverdel. Det här scenariot kräver inte anpassade routningsbeslut, så det finns ingen extra prestandapåverkan. Men vanligtvis medför du en högre resurskostnad än om du distribuerar en delad instans. Om du behöver distribuera instanser med en enda klientorganisation bör du överväga om lokala gatewayer gör att du kan återanvända klientspecifika beräkningsresurser som du redan distribuerar.

API Management-funktioner som stöder flera klientorganisationer

API Management använder principer för att aktivera flexibilitet. Du kan anpassa hur begäranden verifieras, dirigeras och bearbetas när du använder principer. Och när du utformar en lösning för flera klientorganisationer med API Management använder du principer för att implementera många av dess funktioner.

Identifiera klientorganisationer för inkommande begäranden

Fundera på hur du kan identifiera lämplig klientorganisation i varje inkommande begäran. I en lösning med flera klienter är det viktigt att ha en tydlig förståelse för vem som gör varje begäran så att du returnerar data för den specifika klientorganisationen och ingen annan.

API Management tillhandahåller prenumerationer som du kan använda för att autentisera begäranden. Dessa prenumerationer använder en unik prenumerationsnyckel som hjälper dig att identifiera prenumeranten som gör begäran. Om du väljer att använda prenumerationer bör du överväga hur du kan mappa API Management-prenumerationerna till din egen klientorganisation eller kundidentifierare. Prenumerationer är nära integrerade i utvecklarportalen. För de flesta lösningar är det en bra idé att använda prenumerationer för att identifiera klienter.

Du kan också identifiera klientorganisationen med hjälp av andra metoder. Här följer några exempel på metoder som körs inom en anpassad princip som du definierar:

  • Använd en anpassad komponent i URL:en, till exempel en underdomän, sökväg eller frågesträng. I URL:en https://api.contoso.com/tenant1/productskan du till exempel extrahera den första delen av sökvägen tenant1och behandla den som en klientidentifierare. Med tanke på den inkommande URL:en https://tenant1.contoso.com/productskan du på samma sätt extrahera underdomänen. tenant1 Om du vill använda den här metoden bör du överväga att parsa sökvägen eller frågesträngen Context.Request.Url från egenskapen .

  • Använd ett begärandehuvud. Dina klientprogram kan till exempel lägga till en anpassad TenantID rubrik i begäranden. Om du vill använda den här metoden kan du läsa från Context.Request.Headers samlingen.

  • Extrahera anspråk från en JSON-webbtoken (JWT). Du kan till exempel ha ett anpassat tenantId anspråk i en JWT som utfärdas av din identitetsprovider. Om du vill använda den här metoden använder du principen validate-jwt och anger output-token-variable-name egenskapen så att principdefinitionen kan läsa värdena från token.

  • Leta upp klientorganisationsidentifierare dynamiskt. Du kan kommunicera med en extern databas eller tjänst medan begäran bearbetas. Med den här metoden kan du skapa anpassad klientmappningslogik för att mappa en logisk klientidentifierare till en specifik URL eller för att hämta ytterligare information om en klientorganisation. Använd principen för att skicka begäran om du vill använda den här metoden.

    Den här metoden kommer sannolikt att öka svarstiden för dina begäranden. För att minimera den här effekten är det en bra idé att använda cachelagring för att minska antalet anrop till det externa API:et. Du kan använda principerna cache-store-value och cache-lookup-value för att implementera en cachelagringsmetod. Se till att göra cachen ogiltig med varje tillagd, borttagen eller flyttad klientorganisation som påverkar serverdelssökningen.

Namngivna värden

API Management stöder namngivna värden, som är anpassade konfigurationsinställningar som du kan använda i dina principer. Du kan till exempel använda ett namngivet värde för att lagra en klients serverdels-URL och sedan återanvända samma värde på flera platser i dina principer. Om du behöver uppdatera URL:en kan du uppdatera den på en enda plats.

Varning

I en lösning med flera klientorganisationer är det viktigt att vara försiktig när du anger namnen på dina namngivna värden. Om inställningarna varierar mellan klientorganisationer måste du inkludera klientidentifieraren i namnet. Du kan till exempel använda ett mönster som tenantId-key:value när du har bekräftat att det tenantId är lämpligt för begäran.

Inkludera identifieraren för att minska risken för att oavsiktligt referera till eller manipuleras till att referera till en annan klients värde när du bearbetar en begäran för en annan klientorganisation.

Autentisera inkommande begäranden

API-begäranden som görs till API Management-gatewayen måste vanligtvis autentiseras. API Management tillhandahåller flera metoder för att autentisera inkommande begäranden till gatewayen, inklusive OAuth 2.0 och klientcertifikat. Överväg vilka typer av autentiseringsuppgifter som du bör ha stöd för och var de ska verifieras. Överväg till exempel om valideringen ska ske i API Management, i dina serverdelsprogram eller på båda platserna.

Mer information finns i Autentisering och auktorisering till API:er i Azure API Management.

Kommentar

Om du använder en prenumerationsnyckel eller API-nyckel är det bra att även använda en annan autentiseringsmetod.

Enbart en prenumerationsnyckel är inte en stark form av autentisering, men den är användbar för andra scenarier, till exempel för att spåra en enskild klients API-användning.

Dirigera till klientspecifika serverdelar

När du använder API Management som en delad komponent kan du behöva dirigera inkommande API-begäranden till olika klientspecifika serverdelar. Dessa serverdelar kan finnas i olika distributionsstämplar, eller så kan de vara olika program inom en enda stämpel. Om du vill anpassa routningen i en principdefinition använder du principen set-backend-service . Du måste ange den nya bas-URL:en som begäran ska omdirigeras till.

Cachesvar eller andra data

API Management har en kraftfull cachefunktion som du kan använda för att cachelagrar hela HTTP-svar eller andra data. Du kan till exempel använda cachen för klientmappningar om du använder anpassad logik eller om du söker efter mappningen från en extern tjänst.

Använd principerna cache-store-value och cache-lookup-value för att implementera en cachelagringsmetod.

Varning

I en lösning med flera klientorganisationer är det viktigt att vara försiktig när du ställer in cachenycklarna. Om cachelagrade data kan variera mellan klientorganisationer kontrollerar du att du inkluderar klientidentifieraren i cachenyckeln.

Inkludera identifieraren för att minska risken för att oavsiktligt referera till att manipuleras till att referera till en annan klients värde när du bearbetar en begäran för en annan klientorganisation.

Anpassade domäner

Använd API Management för att konfigurera dina egna anpassade domäner för API-gatewayen och utvecklarportalen. På vissa nivåer kan du konfigurera jokerteckendomäner eller flera fullständigt kvalificerade domännamn (FQDN).

Du kan också använda API Management tillsammans med en tjänst som Azure Front Door. I den här typen av konfiguration hanterar Azure Front Door ofta anpassade domäner och TLS-certifikat (Transport Layer Security) och kommunicerar med API Management med hjälp av ett enda domännamn. Om den ursprungliga URL:en från klienten innehåller klientinformation som du behöver skicka till API Management-instansen för senare bearbetning kan du överväga att använda X-Forwarded-Host begärandehuvudet eller använda Azure Front Door-regler för att skicka informationen som ett HTTP-huvud.

Hastighetsbegränsningar

Det är vanligt att tillämpa kvoter eller hastighetsgränser i en lösning med flera klientorganisationer. Hastighetsbegränsningar kan hjälpa dig att minska problemet med bullriga grannar. Du kan också använda hastighetsgränser för att framtvinga tjänstens kvalitet och skilja mellan olika prisnivåer.

Använd API Management för att framtvinga klientspecifika hastighetsbegränsningar. Om du använder klientspecifika prenumerationer bör du överväga att använda kvotprincipen för att framtvinga en kvot för varje prenumeration. Du kan också överväga att använda principen för kvot för nyckel för att framtvinga kvoter med hjälp av en annan hastighetsgränsnyckel, till exempel en klientidentifierare som du fick från begärande-URL:en eller en JWT.

Skapa intäkter

API Management-dokumentationen innehåller omfattande vägledning om hur du tjänar pengar på API:er, inklusive en exempelimplementering. Intäktsgenereringsmetoderna kombinerar många av funktionerna i API Management så att utvecklare kan publicera ett API, hantera prenumerationer och debitera baserat på olika användningsmodeller.

Kapacitetshantering

En API Management-instans stöder en viss mängd kapacitet, vilket representerar de resurser som är tillgängliga för att bearbeta dina begäranden. När du använder komplexa principer eller distribuerar fler API:er till instansen förbrukar du mer kapacitet. Du kan hantera kapaciteten för en instans på flera sätt, till exempel genom att köpa fler enheter. Du kan också dynamiskt skala kapaciteten för din instans.

Vissa multitenantinstanser kan förbruka mer kapacitet än instanser med en klientorganisation, till exempel om du använder många principer för routning av begäranden till olika klientdelsservrar. Överväg att planera kapaciteten noggrant och planera för att skala instansens kapacitet om du ser din användningsökning. Du bör också testa lösningens prestanda för att förstå dina kapacitetsbehov i förväg.

Mer information om skalning av API Management finns i Uppgradera och skala en Azure API Management-instans.

Distributioner i flera regioner

API Management stöder distributioner i flera regioner, vilket innebär att du kan distribuera en enda logisk API Management-resurs i flera Azure-regioner utan att behöva replikera konfigurationen till separata resurser. Den här funktionen är särskilt användbar när du distribuerar eller replikerar din lösning globalt. Du kan effektivt distribuera en uppsättning API Management-instanser i flera regioner, vilket möjliggör bearbetning av begäranden med låg latens och hantera dem som en enda logisk instans.

Men om du behöver helt isolerade API Management-instanser kan du också välja att distribuera oberoende API Management-resurser till olika regioner. Den här metoden separerar hanteringsplanet för varje API Management-instans.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Annan deltagare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Granska arkitekturmetoderna för integrering i lösningar för flera klientorganisationer.