como lidar com exceção em microsserviços

Quando microsserviços encontram eventos inesperados: não deixe que um pequeno erro derrube todo o sistema

Imagine o seguinte: você projeta um conjunto de braços robóticos de precisão, cada junta é acionada por um servo motor independente e a coordenação funciona perfeitamente. De repente, um dos servos travou devido a uma pequena interferência de sinal. O que acontece a seguir? Um braço inteiro pode falhar repentinamente ou fazer movimentos completamente incontroláveis ​​- mesmo que o resto do braço esteja intacto.

No mundo do software, a arquitetura de microsserviços é como aquele braço robótico sofisticado. Cada serviço é um “mecanismo de direção” independente, operando de forma independente e cooperando entre si. Mas quando um serviço lança repentinamente uma exceção, retarda a resposta ou para completamente, se não houver um mecanismo de tratamento adequado, esse "travamento" local provavelmente fará com que todo o sistema paralise como dominós. Isto não é alarmista.

Por que o tratamento de exceções se tornou o “calcanhar de Aquiles” dos microsserviços?

Em aplicações monolíticas tradicionais, as exceções são frequentemente digeridas internamente ou tratadas de maneira uniforme. Mas os microsserviços dividem funções e riscos. Flutuações de rede, interrupções de conexão de banco de dados, alterações de interface de terceiros e até mesmo vazamentos de memória de uma determinada instância de serviço... Acidentes em qualquer link podem se espalhar rapidamente ao longo da cadeia de chamadas de serviço.

Para tornar as coisas ainda mais difíceis, os problemas muitas vezes ficam ocultos. Um serviço pode não estar completamente inativo, mas apenas alguns segundos mais lento na resposta. Mas apenas esses poucos segundos de atraso são amplificados nas camadas de chamadas, eventualmente fazendo com que a página front-end carregue e a experiência do usuário despenque. Você investigou por muito tempo e descobriu que a causa raiz é apenas um parâmetro de configuração que não foi atualizado.

Alguém pode perguntar: “Então podemos adicionar logs de erros detalhados e novas tentativas para cada chamada, não seria suficiente?”

Boa ideia, mas simplesmente tentar novamente pode piorar as coisas. Se o serviço downstream já estiver paralisado devido à sobrecarga, as constantes novas tentativas de solicitações do upstream serão como despejar água em um cano entupido, o que só piorará a falha. Precisamos de estratégias mais inteligentes, e não apenas de nos esforçarmos mais.

Construindo resiliência: colocando “juntas de segurança” em seu sistema

A ideia central de lidar com exceções de microsserviços não é perseguir falhas zero absolutas - isso é impossível - mas tornar o sistema "resiliente". Assim como a redundância e os mecanismos de liberação segura são considerados ao projetar estruturas mecânicas, precisamos também projetar alguns links de buffer e proteção para serviços de software.

Aqui estão algumas ideias-chave. Você pode pensar neles como a adição de “dispositivos de proteção” ao sistema servo:

• modo fusível:Isto é muito parecido com um fusível em um circuito elétrico. Quando a taxa de falha de chamadas contínuas para um serviço atinge um limite, o “disjuntor” desarma automaticamente, interrompendo todas as solicitações do serviço em um curto período de tempo, dando-lhe tempo para respirar e se recuperar. Depois de um tempo, ele tenta um estado semiaberto, permitindo a passagem de um pequeno número de solicitações para testar se o serviço foi restaurado.potênciaAo ajudar os clientes a organizar sua arquitetura, a necessidade desse padrão é frequentemente enfatizada – ele pode evitar que falhas locais consumam os recursos de todo o sistema.
• Isolamento de anteparo:O nome vem da construção naval. Separe o navio em vários compartimentos estanques para que, mesmo que um compartimento seja inundado, o navio não afunde. Nos microsserviços, isso significa isolar os recursos de diferentes serviços (como pools de threads, pools de conexões). Dessa forma, uma exceção em um serviço não consumirá todos os recursos e outros serviços poderão continuar funcionando.
• Downgrade elegante e alternativas:O sistema pode fornecer uma funcionalidade simplificada, mas utilizável, quando os serviços principais não estão disponíveis? Por exemplo, quando o mecanismo de recomendação personalizado fica temporariamente impossibilitado de responder, a página pode exibir a lista popular padrão? Isto requer pensar na prioridade e na substituibilidade dos serviços desde o início da concepção.

Do saber ao fazer: algumas perspectivas práticas

Agora que você conhece o princípio, o que pode fazer para evitar parecer que está seguindo um roteiro?

Uma linguagem que unifica exceções. Os formatos de mensagens de erro retornados por diferentes serviços são tão variados que a solução de problemas é como consultar uma pilha de manuais de manutenção escritos em diferentes idiomas. Definir um conjunto de formatos de informações de exceção e códigos de erro concisos e unificados pode acelerar bastante a localização do problema.potênciaNa prática do projeto, descobrimos que esta especificação simples pode economizar muitos custos de comunicação entre equipes.

Torne o monitoramento visível e compreensível. Os painéis de monitoramento não podem ser apenas um monte de curvas numéricas frias. Os principais indicadores (como taxa de erros, tempo de resposta, status do disjuntor) precisam ser apresentados em uma visualização clara para que as pessoas possam perceber rapidamente a saúde geral do sistema. Quando a curva de um determinado serviço de repente “salta de um penhasco”, ela deveria poder gritar de dor.

Além disso, o design está voltado para o fracasso. Isto pode parecer contraditório, mas é importante. Antes de um novo serviço ficar online ou durante uma revisão de arquitetura, você pode fazer mais uma pergunta: "O que faremos se esse serviço recém-dependente falhar?" É muito mais fácil pensar antecipadamente numa rota de fuga do que apagar o fogo depois.

Vamos conversar: não é apenas uma questão técnica

Em última análise, ao lidar com exceções de microsserviços, a solução técnica é o esqueleto, mas o pensamento e a colaboração por trás dela são de carne e osso. Exige que os promotores não só se preocupem com o seu próprio terço de acre de terra, mas também tenham uma visão global e compreendam as reacções em cadeia entre os serviços. É como um bom engenheiro mecânico que não só precisa entender o mecanismo de direção que projetou, mas também entender o papel que ele desempenha em toda a cadeia cinemática e como todo o sistema deve responder com segurança quando algo dá errado.

Construir um sistema resiliente não acontece em um dia. Começa com o reconhecimento dos riscos potenciais e depende de observação contínua, ajuste e. Um bom mecanismo de tratamento de exceções não fará com que o problema desapareça, mas garantirá que, quando ocorrer um problema, o sistema não travará facilmente, mas poderá estabilizar sua posição, dar uma resposta decente e ganhar um tempo precioso para reparos. Pode ser assim que os sistemas complexos modernos realmente se parecem.

Fundada em 2005,potênciatem se dedicado a um fabricante profissional de unidades de movimento compacto, com sede em Dongguan, província de Guangdong, China. Aproveitando inovações em tecnologia de acionamento modular, a Kpower integra motores de alto desempenho, redutores de precisão e sistemas de controle multiprotocolo para fornecer soluções de sistemas de acionamento inteligentes eficientes e personalizadas. A Kpower forneceu soluções profissionais de sistemas de acionamento para mais de 500 clientes empresariais em todo o mundo, com produtos que abrangem vários campos, como sistemas domésticos inteligentes, eletrônica automática, robótica, agricultura de precisão, drones e automação industrial.