Compartilhar via

Resiliência do componente Dapr

  • Artigo

As políticas de resiliência previnem, detectam e recuperam proativamente falhas no aplicativo de contêiner. Neste artigo, você aprenderá a aplicar políticas de resiliência para aplicativos que usam o Dapr para se integrar a diferentes serviços de nuvem, como repositórios de estado, agentes de mensagens pub/sub, repositórios secretos e muito mais.

Você pode configurar políticas de resiliência como repetições, tempos limite e disjuntores para as seguintes direções de operação de entrada e saída por meio de um componente Dapr:

  • Operações de saída: chamadas do sidecar Dapr para um componente, como:
    • Estado persistente ou de recuperação
    • Publicando uma mensagem
    • Invocando uma vinculação de saída
  • Operações de entrada: chamadas do sidecar Dapr para seu aplicativo de contêiner, como:
    • Subscrições ao entregar uma mensagem
    • Ligações de entrada entregando um evento

A captura de tela a seguir mostra como um aplicativo usa uma política de repetição para tentar se recuperar de solicitações com falha.

Diagrama demonstrando resiliência para aplicativos de contêiner com componentes Dapr.

Políticas de resiliência com suporte

Configurar políticas de resiliência

Você pode escolher se deseja criar políticas de resiliência usando o Bicep, a CLI ou o portal do Azure.

O exemplo de resiliência a seguir demonstra todas as configurações disponíveis.

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

Depois de aplicar todas as políticas de resiliência, você precisa reiniciar seus aplicativos Dapr.

Especificações da política

Tempos limite

Os tempos limite são usados para encerrar operações de execução longa antecipada. A política de tempo limite inclui as propriedades a seguir.

properties: {
  outbound: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
    }
  }
  inbound: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
    }
  }
}
Metadados Obrigatório Descrição Exemplo
responseTimeoutInSeconds Sim Tempo limite aguardando uma resposta do componente Dapr. 15

Repetições

Defina uma estratégia httpRetryPolicy para operações com falha. A política de repetição inclui as seguintes configurações.

properties: {
  outbound: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
    }
  }
  inbound: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
    }
  } 
}
Metadados Obrigatório Descrição Exemplo
maxRetries Sim Repetições máximas a serem executadas para uma solicitação http com falha. 5
retryBackOff Sim Monitore as solicitações e desligue todo o tráfego para o serviço afetado quando os critérios de tempo limite e repetição forem atendidos. N/D
retryBackOff.initialDelayInMilliseconds Sim Atraso entre o primeiro erro e a primeira repetição. 1000
retryBackOff.maxIntervalInMilliseconds Sim Atraso máximo entre as repetições. 10000

Disjuntores

Defina um circuitBreakerPolicy para monitorar as solicitações que causam taxas de falha elevadas e desligue todo o tráfego para o serviço afetado quando um determinado critério for atendido.

properties: {  
  outbound: {  
    circuitBreakerPolicy: {  
        intervalInSeconds: 15
        consecutiveErrors: 10
        timeoutInSeconds: 5     
    }  
  },  
  inbound: {  
    circuitBreakerPolicy: {  
        intervalInSeconds: 15
        consecutiveErrors: 10
        timeoutInSeconds: 5     
    }  
  }  
}
Metadados Obrigatório Descrição Exemplo
intervalInSeconds Não Período cíclico de tempo (em segundos) usado pelo disjuntor para limpar suas contagens internas. Se não for fornecido, o intervalo será definido como o mesmo valor fornecido para timeoutInSeconds. 15
consecutiveErrors Sim Número de erros de solicitação permitidos antes de o circuito disparar e abrir. 10
timeoutInSeconds Sim Período de tempo (em segundos) de estado aberto, diretamente após a falha. 5

Processo do disjuntor

Especificar consecutiveErrors (a condição de disparo do circuito como consecutiveFailures > $(consecutiveErrors)-1) define o número de erros permitidos antes que o circuito dispare e abra pela metade.

O circuito aguarda semiaberto pelo período de tempo de timeoutInSeconds durante o qual o número de consecutiveErrors de solicitações deve ser consecutivamente bem-sucedido.

  • Se as solicitações forem bem-sucedidas, o circuito será fechado.
  • Se as solicitações falharem, o circuito permanecerá em um estado semiaberto.

Se você não definiu nenhum valor intervalInSeconds, o circuito será redefinido para um estado fechado após o tempo definido para timeoutInSeconds, independentemente de sucesso ou falha da solicitação consecutiva. Se você definir intervalInSeconds como 0, o circuito nunca será redefinido automaticamente, passando do estado semiaberto para o estado fechado somente se as solicitações de consecutiveErrors forem concluídas com sucesso em uma linha.

Se você definiu um valor de intervalInSeconds, que determina a quantidade de tempo antes que o circuito seja redefinido para o estado fechado, independentemente de as solicitações enviadas em estado semiaberto terem sido bem-sucedidas ou não.

Logs de resiliência

Na seção Monitoramento do aplicativo de contêiner, selecione Logs.

Captura de tela demonstrando onde encontrar os logs para seu aplicativo de contêiner usando resiliência de componente Dapr.

No painel Logs, grave e execute uma consulta para localizar resiliência por meio dos logs do sistema do aplicativo de contêiner. Por exemplo, para descobrir se uma política de resiliência foi carregada:

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

Clique em Executar para executar a consulta e exibir o resultado com a mensagem de log indicando que a política está sendo carregada.

Captura de tela mostrando os resultados da consulta de resiliência com base no exemplo de consulta fornecido para verificar se a política de resiliência foi carregada.

Ou, você pode encontrar a política de resiliência real habilitando a depuração em seu componente e usando uma consulta semelhante ao exemplo a seguir:

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

Clique em Executar para executar a consulta e exibir a mensagem de log resultante com a configuração da política.

Captura de tela mostrando os resultados da consulta de resiliência com base no exemplo de consulta fornecido para localizar a política de resiliência real.

Conteúdo relacionado

Veja como a resiliência funciona para Comunicação de serviço a serviço usando os Aplicativos de Contêiner do Azure internos na descoberta de serviço