Resilienza del componente Dapr (anteprima)
I criteri di resilienza impediscono, rilevano e ripristinano in modo proattivo dagli errori dell'app contenitore. Questo articolo illustra come applicare criteri di resilienza per le applicazioni che usano Dapr per l'integrazione con servizi cloud diversi, ad esempio archivi di stato, broker di messaggi pub/sub, archivi di segreti e altro ancora.
È possibile configurare criteri di resilienza come tentativi, timeout e interruttori di circuito per le seguenti direzioni delle operazioni in uscita e in ingresso tramite un componente Dapr:
- Operazioni in uscita: chiamate dal sidecar Dapr a un componente, ad esempio:
- Salvataggio permanente o recupero dello stato
- Pubblicazione di un messaggio
- Chiamata di un'associazione di output
- Operazioni in ingresso: chiamate dal sidecar Dapr all'app contenitore, ad esempio:
- Sottoscrizioni durante il recapito di un messaggio
- Associazioni di input che recapitano un evento
Lo screenshot seguente mostra come un'applicazione usa un criterio di ripetizione per tentare di eseguire il ripristino da richieste non riuscite.
Criteri di resilienza supportati
Configurare i criteri di resilienza
È possibile scegliere se creare criteri di resilienza usando Bicep, l'interfaccia della riga di comando o il portale di Azure.
L'esempio di resilienza seguente illustra tutte le configurazioni disponibili.
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
}
}
}
}
Importante
Dopo aver applicato tutti i criteri di resilienza, è necessario riavviare le applicazioni Dapr.
Specifiche dei criteri
Timeout
I timeout vengono usati per le operazioni con esecuzione prolungata anticipata. I criteri di timeout includono le proprietà seguenti.
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
| Metadati UFX | Obbligatorio | Descrizione | Esempio |
|---|---|---|---|
responseTimeoutInSeconds |
Sì | Timeout in attesa di una risposta dal componente Dapr. | 15 |
Nuovi tentativi
Definire una strategia di httpRetryPolicy per le operazioni non riuscite. I criteri di ripetizione includono le configurazioni seguenti.
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
| Metadati UFX | Obbligatorio | Descrizione | Esempio |
|---|---|---|---|
maxRetries |
Sì | Numero massimo di tentativi da eseguire per una richiesta HTTP non riuscita. | 5 |
retryBackOff |
Sì | Monitorare le richieste e arrestare tutto il traffico verso il servizio interessato quando vengono soddisfatti i criteri di timeout e ripetizione dei tentativi. | N/D |
retryBackOff.initialDelayInMilliseconds |
Sì | Ritardo tra il primo errore e il primo tentativo. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
Sì | Ritardo massimo tra i tentativi. | 10000 |
Interruttori
Definire un circuitBreakerPolicy per monitorare le richieste che causano tassi di errore elevati e arrestare tutto il traffico verso il servizio interessato quando viene soddisfatto un determinato criterio.
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
| Metadati UFX | Obbligatorio | Descrizione | Esempio |
|---|---|---|---|
intervalInSeconds |
No | Periodo ciclico di tempo (in secondi) usato dall'interruttore per cancellare i conteggi interni. Se non specificato, l'intervallo viene impostato sullo stesso valore specificato per timeoutInSeconds. |
15 |
consecutiveErrors |
Sì | Numero di errori di richiesta che possono verificarsi prima del trip e dell'apertura del circuito. | 10 |
timeoutInSeconds |
Sì | Periodo di tempo (in secondi) di stato aperto, direttamente dopo l'errore. | 5 |
Processo interruttore
Specificando consecutiveErrors (la condizione trip del circuito come consecutiveFailures > $(consecutiveErrors)-1) si imposta il numero di errori consentiti prima dei trip e dell'apertura a metà del circuito.
Il circuito attende aperto a metà per il periodo di tempo timeoutInSeconds, durante il quale il numero consecutiveErrors di richieste deve avere esito positivo consecutivamente.
- Se le richieste hanno esito positivo, il circuito si chiude.
- Se le richieste hanno esito negativo, il circuito rimane in uno stato semi-aperto.
Se non è stato impostato alcun valore intervalInSeconds, il circuito viene reimpostato su uno stato chiuso dopo l'intervallo di tempo impostato per timeoutInSeconds, indipendentemente dall'esito positivo o negativo della richiesta consecutiva. Se si imposta intervalInSeconds su 0, il circuito non viene mai reimpostato automaticamente, ma passa solo da uno stato chiuso a metà aperto completando correttamente consecutiveErrors richieste in una riga.
Se è stato impostato un valore di intervalInSeconds, che determina l'intervallo di tempo prima che il circuito venga reimpostato sullo stato chiuso, indipendentemente dal fatto che le richieste inviate in uno stato semi-aperto abbiano avuto esito positivo o negativo.
Log di resilienza
Nella sezione Monitoraggio dell'app contenitore selezionare Log.
Nel riquadro Log scrivere ed eseguire una query per trovare la resilienza tramite i log di sistema dell'app contenitore. Ad esempio, per determinare se è stato caricato un criterio di resilienza:
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
Fare clic su Esegui per eseguire la query e visualizzare il risultato con il messaggio di log che indica che il criterio è in fase di caricamento.
In alternativa, è possibile trovare i criteri di resilienza effettivi abilitando i log di debug nell'app contenitore ed eseguendo query per verificare se viene caricata una risorsa di resilienza.
Dopo aver abilitato i log di debug, usare una query simile alla seguente:
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
Fare clic su Esegui per eseguire la query e visualizzare il messaggio di log risultante con la configurazione dei criteri.
Contenuto correlato
Informazioni sul funzionamento della resilienza per la Comunicazione da servizio a servizio tramite App contenitore di Azure integrate nell'individuazione dei servizi