Förstå HTTP-pipelinen och återförsök i Azure SDK för Python

När du anropar en Azure-tjänst med hjälp av Azure SDK för Python går din begäran inte direkt till Azure-tjänsten. Det spelar ingen roll om det är Azure Blob Storage, Azure Key Vault, Azure Cosmos DB eller någon annan HTTP-baserad tjänst. I stället flödar din begäran via en avancerad HTTP-pipeline som hanterar kritiska övergripande problem automatiskt.

Det är viktigt att förstå hur HTTP-pipelinen fungerar för att skapa robusta, högpresterande program. Pipelinen:

  • Hanterar återförsök för tillfälliga fel.
  • Hanterar autentisering.
  • Tillhandahåller loggningsfunktioner.
  • Gör att du kan lägga till anpassat beteende när det behövs.

Den här kunskapen hjälper dig att felsöka prestandaproblem, optimera återhämtning och anpassa ditt programs interaktion med Azure-tjänster.

Vad är HTTP-pipelinen?

Azure SDK för Python använder en intern HTTP-pipelinearkitektur för att bearbeta alla begäranden och svar. Den här pipelinen består av en serie policyer som körs i följd. Varje princip ansvarar för en specifik aspekt av HTTP-kommunikationen. Tänk på pipelinen som en kedja av bearbetningssteg:

Client Request → Retry Policy → Authentication Policy → Logging Policy → HTTP Transport → Azure Service
                                                                                              ↓
Client Response ← Retry Policy ← Authentication Policy ← Logging Policy ← HTTP Transport ← Response

Varje princip i pipelinen kan:

  • Ändra begäran innan den skickas.
  • Bearbeta svaret när det har tagits emot.
  • Utför åtgärder som att försöka utföra misslyckade begäranden igen.
  • Lägg till rubriker, logginformation eller implementera anpassad logik.

Viktiga principer i pipelinen

Azure SDK för Python innehåller flera inbyggda principer som hanterar vanliga scenarier:

  • RetryPolicy: Återförsöker automatiskt begäranden som misslyckas på grund av tillfälliga fel. Den här principen implementerar intelligent återförsökslogik med exponentiell backoff för att undvika överväldigande tjänster vid avbrott.
  • BearerTokenCredentialPolicy: Hanterar autentisering genom att automatiskt hämta och uppdatera åtkomsttoken. Den här principen säkerställer att dina begäranden innehåller giltiga autentiseringsuppgifter utan manuell tokenhantering.
  • NetworkTraceLoggingPolicy: Samlar in detaljerad information om HTTP-begäranden och svar i felsökningssyfte. Den här principen är ovärderlig när du felsöker kommunikationsproblem.
  • HttpTransport: Det lägsta lagret i pipelinen som faktiskt skickar HTTP-begäranden över nätverket. I Azure SDK för Python implementeras den här principen vanligtvis med hjälp av begäranden eller aiohttp för asynkrona åtgärder.

Andra principer

  • RedirectPolicy: Hanterar HTTP-omdirigeringar automatiskt.
  • DistributedTracingPolicy: Integrerar med distribuerade spårningssystem för övervakning.
  • ProxyPolicy: Dirigerar begäranden via HTTP-proxyservrar när de konfigureras.
  • UserAgentPolicy: Lägger till SDK-versionsinformation i begärandehuvuden.

Beteende för återförsök

Azure SDK för Python implementerar intelligent omprövningslogik för att hantera tillfälliga fel automatiskt. Genom att förstå det här beteendet kan du skapa mer motståndskraftiga program.

Villkor som gjorts om automatiskt

SDK:et försöker skicka begäranden om dessa HTTP-statuskoder:

  • Tidsgräns för 408-begäran: Tidsgränsen för servern uppnåddes i väntan på begäran.
  • 429 För många begäranden: Hastighetsbegränsningen gäller.
  • 500 Internt serverfel: Tillfälligt serverproblem.
  • 502 Felaktig gateway: Tillfälligt nätverksproblem.
  • 503 Tjänsten är inte tillgänglig: Tjänsten är inte tillgänglig för tillfället.
  • 504 Gateway-timeout: Tidsgräns för gateway eller proxy.

Standardkonfiguration för återförsök

Standardinställningarna för återförsök ger en bra balans mellan motståndskraft och prestanda:

  • Maximalt antal återförsök: 3
  • Återförsöksläge: Exponentiell tillbakadragning
  • Basfördröjning: 0,8 sekunder
  • Maximal fördröjning: 60 sekunder
  • Maximal total återförsökstid: 120 sekunder

Exponentiell backoff-beräkningen följer det här mönstret:

delay = min(base_delay * (2 ** retry_attempt), max_delay)

Anpassa återförsök

Du kan anpassa återförsöksbeteendet när du skapar SDK-klienter för att matcha programmets specifika krav.

from azure.storage.blob import BlobServiceClient
from azure.core.pipeline.policies import RetryPolicy

# Custom retry configuration
retry_policy = RetryPolicy(
    retry_total=5,                    # Maximum number of retry attempts
    retry_backoff_factor=0.5,         # Base backoff time in seconds
    retry_backoff_max=120,            # Maximum backoff time in seconds
    retry_on_status_codes=[429, 500, 502, 503, 504]  # HTTP status codes to retry
)

# Apply custom retry policy to client
client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    retry_policy=retry_policy
)

Inaktivera återförsök

För scenarier där återförsök inte är lämpliga:

from azure.core.pipeline.policies import RetryPolicy

# Disable retries completely
no_retry_policy = RetryPolicy(retry_total=0)

client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    retry_policy=no_retry_policy
)

Diagnostisera och felsöka återförsöksbeteende

Att förstå när och varför återförsök inträffar är avgörande för att felsöka prestandaproblem.

Aktivera SDK-loggning

Azure SDK för Python använder Pythons standardloggningsramverk:

import logging
import sys

# Configure logging to see retry attempts
logging.basicConfig(
    level=logging.DEBUG,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    stream=sys.stdout
)

# Enable specific Azure SDK loggers
azure_logger = logging.getLogger('azure')
azure_logger.setLevel(logging.DEBUG)

# Now SDK operations will log retry attempts

Identifiera återförsöksmönster

Leta efter loggposter som:

Retry attempt 1 for request [GET] https://myaccount.blob.core.windows.net/container/blob
Waiting 0.8 seconds before retry

Vanliga fallgropar för återförsök

  • Försök igen med icke-tillfälliga fel: SDK:t försöker inte igen med klientfel (4xx) förutom 408 och 429.
  • Ignorerar svarstid för återförsök: Kom ihåg att återförsök lägger till svarstid för misslyckade åtgärder.
  • Ger otillräcklig tidsgräns: Se till att den totala tidsgränsen för åtgärden tar hänsyn till fördröjningar vid återförsök.

Avancerat: Lägga till anpassade principer

Du kan utöka pipelinen med anpassade principer för specialiserade scenarier.

Skapa en anpassad policy

from azure.core.pipeline import PipelineRequest, PipelineResponse
from azure.core.pipeline.policies import HTTPPolicy
from typing import Any, Optional

class CustomTelemetryPolicy(HTTPPolicy):
    """Custom policy to add telemetry headers"""
    
    def send(self, request: PipelineRequest) -> PipelineResponse:
        # Add custom header before sending request
        request.http_request.headers['X-Custom-Telemetry'] = 'my-app-v1.0'
        
        # Continue with the pipeline
        response = self.next.send(request)
        
        # Log response time
        print(f"Request to {request.http_request.url} completed")
        
        return response

Tillämpa anpassade principer

from azure.storage.blob import BlobServiceClient

# Create client with custom policy
client = BlobServiceClient(
    account_url="https://myaccount.blob.core.windows.net",
    credential=credential,
    per_call_policies=[CustomTelemetryPolicy()],  # Policies that run per request
    per_retry_policies=[]  # Policies that run per retry attempt
)

Principordning

Principer körs i en viss ordning:

  • Principer per anrop (körs en gång per åtgärd).
  • Återförsöksprincip.
  • Principer per återförsök (körs på varje försök).
  • Autentiseringsprincip.
  • HTTP-transport.

Metodtips

Använd standardinställningar när det är möjligt

Standardkonfigurationen för återförsök fungerar bra för de flesta scenarier. Anpassa endast när du har specifika krav.

Riktlinjer för anpassning

När du anpassar beteendet för återförsök:

  • Använd exponentiell backoff: Använd för att förhindra att tjänster överbelastas under återhämtning.
  • Ange rimliga gränser: Begränsa den totala återförsökstiden för att förhindra obestämd väntan.
  • Övervaka återförsöksmått: Spåra återförsöksfrekvensen i produktionen för att identifiera problem.
  • Överväg kretsbrytare: Implementera mönster för kretsbrytare i scenarier med hög volym.

Vad du inte ska försöka igen

Undvik att försöka igen med dessa typer av fel:

  • Autentiseringsfel (401, 403): Autentiseringsfel kräver att autentiseringsuppgifterna åtgärdas, inte försöker igen.
  • Klientfel (400, 404): Klientfel indikerar problem med själva begäran.
  • Affärslogikfel: Programspecifika fel som inte löses med återförsök.

Driftskvalitet

  • Loggkorrelations-ID:t: Inkludera x-ms-client-request-id i loggar för Azure-support.
  • Ange lämpliga tidsgränser: Balans mellan tillförlitlighet och användarupplevelse.
  • Testa beteende för återförsök: Kontrollera att programmet hanterar återförsök på ett korrekt sätt.
  • Övervaka prestanda: Spåra P95/P99-svarstider (percentilbaserade svarstidsmått) inklusive omprövningskostnader.

Relaterat innehåll

  • Uppdaterades senast