Partilhar via

Resiliência de componentes Dapr

  • Artigo

As políticas de resiliência previnem, detetam e recuperam proativamente as falhas do seu aplicativo de contêiner. Neste artigo, você aprenderá a aplicar políticas de resiliência para aplicativos que usam o Dapr para integração com diferentes serviços de nuvem, como repositórios de estado, corretores de mensagens pub/sub, repositórios secretos e muito mais.

Você pode configurar políticas de resiliência como tentativas, 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
    • Publicar uma mensagem
    • Invocando uma ligaçã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 que entregam 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 suportadas

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 antecipadamente operações de longa duração. A política de tempo limite inclui as seguintes propriedades.

properties: {
  outbound: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
    }
  }
  inbound: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
    }
  }
}
Metadados Necessário Description Exemplo
responseTimeoutInSeconds Sim Tempo limite aguardando uma resposta do componente Dapr. 15

Tentativas

Defina uma httpRetryPolicy estratégia 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 Necessário Description Exemplo
maxRetries Sim Máximo de tentativas 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/A
retryBackOff.initialDelayInMilliseconds Sim Atraso entre o primeiro erro e a primeira tentativa. 1000
retryBackOff.maxIntervalInMilliseconds Sim Atraso máximo entre tentativas. 10000

Disjuntores

Defina um circuitBreakerPolicy para monitorar 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 Necessário Description Exemplo
intervalInSeconds Não Período de tempo cíclico (em segundos) utilizado pelo disjuntor para limpar as suas contagens internas. Se não for fornecido, o intervalo é definido com o mesmo valor previsto para timeoutInSeconds. 15
consecutiveErrors Sim Número de erros de solicitação permitidos antes que o circuito tropece e abra. 10
timeoutInSeconds Sim Período de tempo (em segundos) de estado aberto, imediatamente 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 tropece e abra no meio do caminho.

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

  • 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 intervalInSeconds valor, o circuito será redefinido para um estado fechado após o período de tempo definido para timeoutInSeconds, independentemente do sucesso ou falha consecutiva da solicitação. Se você definir intervalInSeconds como 0, o circuito nunca será redefinido automaticamente, apenas passando do estado semiaberto para fechado ao concluir consecutiveErrors com êxito as solicitações seguidas.

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

Logs de resiliência

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

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

No painel Logs, escreva e execute uma consulta para encontrar resiliência por meio dos logs do sistema do aplicativo 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údos relacionados

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