Omówienie potoku HTTP i ponownych prób w zestawie Azure SDK dla języka Python

Jeśli wykonasz wywołanie dowolnej usługi platformy Azure przy użyciu zestawu Azure SDK dla języka Python, żądanie nie przechodzi bezpośrednio do usługi platformy Azure. Nie ma znaczenia, czy jest to usługa Azure Blob Storage, Azure Key Vault, Azure Cosmos DB, czy inna usługa oparta na protokole HTTP. Zamiast tego, żądanie przepływa przez zaawansowany mechanizm HTTP, który automatycznie obsługuje krytyczne aspekty przekrojowe.

Zrozumienie, jak działa potok HTTP, jest niezbędne do tworzenia niezawodnych, wydajnych aplikacji. Potok przetwarzania

Zarządza ponownymi próbami w przypadku przejściowych błędów.
Obsługuje uwierzytelnianie.
Zapewnia możliwości rejestrowania.
Umożliwia dodawanie zachowania niestandardowego w razie potrzeby.

Ta wiedza ułatwia debugowanie problemów z wydajnością, optymalizowanie odporności i dostosowywanie interakcji aplikacji z usługami platformy Azure.

Co to jest potok HTTP?

Zestaw Azure SDK dla języka Python używa wewnętrznej architektury potoku HTTP do przetwarzania wszystkich żądań i odpowiedzi. Ten potok przetwarzania składa się z serii polityk wykonywanych w sekwencji. Każda zasada jest odpowiedzialna za określony aspekt komunikacji HTTP. Potok można traktować jako łańcuch kroków przetwarzania:

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

Każda zasada w potoku może:

Zmodyfikuj żądanie przed wysłaniem.
Przetwórz odpowiedź po odebraniu.
Wykonaj akcje, takie jak ponawianie żądań, które zakończyły się niepowodzeniem.
Dodaj nagłówki, informacje dziennika lub zaimplementuj logikę niestandardową.

Kluczowe zasady w potoku

Zestaw Azure SDK dla języka Python zawiera kilka wbudowanych zasad, które obsługują typowe scenariusze:

RetryPolicy: Automatycznie ponawia próby żądań, które kończą się niepowodzeniem z powodu błędów przejściowych. Te zasady implementują inteligentną logikę ponawiania z wykładniczym wycofywaniem, aby uniknąć przeciążeń usług podczas przestojów.
BearerTokenCredentialPolicy: zarządza uwierzytelnianiem przez automatyczne uzyskiwanie i odświeżanie tokenów dostępu. Te zasady zapewniają, że żądania obejmują prawidłowe poświadczenia uwierzytelniania bez ręcznego zarządzania tokenami.
NetworkTraceLoggingPolicy: przechwytuje szczegółowe informacje o żądaniach HTTP i odpowiedziach na potrzeby debugowania. Te zasady są bezcenne podczas rozwiązywania problemów z komunikacją.
HttpTransport: najniższa warstwa pipeline'u, która faktycznie wysyła żądania HTTP za pośrednictwem sieci. W Azure SDK dla języka Python ta polityka jest najczęściej stosowana przy użyciu requests lub aiohttp dla operacji asynchronicznych.

Inne zasady

RedirectPolicy: automatycznie obsługuje przekierowania HTTP.
DistributedTracingPolicy: integruje się z rozproszonymi systemami śledzenia na potrzeby monitorowania.
ProxyPolicy: kieruje żądania za pośrednictwem serwerów proxy HTTP podczas konfigurowania.
UserAgentPolicy: dodaje informacje o wersji zestawu SDK do nagłówków żądań.

Zachowanie ponawiania prób

Zestaw Azure SDK dla języka Python implementuje inteligentną logikę ponawiania prób, aby automatycznie obsługiwać błędy przejściowe. Zrozumienie tego zachowania pomaga tworzyć bardziej odporne aplikacje.

Automatycznie ponawiane warunki

Zestaw SDK ponawia próby żądań dla tych kodów stanu HTTP:

408 Limit czasu żądania: upłynął limit czasu serwera oczekującego na żądanie.
429 Zbyt wiele żądań: ograniczanie szybkości jest w mocy.
500 Wewnętrzny błąd serwera: tymczasowy problem z serwerem.
502 Zła brama: Tymczasowy problem z siecią.
503 Usługa niedostępna: usługa jest tymczasowo niedostępna.
504 Przekroczenie limitu czasu bramy: przekroczenie limitu czasu bramy lub serwera proxy.

Domyślna konfiguracja ponawiania prób

Domyślne ustawienia ponawiania prób zapewniają dobrą równowagę między odpornością a wydajnością:

Maksymalna liczba ponownych prób: 3
Tryb ponawiania prób: wycofywanie wykładnicze
Opóźnienie podstawowe: 0,8 sekundy
Maksymalne opóźnienie: 60 sekund
Maksymalny całkowity czas ponawiania prób: 120 sekund

Obliczenie wycofywania wykładniczego jest zgodne z tym wzorcem:

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

Dostosuj ponowne próby

Zachowanie ponawiania prób można dostosować podczas tworzenia klientów zestawu SDK w celu dopasowania ich do określonych wymagań aplikacji.

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
)

Wyłącz ponowne próby

W przypadku scenariuszy, w których ponawianie prób nie jest odpowiednie:

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
)

Diagnozowanie i debugowanie zachowania ponawiania prób

Zrozumienie, kiedy i dlaczego występują ponowne próby, ma kluczowe znaczenie dla rozwiązywania problemów z wydajnością.

Włączanie rejestrowania zestawu SDK

Zestaw Azure SDK dla języka Python używa standardowej struktury rejestrowania języka Python:

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

Identyfikowanie wzorców ponawiania prób

Poszukaj wpisów dziennika, takich jak:

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

Typowe pułapki ponawiania prób

Ponawianie prób błędów nieprzejściowych: SDK nie ponawia prób dla błędów klientowskich (4xx) z wyjątkiem błędów 408 i 429.
Ignorowanie opóźnienia ponawiania prób: Pamiętaj, że ponowne próby dodają opóźnienie do operacji, które zakończyły się niepowodzeniem.
Zapewnianie niewystarczającego limitu czasu: Upewnij się, że ogólny limit czasu operacji uwzględnia opóźnienia przy ponawianiu prób.

Zaawansowane: Dodawanie zasad niestandardowych

Potok można rozszerzyć przy użyciu zasad niestandardowych dla wyspecjalizowanych scenariuszy.

Tworzenie zasad niestandardowych

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

Stosowanie zasad niestandardowych

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
)

Porządkowanie zasad

Zasady są wykonywane w określonej kolejności:

Zasady poszczególnych wywołań (wykonaj raz na operację).
Zasady ponawiania prób.
Zasady ponawiania prób (wykonaj przy każdej próbie).
Zasady uwierzytelniania.
Transport HTTP.

Najlepsze rozwiązania

Użyj ustawień domyślnych, jeśli to możliwe

Domyślna konfiguracja ponawiania prób działa dobrze w przypadku większości scenariuszy. Dostosuj tylko wtedy, gdy masz określone wymagania.

Wytyczne dotyczące dostosowywania

Podczas dostosowywania zachowania ponawiania prób:

Stosuj odstępy wykładnicze: aby zapobiec przeciążeniu usług podczas odzyskiwania.
Ustaw rozsądne limity: Limit łącznego czasu ponawiania prób, aby zapobiec oczekiwaniu na czas nieokreślony.
Monitorowanie metryk ponawiania prób: Śledzenie współczynników ponawiania prób w środowisku produkcyjnym w celu zidentyfikowania problemów.
Rozważ wyłączniki: Zastosuj wzorce obwodowych wyłączników dla scenariuszy o wysokim natężeniu.

Co nie ponawiać próby

Unikaj ponawiania prób tych typów błędów:

Błędy uwierzytelniania (401, 403): Błędy uwierzytelniania wymagają naprawienia poświadczeń, a nie ponawiania próby.
Błędy klienta (400, 404): Błędy klienta wskazują problemy z samym żądaniem.
Błędy logiki biznesowej: Błędy specyficzne dla aplikacji, które nie są rozwiązywane przy użyciu ponownych prób.

Doskonałość operacyjna

Identyfikatory korelacji dzienników: Uwzględnij x-ms-client-request-id w dziennikach pomocy technicznej platformy Azure.
Ustaw odpowiednie limity czasu: Równowaga między niezawodnością a środowiskiem użytkownika.
Zachowanie ponawiania prób testowych: Sprawdź, czy aplikacja obsługuje ponawianie prób w sposób bezproblemowy.
Monitorowanie wydajności: Śledź opóźnienia P95/P99 (metryki latencji oparte na percentylach), w tym koszty związane z ponawianiem prób.

Implementowanie odpornych aplikacji

Opinia

Czy ta strona była pomocna?

Ostatnia aktualizacja o 2025-12-09