Python için Azure SDK'sında HTTP işlem hattını ve yeniden denemeleri anlama

Python için Azure SDK'sını kullanarak herhangi bir Azure hizmetine çağrı yaptığınızda isteğiniz doğrudan Azure hizmetine gitmez. Azure Blob Depolama, Azure Key Vault, Azure Cosmos DB veya başka bir HTTP tabanlı hizmet olması fark etmez. Bunun yerine, isteğiniz kritik çapraz kesme sorunlarını otomatik olarak işleyen gelişmiş bir HTTP işlem hattı üzerinden akar.

HTTP işlem hattının nasıl çalıştığını anlamak, sağlam ve performanslı uygulamalar oluşturmak için gereklidir. İşlem hattı:

Geçici hatalar için yeniden denemeleri yönetir.
Kimlik doğrulamayı işler.
Günlüğe kaydetme özellikleri sağlar.
Gerektiğinde özel davranış eklemenize olanak tanır.

Bu bilgiler performans sorunlarını ayıklamanıza, dayanıklılığı iyileştirmenize ve uygulamanızın Azure hizmetleriyle etkileşimini özelleştirmenize yardımcı olur.

HTTP işlem hattı nedir?

Python için Azure SDK, tüm istekleri ve yanıtları işlemek için bir iç HTTP işlem hattı mimarisi kullanır. Bu işlem hattı, sırayla yürütülen bir dizi ilkeden oluşur. Her ilke, HTTP iletişiminin belirli bir özelliğinden sorumludur. İşlem hattını işleme adımları zinciri olarak düşünün:

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

İşlem hattındaki her ilke aşağıdakileri yapabilir:

İsteği gönderilmeden önce değiştirin.
Alındıktan sonra yanıtı işleyin.
Başarısız istekleri yeniden deneme gibi eylemler gerçekleştirin.
Başlıklar, günlük kaydı bilgilerini ekleyin veya özel mantık uygulayın.

İşlem hattındaki önemli ilkeler

Python için Azure SDK'sı, yaygın senaryoları işleyen çeşitli yerleşik ilkeler içerir:

RetryPolicy: Geçici hatalar nedeniyle başarısız olan istekleri otomatik olarak yeniden denenir. Bu ilke, kesintiler sırasında ağır hizmetlerden kaçınmak için üstel geri alma ile akıllı yeniden deneme mantığı uygular.
BearerTokenCredentialPolicy: Erişim belirteçlerini otomatik olarak alarak ve yenileyerek kimlik doğrulamasını yönetir. Bu politika, isteklerinizin el ile belirteç yönetimi olmadan geçerli kimlik doğrulama kimlik bilgilerini içermesini sağlar.
NetworkTraceLoggingPolicy: Hata ayıklama amacıyla HTTP istekleri ve yanıtları hakkında ayrıntılı bilgi yakalar. İletişim sorunlarını giderdiğinizde bu ilke çok değerlidir.
HttpTransport: İşlem hattının ağ üzerinden HTTP istekleri gönderen en düşük katmanıdır. Python için Azure SDK'da bu ilke genellikle istekler veya zaman uyumsuz işlemler için aiohttp kullanılarak uygulanır.

Diğer ilkeler

RedirectPolicy: HTTP yeniden yönlendirmelerini otomatik olarak işler.
DistributedTracingPolicy: İzleme için dağıtılmış izleme sistemleriyle tümleşir.
ProxyPolicy: Yapılandırıldığında http proxy'leri aracılığıyla istekleri yönlendirir.
UserAgentPolicy: İstek üst bilgilerine SDK sürüm bilgileri ekler.

Yeniden deneme davranışı

Python için Azure SDK, geçici hataları otomatik olarak işlemek için akıllı yeniden deneme mantığı uygular. Bu davranışı anlamak daha dayanıklı uygulamalar oluşturmanıza yardımcı olur.

Otomatik olarak yeniden denenen koşullar

SDK, şu HTTP durum kodları için istekleri yeniden denenir:

408 İstek Zaman Aşımı: Sunucu isteği beklerken zaman aşımına uğradı.
429 Çok Fazla İstek: Hız sınırlama etkin.
500 İç Sunucu Hatası: Geçici sunucu sorunu.
502 Hatalı Ağ Geçidi: Geçici ağ sorunu.
503 Hizmet Kullanılamıyor: Hizmet geçici olarak kullanılamıyor.
504 Ağ Geçidi Zaman Aşımı: Ağ geçidi veya ara sunucu zaman aşımı.

Varsayılan yeniden deneme yapılandırması

Varsayılan yeniden deneme ayarları dayanıklılık ve performans arasında iyi bir denge sağlar:

Yeniden deneme sayısı üst sınırı: 3
Yeniden deneme modu: Üstel geri alma
Temel gecikme: 0,8 saniye
Maksimum gecikme: 60 saniye
Toplam yeniden deneme süresi üst sınırı: 120 saniye

Üstel geri alma hesaplaması şu deseni izler:

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

Yeniden denemeleri özelleştirin

SDK istemcileri oluşturduğunuzda yeniden deneme davranışını uygulamanızın özel gereksinimlerine uyacak şekilde özelleştirebilirsiniz.

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
)

Yeniden denemeleri devre dışı bırak

Yeniden denemelerin uygun olmadığı senaryolar için:

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
)

Yeniden deneme davranışını tanılama ve hatalarını ayıklama

Yeniden denemelerin ne zaman ve neden gerçekleştiğini anlamak, performans sorunlarını gidermek için çok önemlidir.

SDK günlüğünü etkinleştirme

Python için Azure SDK, Python'ın standart günlük çerçevesini kullanır:

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

Yeniden deneme desenlerini tanımlama

Aşağıdaki gibi günlük girdilerini arayın:

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

Yaygın yeniden deneme tuzakları

Geçici olmayan hataları yeniden deneme: SDK, 408 ve 429 dışında istemci hatalarını (4xx) yeniden denemez.
Yeniden deneme gecikmesinin göz ardı edilmesi: Yeniden denemelerin başarısız işlemlere ekstra gecikme eklediğini unutmayın.
Yetersiz zaman aşımı sağlama: Genel işlem zaman aşımınızın yeniden deneme gecikmelerini de kapsadığından emin olun.

Gelişmiş: Özel ilkeler ekleme

özel senaryolar için işlem hattını özel ilkelerle genişletebilirsiniz.

Özel ilke oluşturma

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

Özel ilkeler uygulama

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
)

İlke sıralama

İlkeler belirli bir sırada yürütülür:

Her çağrı için ilkeler (her işlem için bir kez yürütülür).
Yeniden deneme politikası.
Her Deneme İçin İlkeler (her denemede uygula).
Kimlik doğrulama ilkesi.
HTTP aktarım.

En iyi yöntemler

Mümkün olduğunda varsayılan ayarları kullanın

Varsayılan yeniden deneme yapılandırması çoğu senaryoda düzgün çalışır. Yalnızca belirli gereksinimleriniz olduğunda özelleştirin.

Özelleştirme yönergeleri

Yeniden deneme davranışını özelleştirdiğinizde:

Üstel geri çekilme kullanın: Kurtarma sırasında hizmetlerin aşırı yüklenmesini önlemek için kullanın.
Makul sınırlar ayarlayın: Süresiz beklemeyi önlemek için toplam yeniden deneme süresini sınırla.
Yeniden deneme ölçümlerini izleyin: Sorunları belirlemek için üretimdeki yeniden deneme oranlarını izleyin.
Devre kesicileri göz önünde bulundurun: Yüksek hacimli senaryolar için devre kesici desenleri uygulayın.

Yeniden denenmemesi gerekenler

Bu tür hataları yeniden denemekten kaçının:

Kimlik doğrulama hataları (401, 403): Kimlik doğrulama hataları için kimlik bilgilerinin düzeltilmesi gerekir, yeniden denenmemesi gerekir.
İstemci hataları (400, 404): İstemci hataları, isteğin kendisiyle ilgili sorunları gösterir.
İş mantığı hataları: Yeniden denemelerle çözülmeyen uygulamaya özgü hatalar.

Operasyonel mükemmellik

Günlük bağıntı kimlikleri: Azure desteği için günlüklere ekleyin x-ms-client-request-id .
Uygun zaman aşımlarını ayarlayın: Güvenilirlik ve kullanıcı deneyimi arasında denge sağlar.
Yeniden deneme davranışını test edin: Uygulamanızın yeniden denemeleri düzgün bir şekilde işlediğini doğrulayın.
Performansı izleme: Yeniden deneme yükü de dahil olmak üzere P95/P99 gecikme sürelerini (yüzdebirlik tabanlı gecikme süresi ölçümleri) izleyin.

Dayanıklı uygulamalar geliştirme

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Son güncelleştirme: 2025-12-09