Resilienza del componente Dapr (anteprima)

Le politiche di resilienza consentono di prevenire, rilevare e ripristinare in modo proattivo da eventuali 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 nuovi tentativi, timeout e interruttori per le seguenti operazioni in uscita e in ingresso usando un componente Dapr.

Operazioni in uscita: chiamate da un sidecar Dapr a un componente, ad esempio:
- Permanenza o recupero dello stato
- Pubblicazione di un messaggio
- Richiamo di un'associazione di output
Operazioni in ingresso: chiamate dal sidecar Dapr all'app contenitore, ad esempio:
- Sottoscrizioni quando si recapita un messaggio
- Associazioni di input che generano un evento

Lo screenshot seguente mostra come un'applicazione usa un criterio di ripetizione per tentare di eseguire il ripristino da richieste non riuscite.

Configurare i criteri di resilienza

È possibile scegliere se creare criteri di resilienza usando Bicep, l'interfaccia della riga di comando di Azure 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     
      }  
    }
  }
}

Operazioni preliminari

Accedi all'Azure CLI.

az login

Assicurarsi di avere la versione più recente dell'estensione app Azure Container.

az extension show --name containerapp
az extension update --name containerapp

Creare criteri specifici

Nota

Se tutte le proprietà all'interno di un criterio non vengono impostate durante la creazione o l'aggiornamento, l'interfaccia della riga di comando applica automaticamente le impostazioni predefinite consigliate. Per informazioni su come impostare criteri specifici usando i flag, vedere Creare criteri specifici.

Creare criteri di resilienza specificando come destinazione un singolo criterio. Ad esempio, per creare il criterio Outbound Timeout, eseguire il comando seguente.

az containerapp env dapr-component resiliency create --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --out-timeout 20

Per un elenco completo dei parametri, vedere la guida di riferimento all'interfaccia della riga di comando.

Creare policy con resilienza tramite YAML

Per applicare i criteri di resilienza da un file YAML, eseguire il comando seguente:

az containerapp env dapr-component resiliency create --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --yaml <your-YAML-file>

Questo comando passa il file YAML dei criteri di resilienza, che potrebbe essere simile all'esempio seguente:

outboundPolicy:
  httpRetryPolicy:
    maxRetries: 5
    retryBackOff:
      initialDelayInMilliseconds: 1000
      maxIntervalInMilliseconds: 10000
  timeoutPolicy:
    responseTimeoutInSeconds: 15
  circuitBreakerPolicy:
    intervalInSeconds: 15
    consecutiveErrors: 10
    timeoutInSeconds: 5
inboundPolicy:
  httpRetryPolicy:
    maxRetries: 3
    retryBackOff:
      initialDelayInMilliseconds: 500
      maxIntervalInMilliseconds: 5000
  circuitBreakerPolicy:
    intervalInSeconds: 15
    consecutiveErrors: 10
    timeoutInSeconds: 5

Aggiornare criteri specifici

Aggiornare i criteri di resilienza specificando come destinazione un singolo criterio. Ad esempio, per aggiornare il timeout di risposta del criterio di Outbound Timeout, eseguire il comando seguente.

az containerapp env dapr-component resiliency update --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --out-timeout 20

Aggiornare le policy con YAML di resilienza

È anche possibile aggiornare i criteri di resilienza esistenti aggiornando il file YAML di resilienza creato in precedenza.

az containerapp env dapr-component resiliency update --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component> --yaml <your-YAML-file>

Visualizza le politiche

Usare il comando resiliency list per elencare tutti i criteri di resilienza associati a un'app contenitore.

az containerapp env dapr-component resiliency list --group <your-resource-group> --environment <your-environment> --dapr-component-name <your-component>

Usare il comando resiliency show per visualizzare un singolo criterio tramite nome.

az containerapp env dapr-component resiliency show --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component>

Eliminare le politiche

Per eliminare i criteri di resilienza, eseguire il comando seguente.

az containerapp env dapr-component resiliency delete --group <your-resource-group> --name <your-resiliency-name> --environment <your-environment> --dapr-component-name <your-component>

Importante

Dopo aver applicato tutti i criteri di resilienza, è necessario riavviare le applicazioni Dapr.

Specifiche delle politiche

Timeout

I timeout vengono utilizzati per terminare anticipatamente operazioni a lunga durata. I criteri di timeout includono le proprietà seguenti.

properties: {
  outbound: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
    }
  }
  inbound: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
    }
  }
}

Metadati	Obbligatorio	Descrizione	Esempio
`responseTimeoutInSeconds`	Sì	Timeout in attesa di una risposta dal componente Dapr.	`15`

Tentativi

Definire una strategia di httpRetryPolicy per le operazioni non riuscite. La politica di ripetizione include le seguenti configurazioni.

properties: {
  outbound: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
    }
  }
  inbound: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
    }
  } 
}

Metadati	Obbligatorio	Descrizione	Esempio
`maxRetries`	Sì	Numero massimo di tentativi da eseguire per una richiesta HTTP non riuscita.	`5`
`retryBackOff`	Sì	Monitora le richieste e arresta tutto il traffico verso il servizio interessato quando vengono soddisfatti i criteri di timeout e ripetizione dei tentativi.	Non Disponibile
`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	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 delle richieste consentiti prima che il circuito si attivi e si apra.	`10`
`timeoutInSeconds`	Sì	Periodo di tempo (in secondi) di stato aperto, direttamente dopo l'errore.	`5`

Processo dell'interruttore automatico

Se si specifica consecutiveErrors (la condizione di attivazione del circuito come consecutiveFailures > $(consecutiveErrors)-1), si imposta il numero di errori consentiti prima che il circuito si attivi e si apra a metà.

Il circuito attende in stato semi-aperto per il periodo di tempo definito da timeoutInSeconds, durante il quale il numero di richieste consecutiveErrors 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, passando solo da semi-aperto a chiuso completando consecutiveErrors richieste consecutivamente.

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.

Registri di resilienza

Nella sezione Monitoraggio dell'app contenitore selezionare Log.

Screenshot che illustra dove trovare i log per l'app contenitore usando la resilienza dei componenti Dapr.

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

Selezionare Esegui per eseguire la query e visualizzare il risultato con il messaggio di log che indica che il criterio è in fase di caricamento.

È anche 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

Selezionare Esegui per eseguire la query e visualizzare il messaggio di log risultante con la configurazione dei criteri.

Resilienza dell'individuazione dei servizi (anteprima)

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-02-19