Resiliência do componente Dapr (visualização)
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.
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.
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.
Ou encontre a política de resiliência real habilitando logs de depuração no aplicativo de contêiner e consultando para visualizar se um recurso de resiliência está carregado.
Após habilitar os logs de depuração, use uma consulta semelhante à seguinte:
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.
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