O Alibaba Cloud Service Mesh (ASM) gerencia todo o tráfego norte-sul e leste-oeste nos clusters. Configure políticas de timeout, retry, throttling, circuit breaking, enfileiramento, prefetch e fallback para fortalecer a alta disponibilidade dos seus sistemas distribuídos.
Introdução aos recursos
Em sistemas distribuídos, a proteção e o agendamento de tráfego são fundamentais para a estabilidade. Qualquer flutuação ou anomalia no tráfego pode causar falhas de serviço, efeitos em cascata ou exaustão de recursos.
Frameworks tradicionais, como o Resilience4j, oferecem throttling e circuit breaking no nível da aplicação. O Service Mesh entrega esses recursos no nível da infraestrutura de rede, sem exigir alterações no código, permitindo baixo acoplamento e configurações flexíveis.
O ASM oferece os seguintes recursos de alta disponibilidade:
Throttling: proteção contra sobrecarga do sistema
O throttling controla o tráfego para proteger os serviços de backend contra sobrecarga, exaustão de recursos ou ataques maliciosos. Em cenários de multitenancy, aplique throttling por tenant para garantir gerenciamento refinado de tráfego e alocação justa de recursos.
O ASM fornece as seguintes políticas de throttling:
Throttling local e global
O proxy de malha Envoy suporta dois métodos de throttling: local e global.
Cenários
O throttling local e o global atendem à maioria dos casos comuns, como limitar um serviço específico no cluster ou rotas específicas do gateway, com cotas de limitação de taxa separadas com base em critérios de correspondência de requisições.
Throttling global: Utiliza um serviço centralizado de throttling e um banco de dados Redis para impor limites de taxa em vários serviços.
Throttling local: É mais simples de configurar e não depende de componentes externos, mas cada réplica mantém seu próprio limitador de taxa independente.
Limitação de taxa baseada no conjunto de agendamento de tráfego do ASM
O conjunto de agendamento de tráfego do ASM é uma arquitetura unificada de agendamento de tráfego para Service Mesh que fornece políticas para agendamento de carga e gerenciamento de requisições em aplicações distribuídas nativas da nuvem. Esse conjunto suporta a RateLimitingPolicy para throttling.
Cenários
A RateLimitingPolicy permite agrupar requisições por tags e aplicar throttling dentro de cada grupo, sendo adequada para controle refinado em ambientes de multitenancy.
Controle de concorrência de tráfego: proteção de recursos críticos do sistema
O controle de concorrência limita o número de requisições simultâneas para evitar a exaustão de recursos. Diferentemente do throttling, ele foca em serviços que dependem de recursos críticos, como pools de threads ou bancos de dados.
O ASM oferece dois mecanismos de controle de concorrência:
Controle de concorrência baseado no conjunto de agendamento de tráfego do ASM
O conjunto de agendamento de tráfego do ASM suporta a ConcurrencyLimitingPolicy para controlar requisições concorrentes.
Cenários
Se o limite de concorrência de um sistema for relativamente fixo, defina um limite fixo para um serviço específico. Requisições que excederem esse limite receberão uma resposta 429.
Uso do ASMAdaptiveConcurrency para controle adaptativo de concorrência
O Envoy suporta controle adaptativo de concorrência, ativável por meio do ASMAdaptiveConcurrency. O ASMAdaptiveConcurrency ajusta dinamicamente o limite de concorrência para corresponder à capacidade do serviço de destino, rejeitando requisições excedentes com uma resposta 503 e a mensagem "reached concurrency limit".
Cenários
Se o limite de concorrência de um sistema oscilar significativamente e for difícil de estimar, utilize o AdaptiveConcurrency para limitar a concorrência dinamicamente. Recomendamos também ativar retries por meio da DestinationRule, permitindo retentar com sucesso as requisições rejeitadas.
Circuit breaking de tráfego: isolamento de nós com falha para evitar efeito cascata
O circuit breaking desconecta serviços defeituosos para isolar falhas e impedir sua propagação pelo sistema.
O ASM fornece circuit breaking em vários níveis:
Circuit breaking no nível do pool de conexões
O circuit breaking do pool de conexões, configurado por meio de regras de destino, limita o número máximo de conexões HTTP/1 ou TCP ao host do serviço alvo.
Cenários
Essa estratégia aciona o circuit breaking limitando conexões TCP e aplica-se a serviços cujos códigos de status HTTP não indicam problemas.
Circuit breaking no nível do host
O circuit breaking no nível do host, também configurado por meio de regras de destino, monitora falhas dentro de uma janela de tempo e remove hosts quando a taxa de erro ultrapassa um limiar.
Cenários
O circuit breaking no nível do host opera independentemente por host upstream, removendo temporariamente do pool de balanceamento de carga aqueles que apresentam erros 5xx contínuos. Ele detecta erros persistentes causados por problemas em uma única workload, mas não tem como alvo interfaces de API específicas.
Circuit breaking no nível da rota
O ASM permite configurar regras de circuit breaker para tráfego leste-oeste entre serviços e em rotas específicas. Para mais informações, consulte o documento referenciado.
Cenários
O circuit breaking no nível da rota atua na camada de serviço, detectando erros persistentes em APIs específicas causados por dependências de serviço ou erros de lógica.
Fallback de tráfego: tratamento de cenários de falha de chamada
Quando um microsserviço falha ou fica indisponível, um mecanismo de fallback redireciona as requisições para um serviço alternativo, mantendo a disponibilidade geral do sistema.
Cenários
Combinar circuit breaking no nível do host com fallback de tráfego permite alternar para um serviço de backup durante uma interrupção, mantendo a disponibilidade mesmo durante o acionamento do circuit breaking.
Prefetch de tráfego: transição suave para implantação de nova versão
Em implantações blue-green tradicionais ou atualizações graduais (rolling updates), uma nova versão do serviço pode receber todo o tráfego de uma vez, causando sobrecarga excessiva. O prefetch de tráfego introduz o tráfego gradualmente — por exemplo, começando com 10% e aumentando progressivamente —, ideal para serviços com altos custos de cold-start.
O ASM suporta dois níveis de prefetch de tráfego:
Warm-up
Configure o recurso de warm-up por meio de regras de destino para permitir que uma instância de serviço aumente gradualmente seu volume de requisições dentro de uma janela de tempo especificada.
Cenários
Quando o host upstream de um serviço alvo está dentro da janela de slow-start, o balanceador de carga reduz o tráfego alocado para esse host. Isso é ideal para scale-out de serviços ou lançamentos de novas versões, pois aquece os hosts upstream recém-iniciados.
O warm-up com slow-start não se aplica quando o serviço recém-lançado ou os endpoints de hosts upstream disponíveis são limitados.
Entrada progressiva de serviço online baseada no conjunto de agendamento de tráfego do ASM
Configurar a LoadRampingPolicy durante o lançamento de um novo serviço aumenta gradualmente o tráfego recebido, garantindo uma transição suave.
Cenários
O conjunto de agendamento de tráfego do ASM usa um amostrador de requisições para rejeitar uma proporção delas, garantindo que o tráfego total aumente lentamente. Este método é adequado para lançamentos de novos serviços, mas não para scale-out de serviços ou lançamentos de novas versões.
Timeout e retry: garantia de confiabilidade do serviço
Timeout e retry são medidas comuns de tolerância a falhas em sistemas distribuídos que mantêm a disponibilidade quando os serviços apresentam erros ocasionais. O timeout evita que as requisições fiquem pendentes indefinidamente, enquanto o retry lida com problemas transitórios, como instabilidade de rede ou falhas temporárias.
Enfileiramento de requisições e agendamento baseado em prioridade: sobrevivência em horários de pico
O enfileiramento de requisições complementa o throttling e os limites de concorrência. Quando a taxa de tráfego ou a contagem de requisições simultâneas excede a capacidade de processamento do sistema, as requisições excedentes são enfileiradas em vez de serem rejeitadas imediatamente, sendo processadas conforme as requisições anteriores são concluídas.
O ASM fornece três políticas de agendamento baseado em prioridade por meio de seu conjunto de agendamento de tráfego, baseadas em concorrência, taxa de tráfego e latência. Requisições de alta prioridade são processadas primeiro, garantindo funcionalidades críticas e melhor experiência para tenants principais.
O ASM suporta as seguintes políticas de enfileiramento de requisições e agendamento baseado em prioridade:
Agendamento de requisições baseado em prioridade sob concorrência controlável
Configure a ConcurrencySchedulingPolicy para determinar se o sistema está sobrecarregado com base em um limite de concorrência. Quando a concorrência de requisições excede esse limite, requisições adicionais são enfileiradas e agendadas por prioridade.
Cenários
Indicado para aplicações com limites de concorrência e serviços sujeitos a flutuações significativas de tráfego.
Agendamento de requisições baseado em prioridade sob taxa controlável
Configure a QuotaSchedulingPolicy para determinar se o sistema está sobrecarregado com base em um limite de taxa de tráfego. Quando a taxa de requisições excede esse limite, requisições adicionais são enfileiradas e agendadas por prioridade.
Cenários
Recomendado para aplicações com limites de taxa de tráfego e serviços sujeitos a grandes variações de tráfego.
Agendamento de requisições baseado em prioridade com base na latência média
Configure a AverageLatencySchedulingPolicy para comparar a latência das requisições em tempo real com a média histórica. Um desvio significativo indica sobrecarga do sistema; nesse caso, as requisições excedentes são enfileiradas e agendadas por prioridade.
Cenários
Este método adaptativo é adequado para cenários em que é difícil determinar a taxa máxima aceitável ou a concorrência para um serviço.