Share via

Resiliência da descoberta de serviço (visualização)

  • Artigo

Com a resiliência dos Aplicativos de Contêiner do Azure, você pode prevenir, detetar e recuperar proativamente falhas de solicitação de serviço usando políticas de resiliência simples. Neste artigo, você aprenderá a configurar políticas de resiliência de Aplicativos de Contêiner do Azure ao iniciar solicitações usando a descoberta de serviço de Aplicativos de Contêiner do Azure.

Nota

Atualmente, as políticas de resiliência não podem ser aplicadas a solicitações feitas usando a API de Invocação de Serviço Dapr.

As políticas estão em vigor para cada solicitação a um aplicativo de contêiner. Você pode adaptar as políticas ao aplicativo contêiner aceitando solicitações com configurações como:

  • O número de novas tentativas
  • Duração da repetição e do tempo limite
  • Repetir correspondências
  • Erros consecutivos do disjuntor, entre outros

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.

Diagram demonstrating container app to container app resiliency using a container app's service name.

Políticas de resiliência suportadas

Configurar políticas de resiliência

Quer configure políticas de resiliência utilizando o Bicep, a CLI ou o portal do Azure, só pode aplicar uma política por aplicação de contentor.

Quando você aplica uma política a um aplicativo de contêiner, as regras são aplicadas a todas as solicitações feitas a esse aplicativo de contêiner, não a solicitações feitas a partir desse aplicativo de contêiner. Por exemplo, uma política de repetição é aplicada a um aplicativo de contêiner chamado App B. Todas as solicitações de entrada feitas ao Aplicativo B são repetidas automaticamente em caso de falha. No entanto, não é garantido que as solicitações de saída enviadas pelo aplicativo B tentem novamente em caso de falha.

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

resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
  name: 'my-app-resiliency-policies'
  parent: '${appName}'
  properties: {
    timeoutPolicy: {
        responseTimeoutInSeconds: 15
        connectionTimeoutInSeconds: 5
    }
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                        exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-status-codes'
                '5xx'
                'reset'
                'connect-failure'
                'retriable-4xx'
            ]
        }
    } 
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
    tcpConnectionPool: {
        maxConnections: 100
    }
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
  }
}

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: {
  timeoutPolicy: {
      responseTimeoutInSeconds: 15
      connectionTimeoutInSeconds: 5
  }
}
Metadados Obrigatório Description Exemplo
responseTimeoutInSeconds Sim Tempo limite aguardando uma resposta do aplicativo contêiner. 15
connectionTimeoutInSeconds Sim Tempo limite para estabelecer uma conexão com o aplicativo contêiner. 5

Tentativas

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

httpRetryPolicy

properties: {
    httpRetryPolicy: {
        maxRetries: 5
        retryBackOff: {
          initialDelayInMilliseconds: 1000
          maxIntervalInMilliseconds: 10000
        }
        matches: {
            headers: [
                {
                    header: 'x-ms-retriable'
                    match: { 
                       exactMatch: 'true'
                    }
                }
            ]
            httpStatusCodes: [
                502
                503
            ]
            errors: [
                'retriable-headers'
                'retriable-status-codes'
            ]
        }
    } 
}
Metadados Obrigató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/D
retryBackOff.initialDelayInMilliseconds Sim Atraso entre o primeiro erro e a primeira tentativa. 1000
retryBackOff.maxIntervalInMilliseconds Sim Atraso máximo entre tentativas. 10000
matches Sim Defina os valores de correspondência para limitar quando o aplicativo deve tentar uma nova tentativa. headers, httpStatusCodes, errors
matches.headers Y* Tente novamente quando a resposta de erro incluir um cabeçalho específico. *Os cabeçalhos só são propriedades necessárias se você especificar a retriable-headers propriedade error. Saiba mais sobre as correspondências de cabeçalho disponíveis. X-Content-Type
matches.httpStatusCodes Y* Tente novamente quando a resposta retornar um código de status específico. *Os códigos de status só são propriedades necessárias se você especificar a retriable-status-codes propriedade error. 502, 503
matches.errors Sim Só tenta novamente quando o aplicativo retorna um erro específico. Saiba mais sobre os erros disponíveis. connect-failure, reset
Correspondências de cabeçalho

Se você especificou o retriable-headers erro, pode usar as seguintes propriedades de correspondência de cabeçalho para tentar novamente quando a resposta incluir um cabeçalho específico.

matches: {
  headers: [
    { 
      header: 'x-ms-retriable'
      match: {
        exactMatch: 'true'
      }
    }
  ]
}
Metadados Description
prefixMatch As novas tentativas são realizadas com base no prefixo do valor do cabeçalho.
exactMatch As novas tentativas são realizadas com base em uma correspondência exata do valor do cabeçalho.
suffixMatch As novas tentativas são realizadas com base no sufixo do valor do cabeçalho.
regexMatch As novas tentativas são realizadas com base em uma regra de expressão regular em que o valor do cabeçalho deve corresponder ao padrão regex.
Erros

Você pode executar novas tentativas em qualquer um dos seguintes erros:

matches: {
  errors: [
    'retriable-headers'
    'retriable-status-codes'
    '5xx'
    'reset'
    'connect-failure'
    'retriable-4xx'
  ]
}
Metadados Description
retriable-headers Cabeçalhos de resposta HTTP que acionam uma nova tentativa. Uma nova tentativa é executada se qualquer uma das correspondências de cabeçalho corresponder aos cabeçalhos de resposta. Obrigatório se você quiser tentar novamente em qualquer cabeçalho correspondente.
retriable-status-codes Códigos de status HTTP que devem disparar tentativas. Obrigatório se você quiser repetir os códigos de status correspondentes.
5xx Tente novamente se o servidor responder com qualquer código de resposta 5xx.
reset Tente novamente se o servidor não responder.
connect-failure Tente novamente se uma solicitação falhar devido a uma conexão defeituosa com o aplicativo contêiner.
retriable-4xx Tente novamente se o aplicativo contêiner responder com um código de resposta da série 400, como 409.

tcpRetryPolicy

properties: {
    tcpRetryPolicy: {
        maxConnectAttempts: 3
    }
}
Metadados Obrigatório Description Exemplo
maxConnectAttempts Sim Defina o máximo de tentativas de conexão (maxConnectionAttempts) para tentar novamente em conexões com falha. 3

Disjuntores

As políticas de disjuntor especificam se uma réplica de aplicativo de contêiner é temporariamente removida do pool de balanceamento de carga, com base em gatilhos como o número de erros consecutivos.

properties: {
    circuitBreakerPolicy: {
        consecutiveErrors: 5
        intervalInSeconds: 10
        maxEjectionPercent: 50
    }
}
Metadados Obrigatório Description Exemplo
consecutiveErrors Sim Número consecutivo de erros antes que uma réplica de aplicativo de contêiner seja temporariamente removida do balanceamento de carga. 5
intervalInSeconds Sim A quantidade de tempo dada para determinar se uma réplica é removida ou restaurada do pool de balanceamento de carga. 10
maxEjectionPercent Sim Porcentagem máxima de réplicas de aplicativos de contêiner com falha a serem ejetadas do balanceamento de carga. Remove pelo menos um host, independentemente do valor. 50

Pools de conexões

O pool de conexões do Aplicativo de Contêiner do Azure mantém um pool de conexões estabelecidas e reutilizáveis para aplicativos de contêiner. Esse pool de conexões reduz a sobrecarga de criar e derrubar conexões individuais para cada solicitação.

Os pools de conexões permitem especificar o número máximo de solicitações ou conexões permitidas para um serviço. Esses limites controlam o número total de conexões simultâneas para cada serviço. Quando esse limite é atingido, novas conexões não são estabelecidas para esse serviço até que as conexões existentes sejam liberadas ou fechadas. Esse processo de gerenciamento de conexões evita que os recursos sejam sobrecarregados por solicitações e mantém o gerenciamento eficiente de conexões.

httpConnectionPool

properties: {
    httpConnectionPool: {
        http1MaxPendingRequests: 1024
        http2MaxRequests: 1024
    }
}
Metadados Obrigatório Description Exemplo
http1MaxPendingRequests Sim Usado para http1 solicitações. Número máximo de conexões abertas para um aplicativo de contêiner. 1024
http2MaxRequests Sim Usado para http2 solicitações. Número máximo de solicitações simultâneas para um aplicativo de contêiner. 1024

tcpConnectionPool

properties: {
    tcpConnectionPool: {
        maxConnections: 100
    }
}
Metadados Obrigatório Description Exemplo
maxConnections Sim Número máximo de conexões simultâneas com um aplicativo de contêiner. 100

Observabilidade da resiliência

Você pode realizar a observabilidade de resiliência por meio das métricas e logs do sistema do seu aplicativo de contêiner.

Logs de resiliência

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

Screenshot demonstrating where to find the logs for your container app.

No painel Logs, escreva e execute uma consulta para encontrar resiliência por meio dos logs do sistema do aplicativo contêiner. Por exemplo, execute uma consulta semelhante à seguinte para procurar eventos de resiliência e mostrar os seus:

  • Carimbo de data/hora
  • Nome do ambiente
  • Nome do aplicativo de contêiner
  • Tipo de resiliência e razão
  • Registrar mensagens
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s

Clique em Executar para executar a consulta e exibir os resultados.

Screenshot showing resiliency query results based on provided query example.

Métricas de resiliência

No menu Monitoramento do seu aplicativo de contêiner, selecione Métricas. No painel Métricas, selecione os seguintes filtros:

  • O escopo para o nome do seu aplicativo de contêiner.
  • O namespace de métricas padrão .
  • As métricas de resiliência no menu suspenso.
  • Como pretende que os dados sejam agregados nos resultados (por média, por máximo, etc.).
  • A duração do tempo (últimos 30 minutos, últimas 24 horas, etc.).

Screenshot demonstrating how to access the resiliency metrics filters for your container app.

Por exemplo, se você definir a métrica Repetições de solicitação de resiliência no escopo do aplicativo de teste com Agregação média para pesquisar dentro de um período de tempo de 30 minutos, os resultados terão a seguinte aparência:

Screenshot showing the results from example metrics filters for resiliency.

Conteúdos relacionados

Veja como funciona a resiliência para componentes Dapr em Aplicativos de Contêiner do Azure.