Share via


Resilienza del componente Dapr (anteprima)

I criteri di resilienza impediscono, rilevano e ripristinano in modo proattivo gli 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 segreti e altro ancora.

È possibile configurare criteri di resilienza come tentativi e timeout 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 dei tentativi per tentare di eseguire il ripristino da richieste non riuscite.

Diagram demonstrating resiliency for container apps with Dapr components.

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-08-01-preview' = {
  name: 'my-component-resiliency-policies'
  parent: '${componentName}'
  properties: {
    outboundPolicy: {
      timeoutPolicy: {
          responseTimeoutInSeconds: 15
      }
      httpRetryPolicy: {
          maxRetries: 5
          retryBackOff: {
            initialDelayInMilliseconds: 1000
            maxIntervalInMilliseconds: 10000
          }
      } 
    } 
    inboundPolicy: {
      timeoutPolicy: {
        responseTimeoutInSeconds: 15
      }
      httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
      } 
    }
  }
}

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 Richiesto Descrizione Esempio
responseTimeoutInSeconds Timeout in attesa di una risposta dal componente Dapr. 15

Nuovi tentativi

Definire una httpRetryPolicy strategia per le operazioni non riuscite. I criteri di ripetizione dei tentativi 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 Richiesto Descrizione Esempio
maxRetries Numero massimo di tentativi da eseguire per una richiesta HTTP non riuscita. 5
retryBackOff 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 Ritardo tra il primo errore e il primo tentativo. 1000
retryBackOff.maxIntervalInMilliseconds Ritardo massimo tra i tentativi. 10000

Log di resilienza

Nella sezione Monitoraggio dell'app contenitore selezionare Log.

Screenshot demonstrating where to find the logs for your container app using Dapr component resiliency.

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.

Screenshot showing resiliency query results based on provided query example for checking if resiliency policy has loaded.

In alternativa, è possibile trovare i criteri di resilienza effettivi abilitando il debug sul componente e usando una query simile all'esempio 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.

Screenshot showing resiliency query results based on provided query example for finding the actual resiliency policy.

Informazioni sul funzionamento della resilienza per la comunicazione da servizio a servizio con App Contenitore di Azure integrate nell'individuazione dei servizi