Quando um service downstream responde lentamente ou retorna erros com alta frequência, as falhas podem se propagar e degradar toda a aplicação. O recurso de circuit breaking no Microservices Engine (MSE) monitora essas dependências downstream e interrompe automaticamente o envio de requisições ao ultrapassar um limiar configurado. Após um período de resfriamento, o MSE testa a recuperação e permite gradualmente a retomada das requisições.
O circuit breaking atua sobre dependências fracas — services downstream cuja indisponibilidade temporária a aplicação tolera. Para dependências críticas em que as falhas devem se propagar imediatamente, utilize estratégias de nova tentativa ou fallback.
Como funciona
Um circuit breaker transita entre três estados:
Fechado (operação normal) — Todas as requisições passam normalmente. O MSE rastreia métricas (proporção de chamadas lentas ou proporção de erros) dentro da janela de tempo configurada.
Aberto (circuito disparado) — Quando a métrica rastreada ultrapassa o limiar configurado e atinge a contagem mínima de requisições, o MSE bloqueia todas as requisições durante a duração definida. As requisições bloqueadas falham imediatamente, em vez de aguardar um timeout.
-
Semiaberto (teste de recuperação) — Após o término da duração do circuit breaking, o MSE permite a passagem da próxima requisição como teste:
Se a requisição de teste for bem-sucedida, o circuit breaker retorna ao estado Fechado.
Se a requisição de teste falhar, o circuit breaker retorna ao estado Aberto por mais uma duração completa.
O MSE também oferece suporte à recuperação progressiva, que aumenta gradualmente a porcentagem de requisições permitidas em múltiplas etapas, em vez de depender de uma única requisição de teste.
Pré-requisitos
Antes de começar, verifique se você possui:
MSE Enterprise Edition ativado
-
Microservices Governance habilitado para suas aplicações. Para instruções de configuração, consulte:
Criar uma regra de circuit breaking
Faça login no console do MSE 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 a aplicação desejada. Em seguida, abra a caixa de diálogo Add Circuit Breaking Rule por um dos seguintes caminhos:
Caminho A: No painel de navegação à esquerda, clique em API Details. Na aba WEB service, clique em a aba Client. Selecione uma interface, clique em a aba Circuit Breaking e, em seguida, clique em Added fusing rule.
Caminho B: No painel de navegação à esquerda, clique em Traffic management. Clique em a aba Flow protection, depois na aba Fuse rule e, por fim, clique em Added fusing rule.
Na caixa de diálogo Add Circuit Breaking Rule, configure os parâmetros a seguir e clique em New.
Parâmetros da regra
|
Parâmetro |
Descrição |
Valores válidos |
|
Interface name |
Interface protegida por esta regra. |
-- |
|
Statistical window duration |
Duração da janela de tempo usada para calcular as métricas. |
1 segundo a 120 minutos |
|
Minimum number of requests |
Quantidade mínima de requisições necessária dentro da janela de tempo antes do acionamento do circuit breaking. Se a contagem real de requisições estiver abaixo desse valor, o circuit breaker permanece fechado independentemente da proporção da métrica. |
Inteiro positivo |
|
Threshold Type |
Métrica utilizada para avaliar o disparo do circuit breaker. |
Slow call ratio (%), Abnormal proportion (%) |
|
Slow call RT |
Limiar de tempo de resposta (em milissegundos) que define uma chamada lenta. Requisições que excedem esse valor são contabilizadas como chamadas lentas. Aplica-se apenas quando Threshold Type está definido como Slow call ratio (%). |
Inteiro positivo (ms) |
|
Circuit Breaking Ratio Threshold |
Limiar percentual que dispara o circuit breaking. Para proporção de chamadas lentas, refere-se à porcentagem de chamadas lentas. Para proporção anormal, refere-se à porcentagem de requisições anormais. |
0--100 (%) |
|
Circuit Breaking Duration (s) |
Tempo durante o qual o circuit breaker permanece aberto. Nesse período, todas as requisições para a interface protegida falham. |
Inteiro positivo (segundos) |
|
Circuit Breaking Policy |
Estratégia de recuperação após o término da duração do circuit breaking. |
Single detection recovery, Progressive recovery |
Nota: Os parâmetros Statistical window duration e Minimum number of requests funcionam em conjunto. Por exemplo, definir uma janela de 1 segundo com um mínimo de 10 requisições significa que interfaces de baixo tráfego (menos de 10 requisições por segundo) nunca acionarão o circuit breaker. Para interfaces com pouco tráfego, utilize uma janela mais longa com uma contagem mínima de requisições menor.
Políticas de recuperação
Single detection recovery
Após o término da duração do circuit breaking, o MSE permite a passagem da próxima requisição como teste de sondagem:
Se a requisição for bem-sucedida (tempo de resposta abaixo do limiar de RT de chamada lenta ou ausência de erro), o circuit breaker fecha e o tráfego normal é retomado.
Caso a requisição falhe, o circuit breaker reabre por mais uma duração completa.
Progressive recovery
Em vez de usar uma única requisição de teste, o MSE aumenta gradualmente a proporção de tráfego em várias etapas de recuperação. Isso reduz o risco de disparar o circuit breaker novamente logo após a recuperação.
Configure dois parâmetros adicionais:
|
Parâmetro |
Descrição |
|
Number of recovery phases |
Número de etapas usadas para aumentar o tráfego gradualmente até 100%. |
|
Minimum number of passes per step |
Quantidade mínima de requisições em cada etapa antes que o MSE avalie a progressão para a próxima fase. |
A porcentagem de tráfego permitido em cada etapa é calculada da seguinte forma:
Traffic ratio = 100% / Number of recovery phases
Por exemplo, com 3 fases de recuperação e um mínimo de 5 requisições por etapa:
|
Etapa |
Tráfego permitido |
Comportamento |
|
1 |
33% |
O MSE permite a passagem de 33% das requisições. Após pelo menos 5 requisições passarem, o MSE verifica a métrica. Se estiver abaixo do limiar, avança para a Etapa 2. Se estiver acima, reabre o circuit breaker. |
|
2 |
67% |
O MSE permite a passagem de 67% das requisições. A avaliação segue o mesmo critério da Etapa 1. |
|
3 |
100% |
Todas as requisições passam. O circuit breaker fecha completamente. |
Se o número de requisições em uma etapa for inferior ao mínimo de aprovações por passo, o sistema avança para a próxima etapa de recuperação até que todas as requisições tenham permissão para passar.
Exemplos
Circuit breaking por chamada lenta
Cenário: Sua aplicação chama um service de terceiros que ocasionalmente responde lentamente, causando timeouts que degradam o desempenho da aplicação.
Configuração:
|
Parâmetro |
Valor |
Justificativa |
|
Interface name |
test |
Interface que chama o service downstream lento. |
|
Statistical window duration |
1 segundo |
Detectar degradação rapidamente. |
|
Minimum number of requests |
10 |
Evitar disparos em interfaces de baixo tráfego. |
|
Threshold Type |
Slow call ratio (%) |
Monitorar tempo de resposta, não erros. |
|
Slow call RT |
1000 ms |
Requisições que excedem 1 segundo são consideradas chamadas lentas. |
|
Circuit Breaking Ratio Threshold |
80% |
Disparar quando 80% das requisições forem lentas. |
|
Circuit Breaking Duration (s) |
10 segundos |
Bloquear todas as requisições por 10 segundos. |
|
Circuit Breaking Policy |
Single detection recovery |
Testar uma requisição após cada período de circuit breaking. |
Comportamento: Se mais de 10 requisições chegarem dentro de 1 segundo e mais de 80% demorarem mais de 1000 ms, o circuit breaker abre. Todas as requisições para a interface test falharão nos próximos 10 segundos. Após 10 segundos, o MSE libera uma requisição. Se ela for concluída em menos de 1000 ms, o circuit breaker fecha. Caso contrário, reabre por mais 10 segundos.
Circuit breaking por requisição anormal
Cenário: Sua aplicação exibe conteúdo de um service de terceiros. Quando há um pico de requisições anormais, o conteúdo degradado prejudica a experiência do usuário.
Configuração:
|
Parâmetro |
Valor |
Justificativa |
|
Interface name |
test |
Interface que chama o service downstream anormal. |
|
Statistical window duration |
1 segundo |
Detectar picos de requisições anormais rapidamente. |
|
Minimum number of requests |
10 |
Evitar disparos em interfaces de baixo tráfego. |
|
Threshold Type |
Abnormal proportion (%) |
Monitorar a proporção de requisições anormais. |
|
Circuit Breaking Ratio Threshold |
80% |
Disparar quando 80% das requisições forem anormais. |
|
Circuit Breaking Duration (s) |
10 segundos |
Bloquear todas as requisições por 10 segundos. |
|
Circuit Breaking Policy |
Single detection recovery |
Testar uma requisição após cada período de circuit breaking. |
Comportamento: Se mais de 10 requisições chegarem dentro de 1 segundo e mais de 80% forem anormais, o circuit breaker abre. Todas as requisições para a interface test falharão nos próximos 10 segundos. Após 10 segundos, o MSE libera uma requisição. Se ela for bem-sucedida, o circuit breaker fecha. Caso contrário, reabre por mais 10 segundos.
Melhores práticas
Escolher o tipo de limiar adequado
Utilize Slow call ratio quando a degradação do tempo de resposta for a principal preocupação, como em chamadas de API síncronas em que a latência afeta diretamente a experiência do usuário.
Prefira Abnormal proportion quando erros downstream representarem o risco principal, como em chamadas para services de terceiros não confiáveis.
Definir valores apropriados para janela e limiares
Janela estatística: Janelas mais curtas (1--10 segundos) detectam problemas mais rapidamente, mas são mais sensíveis a picos de tráfego. Janelas mais longas (1--5 minutos) fornecem sinais mais estáveis para interfaces com menor volume de tráfego.
Número mínimo de requisições: Defina este valor alto o suficiente para evitar falsos positivos. Para interfaces de baixo tráfego, um mínimo de 5--10 requisições combinado com uma janela mais longa costuma ser mais confiável do que exigir 10 requisições por segundo.
Selecionar uma política de recuperação
A opção Single detection recovery funciona bem para services com recuperação binária — ou funcionam totalmente ou não funcionam.
A Progressive recovery é mais segura para services que podem estar parcialmente recuperados, pois evita que um fluxo repentino de tráfego sobrecarregue um service recém-restabelecido.
Verificar se uma regra está ativa
Após salvar uma regra de circuit breaking, confirme se ela funciona conforme o esperado:
No painel de navegação à esquerda, clique em Traffic management. Na aba Flow protection, clique em a aba Fuse rule para visualizar todas as regras configuradas e seus respectivos status.
Gere tráfego de teste para a interface protegida e monitore as métricas do circuit breaker para confirmar o acionamento correto da regra.
Tópicos relacionados
Configurar regras de limitação de taxa para controlar as taxas de requisição além do circuit breaking.