Integrera Azure API Management (APIM) med Fabric API för GraphQL

Integreringen av Azure API Management (APIM) med Microsoft Fabrics API för GraphQL förbättrar avsevärt api:ets funktioner genom att tillhandahålla robusta skalbarhets- och säkerhetsfunktioner. APIM fungerar som en gateway i företagsklass som lägger till avancerade funktioner som identitetshantering, hastighetsbegränsning, cachelagring av svar, skydd mot hot och centraliserad övervakning – allt utan att ändra konfigurationen av Infrastruktur-API:et.

Genom att dirigera dina GraphQL-begäranden via APIM kan du skala för att hantera ökad trafik, implementera avancerade säkerhetsprinciper och få insyn i API-användningsmönster i hela organisationen.

Den här artikeln vägleder dig genom att integrera APIM med Fabric API för GraphQL, konfigurera hanterad identitetsautentisering och implementera principer för cachelagring och hastighetsbegränsning.

Vem använder Azure API Management med GraphQL

APIM-integrering är värdefull för:

Företagsarkitekter exponerar Infrastrukturdata via en centraliserad, styrd API-gateway för organisationsomfattande åtkomst
Infrastrukturadministratörer som implementerar hastighetsbegränsning, cachelagring och säkerhetsprinciper för att skydda infrastrukturresursers kapacitet och data
IT-säkerhetsteam som kräver avancerad autentisering, auktorisering och hotskydd för åtkomst till infrastrukturdata
Plattformsteam som hanterar och styr flera Fabric GraphQL-API:er inom avdelningar och affärsenheter

Använd APIM-integrering när du behöver API-hanteringsfunktioner i företagsklass som hastighetsbegränsning, cachelagring, säkerhetsprinciper och centraliserad styrning för dina Fabric GraphQL-API:er.

Förutsättningar

Kontrollera att du har följande innan du börjar:

Ett Fabric-API för GraphQL har redan skapats. Om inte kan du läsa Skapa ett API för GraphQL eller använda Starta med SQL-exempeldatabas i API:et för GraphQL-portalen
En Azure API Management-instans. Installationsinstruktioner finns i Skapa en API Management-instans
Behörigheter för att skapa hanterade identiteter och konfigurera APIM-principer

Lägga till ett Fabric GraphQL-API i Azure API Management

Det första steget i att integrera APIM med Fabric är att importera graphQL-API:et till Azure API Management. Den här processen skapar en proxy som dirigerar begäranden via APIM samtidigt som anslutningen till dina infrastrukturdatakällor upprätthålls. Genom att importera API:et skapar du grunden för att lägga till företagsfunktioner som autentiseringsprinciper, cachelagring och hastighetsbegränsning.

Importprocessen kräver två informationsdelar från ditt Fabric GraphQL-API: slutpunkts-URL:en (där APIM skickar begäranden) och schemafilen (som definierar API-strukturen och tillgängliga åtgärder).

Exportera detaljer om GraphQL API

Samla först in nödvändig information från fabric GraphQL-API:et:

Öppna GraphQL-API:et i Infrastrukturportalen
I menyfliksområdet väljer du Kopiera slutpunkt för att hämta API:ens URL
Välj Exportera schema för att ladda ned GraphQL-schemafilen till din lokala enhet

Importera API:et till APIM

Nu när slutpunkts-URL:en och schemafilen är klara kan du registrera GraphQL-API:et i APIM. Detta skapar en API-definition som APIM använder för att verifiera begäranden, generera dokumentation och tillämpa principer. Schemat som du laddar upp definierar vilka frågor och mutationer klienter kan köra.

Navigera till DIN API Management-instans i Azure-portalen
Välj API:er>+ Lägg till API
Välj GraphQL-ikonen
På skärmen Skapa från GraphQL-schema anger du:
- Visningsnamn: Ett eget namn för API:et
- Namn: API-identifieraren
- GraphQL API-slutpunkt: URL för slutpunkten du kopierade från Fabric
Välj Ladda upp schema och välj den schemafil som du laddade ned

Konfigurera hanterad identitetsautentisering

Nu när ditt GraphQL-API har registrerats i APIM måste du konfigurera hur APIM autentiserar med Fabric. Hanterade identiteter tillhandahåller en säker, lösenordsfri autentiseringsmetod som eliminerar behovet av att lagra autentiseringsuppgifter i DIN APIM-konfiguration. Azure hanterar automatiskt identitetslivscykeln och hanterar tokenförvärv, vilket gör den här metoden både säkrare och enklare att underhålla än traditionella autentiseringsmetoder.

Autentiseringskonfigurationen omfattar tre huvudsakliga steg: att skapa den hanterade identiteten i Azure, ge den behörighet att komma åt din Infrastruktur-arbetsyta och datakällor och konfigurera APIM så att den använder den här identiteten när du gör begäranden till Fabric.

Skapa och tilldela en hanterad identitet

Skapa först den hanterade identitet som APIM använder för att autentisera:

Skapa en användartilldelad hanterad identitet i Azure-portalen.
Observera klient-ID:t för den hanterade identiteten – du behöver klient-ID:t för principkonfigurationen.

Bevilja behörigheter för hanterad identitet i Fabric

När du har skapat den hanterade identiteten måste du ge den behörighet att komma åt dina infrastrukturresurser. Den hanterade identiteten behöver åtkomst till både själva GraphQL API-objektet och alla datakällor som den ansluter till (till exempel lakehouses eller lager). Att lägga till identiteten som medlem i arbetsytan är den enklaste metoden eftersom den ger åtkomst till alla objekt på arbetsytan samtidigt.

Öppna arbetsytan Fabric som innehåller GraphQL-API:et
Välj Hantera åtkomst
Lägg till den hanterade identiteten (till exempel apim-id) med minst deltagarroll

Tips/Råd

För mer detaljerad kontroll kan du bevilja behörigheter direkt till enskilda infrastrukturobjekt (API:et och dess datakällor) i stället för åtkomst på arbetsytenivå. Detaljerad kontroll är särskilt viktigt om ditt API använder enkel inloggningsautentisering (SSO). Mer information finns i Sammanfattning av autentisering och behörigheter.

Konfigurera APIM för att använda den hanterade identiteten

Med de behörigheter som har beviljats i Fabric bör du ange för APIM vilken hanterad identitet som ska användas. Med den här associationen kan APIM autentisera som den identiteten när du gör begäranden till ditt Fabric GraphQL-API.

I Azure-portalen navigerar du till din APIM-instans
Gå tillSäkerhet>Hanterade identiteter
Lägg till den användartilldelade hanterade identiteten som du skapade tidigare

Lägg till autentiseringsprincip

Det sista autentiseringssteget är att lägga till en APIM-policy som hämtar en åtkomsttoken med hjälp av den hanterade identiteten och inkluderar den i begäranden till Fabric. Den här policyn körs på varje begäran och hanterar automatiskt tokenförvärv och -förnyelse. Principen använder authentication-managed-identity-elementet för att hämta en token för Fabric API-resursen och lägger sedan till den i Authorization-headern.

I graphQL-API:et i APIM väljer du fliken API-principer
Redigera policyn för inkommande bearbetning

Lägg till följande XML under <inbound><base/>:

<authentication-managed-identity 
    resource="https://analysis.windows.net/powerbi/api" 
    client-id="YOUR-MANAGED-IDENTITY-CLIENT-ID" 
    output-token-variable-name="token-variable" 
    ignore-error="false" />
<set-header name="Authorization" exists-action="override">
    <value>@("Bearer " + (string)context.Variables["token-variable"])</value>
</set-header>

Ersätt YOUR-MANAGED-IDENTITY-CLIENT-ID med den hanterade identitetens klient-ID
Spara principen

Testa anslutningen

Innan du fortsätter att lägga till cachelagring och hastighetsbegränsning kontrollerar du att autentiseringskonfigurationen fungerar korrekt. Testningen säkerställer nu att eventuella problem som du stöter på senare inte är relaterade till autentiseringskonfigurationen.

I APIM navigerar du till graphQL-API:et
Gå till fliken Test
Köra en exempelfråga eller mutation för att bekräfta att anslutningen fungerar

Konfigurera cachelagring av svar

Svarscachelagring minskar avsevärt fördröjningen för API-anropare och minskar belastningen på backend på dina Fabric-datakällor. APIM stöder inbyggd cachelagring eller externa Redis-instanser. För GraphQL-API:er använder cachelagring begärandetexten (GraphQL-frågan) som cachenyckel, vilket säkerställer att identiska frågor returnerar cachelagrade svar.

Fördelar med cachelagring av GraphQL-svar:

Kortare svarstid: Cachelagrade svar returneras omedelbart utan att fråga Fabric
Lägre kapacitetsförbrukning: Färre förfrågningar till Fabric minskar CU-användningen (kapacitetsenhet)
Bättre skalbarhet: Hantera fler samtidiga användare utan att öka serverdelsbelastningen

Lägg till cachelagringsprincip

Om du vill implementera cachelagring ändrar du den befintliga autentiseringsprincipen för att lägga till cacheuppslagning och lagringslogik. Policyn kontrollerar om det finns cachelagrade svar innan begäranden vidarebefordras till Fabric och lagrar lyckade svar för framtida användning. Det här fullständiga principexemplet visar hur autentisering och cachelagring fungerar tillsammans:

<policies>
    <inbound>
        <base />
        <!-- Authenticate with managed identity -->
        <authentication-managed-identity 
            resource="https://analysis.windows.net/powerbi/api" 
            client-id="YOUR-MANAGED-IDENTITY-CLIENT-ID" 
            output-token-variable-name="token-variable" 
            ignore-error="false" />
        <set-header name="Authorization" exists-action="override">
            <value>@("Bearer " + (string)context.Variables["token-variable"])</value>
        </set-header>
        <!-- Check if response is cached -->
        <cache-lookup-value 
            key="@(context.Request.Body.As<String>(preserveContent: true))" 
            variable-name="cachedResponse" 
            default-value="not_exists" />
    </inbound>
    <backend>
        <!-- Only forward request if not cached -->
        <choose>
            <when condition="@(context.Variables.GetValueOrDefault<string>("cachedResponse") == "not_exists")">
                <forward-request />
            </when>
        </choose>
    </backend>
    <outbound>
        <base />
        <choose>
            <!-- Return cached response if it exists -->
            <when condition="@(context.Variables.GetValueOrDefault<string>("cachedResponse") != "not_exists")">
                <set-body>@(context.Variables.GetValueOrDefault<string>("cachedResponse"))</set-body>
            </when>
            <!-- Cache successful responses for 60 seconds -->
            <when condition="@((context.Response.StatusCode == 200) && (context.Variables.GetValueOrDefault<string>("cachedResponse") == "not_exists"))">
                <cache-store-value 
                    key="@(context.Request.Body.As<String>(preserveContent: true))" 
                    value="@(context.Response.Body.As<string>(preserveContent: true))" 
                    duration="60" />
            </when>
        </choose>
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Så här fungerar den här principen:

Inkommande: Autentiserar med hanterad identitet och kontrollerar om svaret cachelagras baserat på GraphQL-frågan
Backend: Hoppar över vidarebefordran av begäran till Fabric om det finns ett cachelagrat svar
Utgående: Returnerar cachelagrade svar eller cachelagrar nya lyckade svar i 60 sekunder

Kontrollera att cachelagring fungerar

Bekräfta att begäranden cachelagras:

Kör samma GraphQL-fråga två gånger i APIM
Spåra API-anropet för att se cacheträffar

Optimera cachevaraktighet

I exemplet används en cachevaraktighet på 60 sekunder. Justera varaktigheten baserat på dina krav på data freshness:

Uppdateringar med hög frekvens: Använd kortare varaktigheter (10–30 sekunder) för data som ändras ofta
Statiska data eller referensdata: Använd längre varaktigheter (5–60 minuter) för data som ändras sällan
Realtidskrav: Cachelagrar inte frågor som alltid måste returnera de senaste data

Avancerade cachelagringsscenarier, inklusive cache-ogiltighet och extern Redis-konfiguration, finns i APIM-cachelagringsprinciper.

Begränsning av hastighet

Du kan begränsa antalet API-anrop som en klient kan göra under en viss tidsperiod. Här är ett exempel på en princippost som begränsar hastighetsbegränsningen som du kan lägga till nedan <inbound><base/> och som inte kräver fler än två anrop var 60:e sekund för en viss användare:

<rate-limit-by-key 
    calls="2" 
    renewal-period="60" 
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization"))" 
    increment-condition="@(context.Response.StatusCode == 200)" 
    remaining-calls-variable-name="remainingCallsPerUser" />

När du har skickat fler än två API-anrop på en minut får du ett felmeddelande:

{
    "statusCode": 429,
    "message": "Rate limit is exceeded. Try again in 58 seconds."
}

Mer information om hur du konfigurerar principer för hastighetsbegränsning i APIM finns i dokumentationen.

Metodtips

När du integrerar APIM med Fabric API för GraphQL följer du dessa rekommendationer:

Security

Använd hanterade identiteter: Föredrar hanterade identiteter framför API-nycklar eller anslutningssträngar för autentisering
Implementera minsta behörighet: Bevilja endast de minsta behörigheter som krävs för den hanterade identiteten
Aktivera endast HTTPS: Konfigurera APIM för att avvisa HTTP-begäranden och framtvinga HTTPS
Verifiera indata: Använd APIM-principer för att validera GraphQL-frågor innan de skickas vidare till Fabric

Performance

Cachelagrar data som används ofta: Identifiera vanliga frågor och ange lämpliga cachevaraktigheter
Övervaka cacheträffar: Använd APIM-analys för att spåra cacheeffektivitet
Optimera hastighetsbegränsningar: Balansera användarupplevelsen med kapacitetsskydd
Använd regional distribution: Distribuera APIM i samma region som din Fabric-kapacitet

Övervakning och styrning

Aktivera diagnostik: Konfigurera APIM-diagnostikloggning för att spåra API-användning
Konfigurera aviseringar: Skapa aviseringar för hastighetsbegränsningsöverträdelser och fel
Versionera dina API:n: Använd APIM-versionshantering för att hantera brytande ändringar
Dokumentera dina API:er: Använd APIM:s utvecklarportal för att tillhandahålla API-dokumentation

Kostnadsoptimering

Hastighetsbegränsningar för rätt storlek: Ange gränser som överensstämmer med din kapacitetsnivå
Övervaka kapacitetsförbrukning: Spåra både APIM- och Fabric-kapacitetsanvändning
Använd cachelagring strategiskt: Balansera krav på färskhet med kapacitetsbesparingar
Granska användningsmönster: Analysera regelbundet vilka frågor som förbrukar mest resurser

Sammanfattning

Integreringen av Microsoft Fabric API för GraphQL med Azure API Management sammanför Fabrics kraftfulla datafunktioner med APIM:s API Gateway-funktioner i företagsklass. Den här kombinationen ger:

Förbättrad säkerhet: Hanterad identitetsautentisering, hotskydd och principbaserad åtkomstkontroll
Förbättrad skalbarhet: Cachelagring av svar, hastighetsbegränsning och belastningsfördelning över flera serverdelar
Bättre prestanda: Kortare svarstid genom cachelagring och optimerad routning av begäranden
Centraliserad styrning: Enhetlig övervakning, versionshantering och hantering över flera API:er
Kostnadskontroll: Begränsning av förfrågningstakt och cachelagring minskar kapacitetsförbrukningen hos systemfabric

Genom att följa konfigurationsstegen och metodtipsen i den här artikeln kan du skapa ett robust, säkert och skalbart API-lager som stöder produktionsarbetsbelastningar i hela organisationen.

Feedback

Var den här sidan hjälpsam?

Last updated on 2026-01-20