Implementando o Circuit Breaker Pattern – Parte 1

Fala Galera,

Estou criando uma série de artigos para explicar o conceito de Circuit Breaker, este padrão está se tornando muito comum em cenários de micro-serviços aonde temos chamadas a serviços ou recursos externos que podem entrar em estado de falha, saber como tratar as exceções e criar serviços resilientes a falha nos dias de hoje se torna cada mais vez necessário e nesta série de artigos vou abordar como podemos usar o Pattern Circuit Breaker.

Neste primeiro artigo estarei mostrando os principais conceitos desse pattern e na segunda parte estaremos implementando o nosso Circuit Breaker e por último estarei mostrando componentes que implementam o Circuit Breaker Pattern

Em um ambiente distribuído temos diversas chamadas a recursos externos e claro estes recursos externos podem entrar em estado de falha, essas falhas podem ser por exemplo uma rede lenta, timeouts ou uma implementação errada causando status code 500.

Essas falhas na maiorias das vezes são corrigidas em um espaço curto de tempo e uma aplicação robusta deve saber lidar com essas situações criando uma estratégia de repetição caso um serviço entre em estado de falha.

O Circuit Break Pattern tem uma proposta diferente de um Retry Pattern. O Retry Pattern habilita uma aplicação a fazer diversas tentativas no qual em um determinado momento a chamada será bem-sucedida.

O Circuit Break Pattern previne aplicações de fazer chamadas a operações que estão em estado de falha. Uma aplicação pode combinar os dois Pattern usando o Retry Pattern e o Circuit Break Pattern e essa junção é a mais comum de ser feita.

O Circuit Breaker Pattern

O Circuit Breaker atua como um proxy em operações que podem falhar. Esse proxy monitora o número de falhas ocorridas em uma chamada e deve decidir se permite que a operação continue ou retorne uma exceção imediatamente.

O proxy na realidade é uma maquina de estado com 3 estágios que imitam um disjuntor elétrico de uma casa que no caso de falha o disjuntor abre o circuito não causando danos a equipamento eletrônicos cortando a passagem de eletricidade e quando está tudo ok ele fecha o circuito e deixa a corrente elétrica passar.

• Fechado: Uma chamada para um serviço é feita, o proxy mantém a contagem do número de falhas recentes e caso a chamada não for bem-sucedida, o proxy aumentará a contagem de falhas. Caso a contagem exceda o limite em um determinado período de tempo, o proxy entrará em Circuito Aberto.

• Aberto: A chamada para um serviço falha imediatamente e uma exceção é retornada

• Entreaberto: O estado de entreaberto é quando um número limitado de chamadas a um serviço for feito e caso forem bem-sucedidas o proxy irá considerar que o problema foi corrigido e mudará o estado para Fechado. Se alguma operação falhar, o proxy irá considerar que ainda estamos com falha e voltará o estado para Aberto. 

O estado Entreaberto é útil para impedir que um serviço que acabou de entrar no ar seja bombardeado com solicitações de forma repentina.

Considerações

Alguns pontos que devemos considerar quando vamos utilizar o Circuit Breaker Pattern

• Tratamento de Exceção: Sua aplicação deve estar preparada para tratar as exceções geradas pelo Circuit Breaker.
• Registro em Log: O Circuit Breaker deve logar toda a atividade gerenciada por ele tantos as solicitações com falha e as bem-sucedidas.
• Capacidade de Recuperação: O Circuit Breaker deve ter capacidade de recuperação, ele deve ser inteligente o suficiente saber quando mudar de estado, por exemplo se o circuito estiver aberto por muito tempo, ele pode estar gerando exceções erradas pois é possível que o serviço com problema já esteja em normal funcionamento.
• Simultaneidade: O Circuit Breaker pode e deve ser acessado por diversas instâncias simultâneas. A implementação do Circuit Breaker não deve bloquear chamadas a serviços e nem criar overhead em chamadas
• Reprodução de Falhas : O Circuit Breaker no seu estado aberto em vez de simplesmente soltar uma exceção, ele deverá também registrar todo o detalhe da solicitação e a exceção do causadora do evento.

Quando usar esse Padrão

• Quando temos um serviço que tem que fazer chamadas a serviços externos

Quando não usar esse Padrão

• Para tratar de recursos locais como acesso a base de dados locais, estrutura em memória, caches e afins.
• Para substituir o tratamento de exceções lógicas do seu serviço.

E assim chegamos ao fim do primeiro artigo da série sobre Circuit Breaker, no próximo estaremos implementando nosso Circuit Breaker e entendendo mais ainda o seu funcionamento

Abs e até o próximo