Resiliência do componente Dapr (visualização)
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.
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.
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.
Ou, você pode encontrar a política de resiliência real habilitando logs de depuração em seu aplicativo de contêiner e consultando para ver se um recurso de resiliência está carregado.
Depois que os logs de depuração estiverem habilitados, 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ú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