Dapr bileşeni dayanıklılığı (önizleme)
Dayanıklılık ilkeleri kapsayıcı uygulama hatalarınızı proaktif olarak önler, algılar ve kurtarır. Bu makalede, durum depoları, pub/alt ileti aracıları, gizli dizi depoları ve daha fazlası gibi farklı bulut hizmetleriyle tümleştirmek için Dapr kullanan uygulamalar için dayanıklılık ilkeleri uygulamayı öğreneceksiniz.
Bir Dapr bileşeni aracılığıyla aşağıdaki giden ve gelen işlem yönleri için yeniden denemeler, zaman aşımları ve devre kesiciler gibi dayanıklılık ilkelerini yapılandırabilirsiniz:
- Giden işlemler: Dapr sepetten bir bileşene yapılan çağrılar, örneğin:
- Durumu kalıcı hale getirme veya alma
- İleti yayımlama
- Çıkış bağlamasını çağırma
- Gelen işlemler: Dapr sepetten kapsayıcı uygulamanıza yapılan çağrılar, örneğin:
- İleti teslim ederken abonelikler
- Olay teslim eden giriş bağlamaları
Aşağıdaki ekran görüntüsünde, uygulamanın başarısız isteklerden kurtarmayı denemek için yeniden deneme ilkesini nasıl kullandığı gösterilmektedir.
Desteklenen dayanıklılık ilkeleri
Dayanıklılık ilkelerini yapılandırma
Bicep, CLI veya Azure portalını kullanarak dayanıklılık ilkeleri oluşturmayı seçebilirsiniz.
Aşağıdaki dayanıklılık örneği tüm kullanılabilir yapılandırmaları gösterir.
resource myPolicyDoc 'Microsoft.App/managedEnvironments/daprComponents/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-component-resiliency-policies'
parent: '${componentName}'
properties: {
outboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
inboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
}
Önemli
Tüm dayanıklılık ilkelerini uyguladıktan sonra Dapr uygulamalarınızı yeniden başlatmanız gerekir.
İlke belirtimleri
Zaman aşımları
Zaman aşımları, uzun süre çalışan işlemleri erken sonlandırmak için kullanılır. Zaman aşımı ilkesi aşağıdaki özellikleri içerir.
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
Meta veri | Zorunlu | Açıklama | Örnek |
---|---|---|---|
responseTimeoutInSeconds |
Yes | Dapr bileşeninden yanıt beklerken zaman aşımı. | 15 |
Yeniden deneme sayısı
Başarısız işlemler için bir httpRetryPolicy
strateji tanımlayın. Yeniden deneme ilkesi aşağıdaki yapılandırmaları içerir.
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
Meta veri | Zorunlu | Açıklama | Örnek |
---|---|---|---|
maxRetries |
Yes | Başarısız bir http isteği için yürütülecek en fazla yeniden deneme sayısı. | 5 |
retryBackOff |
Yes | İstekleri izleyin ve zaman aşımı ve yeniden deneme ölçütleri karşılandığında etkilenen hizmete yönelik tüm trafiği kapatın. | YOK |
retryBackOff.initialDelayInMilliseconds |
Evet | İlk hata ile ilk yeniden deneme arasındaki gecikme. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Yes | Yeniden denemeler arasındaki en uzun gecikme. | 10000 |
Devre kesiciler
Yükseltilmiş hata oranlarına neden olan istekleri izlemek için bir circuitBreakerPolicy
tanımlayın ve belirli bir ölçüt karşılandığında etkilenen hizmete yönelik tüm trafiği kapatın.
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
Meta veri | Zorunlu | Açıklama | Örnek |
---|---|---|---|
intervalInSeconds |
Hayır | Devre kesici tarafından iç sayılarını temizlemek için kullanılan döngüsel süre (saniye cinsinden). Sağlanmadıysa, aralık için timeoutInSeconds sağlanan değerle aynı değere ayarlanır. |
15 |
consecutiveErrors |
Yes | Bağlantı hattı açılmadan önce oluşmasına izin verilen istek hatalarının sayısı. | 10 |
timeoutInSeconds |
Yes | Hatadan hemen sonra açık durumdaki zaman aralığı (saniye cinsinden). | 5 |
Devre kesici işlemi
Belirterek consecutiveErrors
(bağlantı hattı dönüş koşulu olarak consecutiveFailures > $(consecutiveErrors)-1
) devre dönüşlerinden önce oluşmasına izin verilen hata sayısını ayarlar ve yarı yarıya açılır.
Devre, consecutiveErrors
istek sayısının art arda başarılı olması gereken süre boyunca timeoutInSeconds
yarı açık bekler.
- İstekler başarılı olursa devre kapanır.
- İstekler başarısız olursa devre yarı açık durumda kalır.
Herhangi bir intervalInSeconds
değer ayarlamadıysanız, ardışık istek başarısına veya başarısızlığına bakılmaksızın bağlantı hattı için timeoutInSeconds
ayarladığınız sürenin sonunda kapalı duruma sıfırlanır. olarak 0
ayarlarsanızintervalInSeconds
, devre hiçbir zaman otomatik olarak sıfırlanmaz, yalnızca istekleri bir satırda başarıyla tamamlayarak yarı açık durumdan consecutiveErrors
kapalı duruma geçebilirsiniz.
Bir intervalInSeconds
değer ayarladıysanız, devrenin kapalı duruma sıfırlanmadan önce geçmesi gereken süreyi, yarı açık durumda gönderilen isteklerin başarılı olup olmadığından bağımsız olarak belirler.
Dayanıklılık günlükleri
Kapsayıcı uygulamanızın İzleme bölümünde Günlükler'i seçin.
Günlükler bölmesinde, kapsayıcı uygulama sistemi günlükleriniz aracılığıyla dayanıklılığı bulmak için bir sorgu yazın ve çalıştırın. Örneğin, dayanıklılık ilkesinin yüklenip yüklenmediğini bulmak için:
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Loading Resiliency configuration:"
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
Sorguyu çalıştırmak ve ilkenin yüklendiğini belirten günlük iletisiyle sonucu görüntülemek için Çalıştır'a tıklayın.
Alternatif olarak, kapsayıcı uygulamanızda hata ayıklama günlüklerini etkinleştirerek ve bir dayanıklılık kaynağının yüklenip yüklenmediğini görmek için sorgulayarak gerçek dayanıklılık ilkesini bulabilirsiniz.
Hata ayıklama günlükleri etkinleştirildikten sonra aşağıdakine benzer bir sorgu kullanın:
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Resiliency configuration ("
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
Sorguyu çalıştırmak ve sonuçta elde edilen günlük iletisini ilke yapılandırmasıyla görüntülemek için Çalıştır'a tıklayın.
İlgili içerik
Azure Container Apps yerleşik hizmet bulma kullanarak hizmet iletişiminde dayanıklılığın nasıl çalıştığını görün