Alibaba Cloud Service Mesh:Build fault-tolerant distributed systems with ASM

Configure um timeout

Sem um timeout, uma requisição para um serviço upstream sem resposta fica bloqueada indefinidamente, consumindo recursos e podendo travar o chamador. Definir um timeout estabelece um limite para essa espera: se o upstream não responder dentro da duração especificada, o sidecar proxy retorna um erro para que o chamador possa executar uma ação alternativa.

Um erro de timeout não significa que a operação no upstream falhou. A operação ainda pode ser concluída no lado do servidor. O timeout indica apenas que o chamador parou de esperar.

Defina o campo timeout em uma rota dentro de um VirtualService. Esse timeout se aplica a todas as requisições que correspondem a essa rota.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - 'httpbin'
  http:
  - route:
    - destination:
        host: httpbin
    timeout: 5s

Configure uma política de retry

Falhas transitórias, como redefinições de conexão, reinícios breves de serviços ou problemas momentâneos de rede, costumam se resolver sozinhas. Um mecanismo de retry reenvia automaticamente as requisições com falha, aumentando as taxas de sucesso sem intervenção manual.

Defina um bloco retries em um VirtualService. O exemplo abaixo tenta até 3 vezes em caso de falhas ou redefinições de conexão, com um timeout de 5 segundos por tentativa:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - 'httpbin'
  http:
  - route:
    - destination:
        host: httpbin
    retries:
      attempts: 3
      perTryTimeout: 5s
      retryOn: connect-failure,reset

Configure um bulkhead

Um único chamador com comportamento inadequado pode sobrecarregar um serviço ao abrir conexões demais ou enviar muitas requisições simultâneas. O padrão bulkhead isola os recursos limitando as conexões e requisições, impedindo que um serviço consuma toda a capacidade disponível. Requisições que ultrapassam o limiar recebem imediatamente um erro 503, em vez de ficarem enfileiradas indefinidamente.

Defina limites de connection pool em um DestinationRule. O exemplo a seguir restringe o serviço httpbin a 1 conexão simultânea, 1 requisição por conexão e 1 requisição pendente, com um timeout de conexão de 10 segundos:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
      tcp:
        connectTimeout: 10s
        maxConnections: 1

Configure o circuit breaking

Se um host upstream começar a retornar erros consistentemente, continuar enviando tráfego para ele desperdiça recursos e aumenta as taxas de erro. O circuit breaking detecta hosts com falha e os remove (ejetam) temporariamente do pool de balanceamento de carga. Após o período de ejeção, o host é readicionado. Se as falhas persistirem, a duração das ejeções aumenta progressivamente — cada ejeção subsequente dura mais que a anterior (baseEjectionTime x número de ejeções consecutivas).

Defina regras de detecção de outliers em um DestinationRule. O exemplo abaixo ejeta um host do serviço httpbin se ele retornar 3 erros consecutivos dentro de qualquer janela de 5 segundos. O host permanece ejetado por pelo menos 5 minutos, e até 100% dos hosts podem ser ejetados simultaneamente:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 3
      interval: 5s
      baseEjectionTime: 5m
      maxEjectionPercent: 100

Referências

• Referência do VirtualService do Istio — referência completa de campos para configuração de timeout e retry

• Referência do DestinationRule do Istio — referência completa de campos para configuração de bulkhead e circuit breaking

• Configurar sidecar proxies — gerencie as configurações de sidecar proxy para suas cargas de trabalho