Odporność składników języka Dapr
Zasady odporności proaktywnie zapobiegają awariom aplikacji kontenera, wykrywają je i odzyskują. Z tego artykułu dowiesz się, jak zastosować zasady odporności dla aplikacji korzystających z języka Dapr do integracji z różnymi usługami w chmurze, takimi jak magazyny stanów, brokerzy komunikatów pub/sub, magazyny wpisów tajnych i inne.
Zasady odporności, takie jak ponawianie prób, przekroczenia limitu czasu i wyłączniki, można skonfigurować dla następujących wskazówek dotyczących ruchu wychodzącego i przychodzącego za pośrednictwem składnika Języka Dapr:
- Operacje ruchu wychodzącego: wywołania z przyczepki dapr do składnika, na przykład:
- Stan utrwalania lub pobierania
- Publikowanie komunikatu
- Wywoływanie powiązania wyjściowego
- Operacje przychodzące: wywołania z przyczepki dapr do aplikacji kontenera, takie jak:
- Subskrypcje podczas dostarczania komunikatu
- Powiązania wejściowe dostarczające zdarzenie
Poniższy zrzut ekranu przedstawia sposób, w jaki aplikacja używa zasad ponawiania prób odzyskania po żądaniach, które zakończyły się niepowodzeniem.
Obsługiwane zasady odporności
Konfigurowanie zasad odporności
Możesz wybrać, czy chcesz utworzyć zasady odporności przy użyciu aplikacji Bicep, interfejsu wiersza polecenia lub witryny Azure Portal.
Poniższy przykład odporności przedstawia wszystkie dostępne konfiguracje.
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
}
}
}
}
Ważne
Po zastosowaniu wszystkich zasad odporności należy ponownie uruchomić aplikacje Dapr.
Specyfikacje zasad
Limity czasu
Limity czasu są używane do wczesnego zakończenia długotrwałych operacji. Zasady limitu czasu zawierają następujące właściwości.
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
| Metadane | Wymagania | opis | Przykład |
|---|---|---|---|
responseTimeoutInSeconds |
Tak | Limit czasu oczekiwania na odpowiedź ze składnika Dapr. | 15 |
Ponowne próby
Zdefiniuj strategię dla operacji, które zakończyły się niepowodzeniem httpRetryPolicy . Zasady ponawiania prób obejmują następujące konfiguracje.
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
| Metadane | Wymagania | opis | Przykład |
|---|---|---|---|
maxRetries |
Tak | Maksymalna liczba ponownych prób do wykonania dla nieudanego żądania HTTP. | 5 |
retryBackOff |
Tak | Monitoruj żądania i wyłącza cały ruch do usługi, której dotyczy ten wpływ, po przekroczeniu limitu czasu i spełnieniu kryteriów ponawiania prób. | Nie dotyczy |
retryBackOff.initialDelayInMilliseconds |
Tak | Opóźnienie między pierwszym błędem a pierwszą ponowną próbą. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Tak | Maksymalne opóźnienie między ponownych prób. | 10000 |
Wyłączniki
Zdefiniuj element , circuitBreakerPolicy aby monitorować żądania powodujące podwyższony poziom liczby niepowodzeń i wyłączyć cały ruch do usługi, której dotyczy problem, gdy zostaną spełnione określone kryteria.
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
| Metadane | Wymagania | opis | Przykład |
|---|---|---|---|
intervalInSeconds |
Nie. | Cykliczny okres czasu (w sekundach) używany przez wyłącznik w celu wyczyszczenia liczby wewnętrznych. Jeśli nie zostanie podana, interwał zostanie ustawiony na tę samą wartość, co podana dla elementu timeoutInSeconds. |
15 |
consecutiveErrors |
Tak | Liczba błędów żądań, które mogą wystąpić przed rozpoczęciem i otwarciem obwodu. | 10 |
timeoutInSeconds |
Tak | Czas (w sekundach) stanu otwarcia bezpośrednio po awarii. | 5 |
Proces wyłącznika
Określenie consecutiveErrors (warunek podróży obwodu jako consecutiveFailures > $(consecutiveErrors)-1) określa liczbę błędów, które mogą wystąpić przed przejazdami obwodu i otwiera się w połowie drogi.
Obwód czeka na pół otwarcia przez timeoutInSeconds czas, w którym consecutiveErrors liczba żądań musi pomyślnie zakończyć się powodzeniem.
- Jeśli żądania zakończą się pomyślnie, obwód zostanie zamknięty.
- Jeśli żądania kończą się niepowodzeniem, obwód pozostaje w stanie półwartym.
Jeśli nie ustawiono żadnej intervalInSeconds wartości, obwód zostanie zresetowany do stanu zamkniętego po upływie ustawionego czasu dla timeoutInSeconds, niezależnie od kolejnych pomyślnych żądań lub niepowodzeń. Jeśli ustawiono wartość intervalInSeconds 0, obwód nigdy nie zostanie automatycznie zresetowany, tylko przejście z połowy do stanu zamkniętego przez pomyślne ukończenie żądań consecutiveErrors z wiersza.
Jeśli wartość została ustawiona intervalInSeconds , określa czas, po którym obwód zostanie zresetowany do stanu zamkniętego, niezależnie od tego, czy żądania wysyłane w stanie połowy otwarcia zakończyły się powodzeniem, czy nie.
Dzienniki odporności
W sekcji Monitorowanie aplikacji kontenera wybierz pozycję Dzienniki.
W okienku Dzienniki napisz i uruchom zapytanie, aby znaleźć odporność za pośrednictwem dzienników systemu aplikacji kontenera. Aby na przykład sprawdzić, czy zostały załadowane zasady odporności:
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
Kliknij przycisk Uruchom , aby uruchomić zapytanie i wyświetlić wynik z komunikatem dziennika wskazującym, że zasady są ładowane.
Możesz też znaleźć rzeczywiste zasady odporności, włączając debugowanie składnika i używając zapytania podobnego do poniższego przykładu:
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
Kliknij przycisk Uruchom , aby uruchomić zapytanie i wyświetlić wynikowy komunikat dziennika z konfiguracją zasad.
Powiązana zawartość
Zobacz, jak działa odporność na potrzeby komunikacji między usługami przy użyciu usługi Azure Container Apps wbudowanej w odnajdywanie usług