Quando um serviço downstream responde lentamente ou retorna erros com alta frequência, as falhas podem se propagar em cascata 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 exceder 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 — serviços 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.
-
Meio aberto (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últiplos estágios, 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:
Crie 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 caminhos abaixo:
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 para acionar o 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 se o circuit breaker deve ser disparado. |
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ários estágios 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 estágios usados para aumentar o tráfego progressivamente até 100%. |
|
Minimum number of passes per step |
Quantidade mínima de requisições em cada estágio antes que o MSE avalie se deve prosseguir para o próximo estágio. |
A porcentagem de tráfego permitido em cada estágio é 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 estágio:
|
Estágio |
Tráfego permitido |
Comportamento |
|
1 |
33% |
O MSE permite a passagem de 33% das requisições. Após pelo menos 5 requisições serem aprovadas, o MSE verifica a métrica. Se estiver abaixo do limiar, avança para o Estágio 2. Caso contrário, reabre o circuit breaker. |
|
2 |
67% |
O MSE permite a passagem de 67% das requisições. A avaliação segue o mesmo critério do Estágio 1. |
|
3 |
100% |
Todas as requisições passam. O circuit breaker fecha totalmente. |
Se o número de requisições em um estágio for inferior ao mínimo de aprovações por etapa, o sistema avança para o próximo estágio 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 serviço de terceiros que ocasionalmente responde com lentidão, causando timeouts que degradam o desempenho da aplicação.
Configuração:
|
Parâmetro |
Valor |
Justificativa |
|
Interface name |
test |
Interface que chama o serviço 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 acima de 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% levarem mais de 1000 ms, o circuit breaker abre. Todas as requisições para a interface test falharão pelos próximos 10 segundos. Após esse período, 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 proveniente de um serviço de terceiros. Quando há um pico de requisições anormais, a degradação do conteúdo prejudica a experiência do usuário.
Configuração:
|
Parâmetro |
Valor |
Justificativa |
|
Interface name |
test |
Interface que chama o serviço 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 pelos próximos 10 segundos. Após esse período, 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
Escolha 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 primário, como em chamadas para serviços de terceiros não confiáveis.
Defina 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 um valor suficientemente alto 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 serviços que se recuperam de forma binária — ou funcionam completamente ou não funcionam.
Já a Progressive recovery é mais segura para serviços que podem estar parcialmente recuperados, pois evita que um fluxo repentino de tráfego sobrecarregue um serviço que acabou de voltar a ficar online.
Verifique se uma regra está ativa
Após salve 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 visualize 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 confirme se a regra dispara corretamente.
Tópicos relacionados
Configurar regras de limitação de taxa para controlar as taxas de requisição além do circuit breaking.