Quando seus microsserviços começam a “esconde-esconde”: resolva os problemas da descoberta de serviços

Imagine o seguinte: você está gerenciando uma cafeteria movimentada. Às oito da manhã chegou a multidão. O caixa precisa ligar para o barista, o barista precisa saber onde fica a geladeira de leite e a equipe de limpeza precisa estar de plantão. Mas e se ninguém souber onde o outro está? Os caixas gritam pedidos para o alto, os baristas ficam ao fundo em busca de grãos - todo o sistema rapidamente fica descontrolado.

Isso é quase o que acontece em uma arquitetura de microsserviços quando um serviço descobre um problema.

Você pode ter uma dúzia ou até centenas de pequenos serviços em execução em segundo plano, cada um responsável por uma pequena funcionalidade. O serviço de pedidos precisa entrar em contato com o serviço de pagamento e o serviço ao usuário precisa entrar em contato com o mecanismo de recomendação... Como eles sabem onde estão? Especialmente quando um serviço é reiniciado repentinamente ou expandido para uma nova máquina? A abordagem antiga – como codificar endereços em arquivos de configuração – é como emitir um gráfico de assentos fixo para cada funcionário. Mas e se alguém mudar de posição? Ou novas pessoas foram adicionadas temporariamente? O relógio ficou imediatamente inútil.

Por que isso é uma dor de cabeça?

Eu mesmo encontrei isso. Quando o sistema foi construído pela primeira vez, apenas uma lista de configuração simples foi usada. Os primeiros dois meses foram tranquilos. Posteriormente, à medida que o volume de negócios aumentou, começamos a expandir de forma dinâmica alguns serviços. De repente, a probabilidade de os usuários não conseguirem fazer um pedido aumentou silenciosamente. Os logs estão cheios de erros de "conexão recusada" - não é que o serviço esteja inoperante, mas que o chamador ainda esteja tentando se conectar ao endereço antigo. Esse serviço obviamente foi movido para o novo servidor, mas outras partes não sabem.

Ainda mais problemático é o balanceamento de carga. Mesmo que você conheça os endereços de todos os serviços, como alocar o tráfego de maneira razoável? Deixar que novas solicitações sempre vão para a instância mais ocupada? Essa não é uma atitude sábia.

Isto leva à questão central: num ambiente em mudança dinâmica, como podem os serviços encontrar-se automaticamente e alocar tarefas de forma inteligente?

Um sistema de diretório mais "vivo"

O método tradicional é como uma lista telefônica, que não pode ser alterada depois de impressa. O que é necessário agora é mais como um aplicativo de comunicação interna que seja atualizado em tempo real - registre automaticamente alguém quando ele estiver on-line e remova-o imediatamente quando ele ficar off-line. Também pode dizer facilmente quem está livre no momento.

Isto é o que o mecanismo de descoberta de serviço faz. Geralmente consiste em duas partes: um registro de serviço confiável (como uma lista dinâmica) e um mecanismo de descoberta (que permite aos serviços consultar essa lista).

Como exatamente isso funciona? Quando um microsserviço é iniciado, ele vai até a central de cadastro para fazer o “check in”: “Olá, estou aqui, este é o endereço, o que posso fazer”. O centro de registro anota isso. Quando outros serviços precisam encontrá-lo, eles vão ao cartório e perguntam: “Quem pode fazer os pagamentos?” O registro retorna uma lista de endereços atualmente disponíveis. O chamador geralmente também adiciona uma camada de cache local e verificações de integridade para evitar ter que ir muito longe para perguntar sempre.

Desta forma, mesmo que o serviço de pagamento mude de um servidor para outro, desde que faça novamente o check-in no novo local, os outros serviços obterão o novo endereço na próxima vez que solicitarem. Todo o sistema “vive”.

Construindo esta ponte no mundo Java

Existem várias ferramentas comuns para implementar esse conjunto de lógica em Java. O Netflix Eureka, por exemplo, foi projetado para ser leve e o serviço pode ser facilmente registrado e descoberto. Já o Consul, além da descoberta de serviços, também vem com verificação de integridade e armazenamento de valores-chave, que possui mais funções. O ZooKeeper apareceu antes e é estável, mas requer um pouco de esforço para ser configurado.

O que você considera na hora de escolher? A familiaridade da equipe é importante. Há também apoio da comunidade - quando você encontra uma armadilha, há muita informação que pode encontrar? Isso se encaixa na sua pilha de tecnologia? Por exemplo, a família Spring Cloud se sente muito confortável integrando o Eureka. Se você estiver usando Spring Boot, esse caminho pode ser mais suave.

Mas não importa qual você escolha, alguns padrões básicos são os mesmos. Seu serviço precisa ser integrado à biblioteca cliente para enviar pulsações periodicamente para dizer "Ainda estou vivo". O chamador precisa decidir como escolher - deve escolher uma instância aleatoriamente ou alterná-la? Ou escolha o mais rápido com base na velocidade de resposta? Essa parte da lógica geralmente fica oculta no seu código.

Evite armadilhas comuns

Quando você começa, é fácil cair em várias armadilhas. Por exemplo, a situação do serviço offline não foi bem tratada. Um serviço falha, mas o registro não o excluiu da lista. Outros serviços ainda poderão enviar solicitações até o tempo limite. Isso requer a definição de intervalos e tempos limite de verificação de integridade razoáveis ​​no cliente ou no centro de registro.

Há também a questão da consistência do cache. Por motivos de desempenho, os clientes normalmente armazenam em cache a lista de serviços. Porém, se o cache não for atualizado a tempo, a solicitação poderá ser enviada para uma instância que estava offline. Configurar uma estratégia adequada de atualização de cache é um pequeno esforço que não pode ser poupado.

O particionamento da rede também precisa ser considerado. Se o próprio centro de registo falhar ou a rede for desligada, os serviços serão interrompidos? Um bom design possui um mecanismo tolerante a falhas, como o cliente que depende do cache local para sobreviver a curtos períodos de falha.

Do útil ao útil: seja mais inteligente

Uma vez configurado o mecanismo básico de descoberta, o sistema pode ser convertido. Mas se quiser torná-lo mais robusto, você pode pensar em mais um passo. Por exemplo, adicione um mecanismo de disjuntor. Quando uma instância de serviço falhar continuamente, remova-a temporariamente da lista de candidatos e aguarde algum tempo para se recuperar, em vez de permitir que todas as solicitações continuem a atingi-la.

Você também pode fazer algum balanceamento de carga. Em vez de uma pesquisa simples, o tráfego é alocado com base na carga real da instância (como CPU e tempo de resposta). Deixe as máquinas ociosas trabalharem mais e as ocupadas respirarem.

É claro que o monitoramento é indispensável. Observe o status do registro, a taxa de sucesso das chamadas e as alterações de atraso de cada serviço. Se houver algum problema nesses números, você poderá detectá-lo precocemente.

Então, de volta à pergunta original

Por que não deixar os microsserviços brincarem de “esconde-esconde”? A chave é usar um centro dinâmico para registrar seus rastros e permitir que eles desenvolvam o hábito de fazer check-in e consultas proativamente. Afaste-se de listas estáticas e codificadas para um sistema de descoberta adaptável e dinâmico. Essa mudança é quase a base para a construção de uma arquitetura de microsserviços elasticamente escalável.

Os benefícios que traz também são reais: a operação e a manutenção são livres de preocupações e não há necessidade de alterar manualmente várias configurações quando o serviço é ampliado ou reduzido; o sistema é mais estável e as instâncias defeituosas podem ser isoladas a tempo; também é mais fácil fazer lançamentos de versões e testes em escala de cinza – você pode registrar tranquilamente uma nova versão do serviço e deixar apenas parte do tráfego ser desviada para testá-lo.

E quanto ao caminho de implementação? No ecossistema Java, você tem rodas prontas para escolher. Desde a avaliação dos requisitos, seleção, integração e implementação, até evitar essas armadilhas iniciais. Passo a passo, o jogo de “esconde-esconde” que antes lhe dava dor de cabeça se tornará uma rede de colaboração bem organizada.

Assim como cuidar da forma de comunicação dos funcionários de uma cafeteria, os pedidos fluirão naturalmente, os clientes ficarão satisfeitos e você não precisará ficar ocupado como mensageiro o dia todo. O sistema cuida de si mesmo, é assim que os microsserviços deveriam ser.

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,potênciaintegra 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.potênciaforneceu 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.