Quando interfaces individuais não possuem regras dedicadas de proteção de tráfego, picos inesperados podem desestabilizar suas aplicações de microsserviços. A proteção do sistema oferece salvaguardas no nível do nó que abrangem todas as interfaces e funcionam como uma rede de segurança básica para manter a estabilidade da aplicação.
O Microservices Governance oferece cinco tipos de proteção do sistema:
|
Tipo de proteção |
Monitora |
Aplica-se a |
Versão do agente |
|
Utilização de CPU |
Todas as interfaces de servidor |
V3.1.4+ |
|
|
Soma do QPS de todas as interfaces em um nó |
Todas as interfaces de servidor |
4.2.0+ |
|
|
Soma de requisições simultâneas em todas as interfaces de um nó |
Todas as interfaces de servidor |
4.2.0+ |
|
|
Percentual de erros por interface de cliente |
Todas as interfaces de cliente |
4.2.0+ |
|
|
Percentual de chamadas lentas por interface de cliente |
Todas as interfaces de cliente |
4.2.0+ |
Todas as regras de proteção do sistema têm prioridade inferior às regras de proteção de tráfego no nível da interface. Quando o sistema aciona a limitação ou o circuit breaking, ele retorna o código de status HTTP 429. Para obter uma comparação detalhada, consulte Proteção do sistema vs. proteção de tráfego.
Escolha o tipo de proteção adequado
Use esta matriz de decisão para identificar quais tipos de proteção se adequam ao seu cenário:
|
Cenário |
Proteção recomendada |
Motivo |
|
Aplicação sensível a CPU com carga impulsionada por tráfego |
Proteção adaptativa contra sobrecarga |
Ajusta dinamicamente a limitação com base na diferença de utilização da CPU |
|
Desempenho limitado por memória, rede ou outros fatores (não CPU) |
Limitação de QPS total |
Limita a taxa de requisições independentemente da carga da CPU |
|
Tempos de resposta altos (geralmente acima de 1 segundo) causando filas de requisições |
Limitação de QPS total + Limitação de concorrência total |
A limitação de QPS sozinha não evita o acúmulo de filas quando as requisições levam mais de 1 segundo para concluir |
|
Serviços downstream retornando erros frequentes |
Circuit breaking de chamadas anômalas |
Permite falha rápida para evitar filas de requisições no chamador |
|
Serviços downstream respondendo lentamente, mas sem atingir o tempo limite |
Circuit breaking de chamadas lentas |
Detecta respostas lentas independentemente das configurações de tempo limite |
Melhor prática: Comece com a proteção do sistema como uma rede de segurança básica e adicione regras de proteção de tráfego no nível da interface para minimizar limitações desnecessárias em interfaces individuais.
Configure regras de proteção do sistema
Antes de começar, verifique se você tem:
Microservices Governance Enterprise Edition ativado. Para mais informações, consulte Ativar o Microservices Governance
Microservices Governance habilitado para sua aplicação. Para mais informações, consulte Habilitar o Microservices Governance para aplicações de microsserviços Java em um cluster ACK ou ACS e Habilitar o Microservices Governance para aplicações de microsserviços em instâncias ECS
Para configurar a proteção do sistema:
Faça login no MSE console e selecione uma região na barra de navegação superior.
No painel de navegação à esquerda, escolha Microservices Governance > Application Governance.
Na página Application list, clique em no cartão de recursos da aplicação desejada. No painel de navegação à esquerda, clique em Traffic management.
Clique em na aba System Protection e configure os tipos de proteção descritos nas seções a seguir.
Proteção adaptativa contra sobrecarga
Requer o agente V3.1.4 ou posterior.
Como funciona
A proteção adaptativa contra sobrecarga usa a utilização da CPU para medir a carga do sistema. Quando o uso da CPU se aproxima do limiar configurado, o sistema ajusta adaptativamente a porcentagem de limitação do tráfego do servidor. Ele rejeita parte das requisições recebidas para manter a utilização da CPU dentro de uma pequena faixa em torno do limiar.
Essa proteção entra em vigor em todas as interfaces de servidor.
Quando usar
Use a proteção adaptativa contra sobrecarga para aplicações sensíveis à CPU, em que picos inesperados de tráfego aumentam diretamente a carga da CPU e degradam os tempos de resposta.
Para determinar um limiar, execute testes de estresse ou analise dados históricos para identificar a utilização máxima da CPU durante a operação em estado estacionário e defina um valor ligeiramente superior.
Layout do console
A seção Adaptive Overload Protection possui dois painéis:
Painel esquerdo -- Lista eventos de proteção adaptativa contra sobrecarga. O sistema gera eventos quando a limitação inicia, ativa e termina. Clique em View na coluna Actions para inspecionar a utilização da CPU de um IP de nó específico e reproduzir dados do intervalo de relatório.
Painel direito -- Mostra a tendência média de utilização da CPU para cada nó da aplicação nos últimos 5 minutos.
Parâmetros
|
Parâmetro |
Descrição |
|
ON |
Close: Desativado. Simulated Execution: Gera eventos quando o sistema aciona a proteção, mas não limita o tráfego. Open: O sistema aciona a proteção e limita uma porcentagem do tráfego de entrada. |
|
vCPU Utilization |
Limiar alvo de utilização da CPU. O sistema ajusta adaptativamente a probabilidade de limitação com base na diferença entre a utilização real e a alvo. |
|
Exception Settings |
Interfaces excluídas desta regra. Consulte Configurações de exceção. |
Limitação de QPS total
Requer o agente 4.2.0 ou posterior.
Como funciona
A limitação de QPS total mede o total agregado de consultas por segundo (QPS) em todas as interfaces de servidor em um único nó. Se o QPS total exceder o limiar configurado, o sistema limitará as requisições recebidas.
Essa proteção entra em vigor em todas as interfaces de servidor.
Quando usar
Use a limitação de QPS total quando o desempenho da aplicação depender de fatores além da utilização da CPU, como memória, rede ou outros recursos. Nesses casos, a proteção adaptativa baseada apenas em CPU pode não ser acionada mesmo que a aplicação esteja degradada.
Para definir um limiar, execute testes de estresse ou analise dados históricos para identificar o QPS total durante a operação em estado estacionário e configure um valor ligeiramente maior.
Layout do console
A seção Total QPS Throttling possui dois painéis:
Painel esquerdo -- Lista eventos de limitação. O sistema relata eventos para nós e interfaces limitados nos últimos 5 minutos, com um intervalo de relatório de 5 minutos. Clique em View para inspecionar o QPS total de um IP de nó específico e reproduzir dados do intervalo de relatório.
Painel direito -- Exibe a tendência média do QPS total para cada nó da aplicação nos últimos 5 minutos.
Parâmetros
|
Parâmetro |
Descrição |
|
ON |
Close: Desativado. Enable: Limita requisições quando o QPS total excede o limiar. |
|
Total QPS Threshold |
QPS total máximo permitido em um único nó. |
|
Exception Settings |
Interfaces excluídas desta regra. Consulte Configurações de exceção. |
Limitação de concorrência total
Requer o agente 4.2.0 ou posterior.
Como funciona
A limitação de concorrência total mede o número agregado de requisições simultâneas em todas as interfaces de servidor em um único nó. Se a concorrência total exceder o limiar configurado, o sistema limitará as requisições recebidas.
Essa proteção entra em vigor em todas as interfaces de servidor.
Quando usar
Use a limitação de concorrência total junto com a limitação de QPS total, especialmente quando os tempos de resposta (RT) das interfaces forem altos (geralmente acima de 1 segundo). Em cenários de alto RT, se recursos do sistema como pools de threads, memória e pools de conexões estiverem ocupados, as requisições entrarão em fila e o RT da interface aumentará. A limitação de QPS sozinha tem uma limitação: mesmo um pequeno número de novas requisições por segundo pode se acumular, pois as requisições enfileiradas levam mais de um segundo para concluir. Isso causa filas de requisições e infla o RT tanto para requisições existentes quanto para novas.
A limitação de concorrência resolve esse problema ao rejeitar novas requisições enquanto as requisições enfileiradas ainda estão em processamento. Após o esgotamento da fila, o sistema admite e processa as requisições subsequentes com tempos de espera menores, o que melhora significativamente as taxas de sucesso e o RT médio.
Para determinar um limiar, execute testes de estresse ou analise dados históricos para identificar a concorrência total durante a operação em estado estacionário e defina um valor ligeiramente superior.
Layout do console
A seção Total Concurrency Throttling possui dois painéis:
Painel esquerdo -- Lista eventos de limitação. O sistema relata eventos para nós e interfaces limitados nos últimos 5 minutos, com um intervalo de relatório de 5 minutos. Clique em View para inspecionar a concorrência total de um IP de nó específico e reproduzir dados do intervalo de relatório.
Painel direito -- Apresenta a tendência média da concorrência total para cada nó da aplicação nos últimos 5 minutos.
Parâmetros
|
Parâmetro |
Descrição |
|
ON |
Close: Desativado. Enable: Limita requisições quando a concorrência total excede o limiar. |
|
Total Concurrency Threshold |
Número máximo de requisições simultâneas permitidas em um único nó. |
|
Exception Settings |
Interfaces excluídas desta regra. Consulte Configurações de exceção. |
Circuit breaking de chamadas anômalas
Requer o agente 4.2.0 ou posterior.
Como funciona
O circuit breaking de chamadas anômalas monitora o percentual de erros de cada interface de cliente. Quando o percentual de erros excede o limiar configurado, o circuit breaker abre para essa interface. Durante o período de circuit breaking, todas as requisições para a interface falham imediatamente. O sistema envia requisições de sondagem em intervalos regulares e, se uma sondagem for bem-sucedida, o circuit breaker fecha e o tráfego normal é retomado.
Esta proteção aplica-se a todas as interfaces de cliente, exceto aquelas que já possuem regras de circuit breaking no nível da interface configuradas.
Quando usar
O circuit breaking de chamadas anômalas lida com dois cenários:
Cenários de tempo limite -- Tempos limite frequentes em uma interface de cliente geralmente indicam que o provedor de serviços está enfrentando problemas. Sem o circuit breaking, as requisições se acumulam em fila e acabam afetando outras interfaces na aplicação chamadora. O circuit breaking permite uma falha rápida e evita o enfileiramento de requisições.
Cenários de erro sem tempo limite -- Erros frequentes que não são de tempo limite em uma interface de cliente. O circuit breaking permite que o sistema relate erros relevantes para tratamento pelo usuário, minimiza o impacto dos problemas e otimiza a experiência do usuário quando os problemas ocorrem.
Layout do console
A seção Abnormal Call Circuit Breaking possui dois painéis:
Painel esquerdo -- Lista eventos de circuit breaking relatados nos últimos 5 minutos, com um intervalo de relatório de 5 minutos.
Painel direito -- Mostra as 10 principais interfaces com o maior percentual de chamadas anômalas nos últimos 5 minutos.
Parâmetros
|
Parâmetro |
Descrição |
|
ON |
Close: Desativado. Enable: Aciona o circuit breaking quando o percentual de chamadas anômalas excede o limiar. |
|
Circuit Breaking Percentage Threshold (%) |
Percentual de erros que aciona o circuit breaking em uma interface. |
|
Exception Settings |
Interfaces excluídas desta regra. Consulte Configurações de exceção. |
Configurações avançadas
|
Parâmetro |
Descrição |
|
Statistics Window Duration (s) |
Duração da janela de estatísticas. Faixa válida: 1 segundo a 120 minutos. |
|
Circuit Breaking Duration (s) |
Duração do período de circuit breaking. Durante este período, todas as requisições para a interface afetada falham imediatamente. |
|
Minimum number of requests |
Número mínimo de requisições necessárias dentro da janela de estatísticas para acionar o circuit breaking. Se a contagem de requisições estiver abaixo deste valor, o circuit breaking não será acionado mesmo que o percentual de erros exceda o limiar. |
|
Fuse recovery strategy |
Controla como o circuit breaker se recupera após o término do período de circuit breaking. Single detection recovery -- O circuit breaker testa a próxima requisição após o período de circuit breaking. Se a requisição for bem-sucedida (sem chamada lenta ou anômala), o circuit breaker fecha. Caso contrário, o circuit breaking é acionado novamente. Progressive recovery -- Requer os parâmetros Number of recovery phases e Minimum number of passes per step. O circuit breaker aumenta gradualmente a porcentagem de requisições permitidas em vários estágios. Consulte Recuperação progressiva. |
Recuperação progressiva
Após o término do período de circuit breaking, o circuit breaker percorre estágios de recuperação e aumenta gradualmente a porcentagem de requisições permitidas.
Como a porcentagem é calculada:
Porcentagem de requisições por estágio = 100 / Número de estágios de recuperação (N)
O Estágio 1 permite T% das requisições
O Estágio 2 permite 2T% das requisições
Isso continua até que 100% das requisições sejam permitidas
Em cada estágio, o sistema aciona uma verificação quando o número de requisições atinge o valor de Minimum number of passes per step. Se o percentual de erros permanecer abaixo do limiar, o circuit breaker avança para o próximo estágio. Se o percentual de erros exceder o limiar, o circuit breaking é acionado novamente.
Exemplo: Com 3 estágios de recuperação e um mínimo de 5 aprovações por etapa:
|
Estágio |
Requisições permitidas |
Condição de verificação |
|
1 |
33% |
Após 5 ou mais requisições |
|
2 |
67% |
Após 5 ou mais requisições |
|
3 |
100% |
Recuperação total |
Se chegarem menos de 5 requisições durante um estágio, o sistema avança para o próximo estágio sem verificação.
Circuit breaking de chamadas lentas
Requer o agente 4.2.0 ou posterior.
Como funciona
O circuit breaking de chamadas lentas monitora o percentual de chamadas lentas de cada interface de cliente. Uma chamada é classificada como lenta quando seu tempo de resposta excede o limiar configurado de Slow Call RT. Quando o percentual de chamadas lentas excede o Degradation Threshold, o circuit breaker abre para essa interface. Durante o período de circuit breaking, todas as requisições falham imediatamente. O sistema envia requisições de sondagem em intervalos regulares e, se uma sondagem for bem-sucedida, o circuit breaker fecha.
Esta proteção aplica-se a todas as interfaces de cliente, exceto aquelas que já possuem regras de circuit breaking no nível da interface configuradas.
Quando usar
Use o circuit breaking de chamadas lentas em cenários propensos a tempo limite onde o circuit breaking de chamadas anômalas também possa se aplicar. Ao contrário do circuit breaking de chamadas anômalas, o circuit breaking de chamadas lentas permite o ajuste dinâmico do limiar de RT que define uma "chamada lenta", independentemente das configurações de tempo limite.
Layout do console
A seção Slow Call Circuit Breaking possui dois painéis:
Painel esquerdo -- Lista eventos de circuit breaking relatados para chamadas lentas nos últimos 5 minutos, com um intervalo de relatório de 5 minutos.
Painel direito -- Exibe os 10 principais valores médios de RT nas interfaces da aplicação nos últimos 5 minutos.
Parâmetros
|
Parâmetro |
Descrição |
|
ON |
Close: Desativado. Enable: Classifica chamadas como lentas quando seu RT excede o limiar configurado. |
|
Slow Call RT (ms) |
Limiar de RT em milissegundos. Chamadas com RT acima deste valor são classificadas como chamadas lentas. |
|
Degradation Threshold (%) |
Percentual de chamadas lentas que aciona o circuit breaking. |
|
Exception Settings |
Interfaces excluídas desta regra. Consulte Configurações de exceção. |
Configurações avançadas
|
Parâmetro |
Descrição |
|
Statistics Window Duration (s) |
Duração da janela de estatísticas. Faixa válida: 1 segundo a 120 minutos. |
|
Circuit Breaking Duration (s) |
Duração do período de circuit breaking. Durante este período, todas as requisições para a interface afetada falham imediatamente. |
|
Minimum number of requests |
Número mínimo de requisições necessárias dentro da janela de estatísticas para acionar o circuit breaking. Se a contagem de requisições estiver abaixo deste valor, o circuit breaking não será acionado mesmo que o percentual de chamadas lentas exceda o limiar. |
|
Fuse recovery strategy |
Controla como o circuit breaker se recupera após o término do período de circuit breaking. Single detection recovery e Progressive recovery. Para detalhes, consulte Recuperação progressiva. |
Configurações de exceção
Requer o agente 4.2.0 ou posterior.
As configurações de exceção permitem excluir interfaces específicas de todas as regras de proteção do sistema. As requisições nas interfaces excluídas passam sem verificação de regras.
Quando usá-las
Configure definições de exceção para:
Interfaces de verificação de integridade -- Evita que regras de proteção do sistema limitem verificações de integridade, o que poderia afetar o status de integridade dos nós.
Interfaces críticas do sistema -- Interfaces chave que possuem limites de limitação separados não devem estar sujeitas ao mecanismo de limitação global do sistema.
Como configurar
Na caixa de diálogo de configurações de exceção:
A seção Available Interfaces à esquerda lista as interfaces chamadas recentemente. Se a interface desejada não estiver listada, insira seu nome na caixa de pesquisa e clique em no ícone de pesquisa.
Adicione a interface à seção Selected Interfaces à direita.
Proteção do sistema vs. proteção de tráfego
Tanto a proteção do sistema quanto a proteção de tráfego mantêm as aplicações estáveis, mas operam em níveis diferentes:
|
Dimensão |
Proteção do sistema |
Proteção de tráfego |
|
Escopo |
Nível de nó. As mesmas regras se aplicam a todas as interfaces de uma aplicação. |
Nível de interface. Limiares diferentes por interface. |
|
Granularidade |
Granulação grossa -- protege o nó como um todo. |
Granulação fina -- protege interfaces individuais com base na importância e nas características de carga. |
|
Esforço de configuração |
Baixo. Alguns poucos limiares cobrem toda a aplicação. |
Maior. Requer ajuste de limiar por interface. |
|
Perda de tráfego |
Maior. A limitação aplica-se amplamente a todas as interfaces. |
Menor. Apenas as interfaces que excedem seus limiares individuais são limitadas. |
|
Mais indicado para |
Rede de segurança básica contra picos inesperados. |
Proteção de nível de produção com perda de tráfego minimizada. |
Tanto a proteção do sistema quanto a proteção de tráfego retornam o código de status HTTP 429 quando o sistema aciona a limitação. Códigos de status personalizados não são suportados.