Quando seu projeto de servo motor atende microsserviços: por que você precisa de uma fila de mensagens e nossa prática

Imagine isto: você está depurando um braço robótico, com cada junta controlada por um servo motor independente. Esses motores precisam trabalhar juntos em tempo real, mas as instruções vêm de diferentes microsserviços – um calcula a trajetória, um lida com o feedback do sensor e outro gerencia a lógica de segurança. De repente, um determinado serviço fica lento por alguns milissegundos devido à alta carga, e toda a operação começa a congelar ou até mesmo ficar fora de sincronia. Naquele momento, você achou que seria ótimo se esses serviços pudessem tornar as conversas mais “tranquilas”?

Na verdade, este não é apenas um problema encontrado pelo controle mecânico. Qualquer sistema dividido em microsserviços enfrenta desafios semelhantes: como comunicar entre serviços de forma confiável e eficiente? Como garantir que os dados não sejam perdidos, que o pedido não seja confuso e que possa suportar tráfego repentino?

Atingimos esse obstáculo há alguns anos, quando estávamos atualizando uma linha de classificação automatizada. Os métodos tradicionais, como chamadas HTTP diretas, tornam-se frágeis à medida que os serviços aumentam. Quando um serviço fica inativo, outros serviços no link também são afetados; assim que chegam os picos de solicitações, o sistema começa a entrar na fila e o desempenho em tempo real fica fora de questão. Precisamos de um mecanismo que seja mais parecido com uma “esteira transportadora” – coloque os dados nele e deixe que os locais onde eles são necessários acessem-nos em seu próprio ritmo, sem bloquear uns aos outros.

Então, começamos a procurar e finalmente apresentamos o Kafka.

O que é Kafka? Pense nisso como uma linha de montagem inteligente e de alta velocidade

Se você usar uma cena familiar como analogia: Kafka é como a esteira interminável de uma fábrica. Cada microsserviço pode ser considerado uma estação de trabalho. A estação A coloca os produtos semiacabados (mensagens) na esteira transportadora e as estações B e C os levam para processamento a qualquer momento, conforme necessário. A própria correia transportadora continua funcionando. Mesmo que uma determinada estação seja reparada temporariamente, os produtos semiacabados não desaparecerão, mas apenas esperarão silenciosamente na linha até que uma estação assuma o controle.

Isso resolve várias dores de cabeça:

• dissociação: Os serviços não “chamam” mais diretamente, mas são transferidos por meio de uma esteira transportadora. O remetente descarta a mensagem e vai embora sem saber quem vai cuidar dela ou quando.
• buffer: Quando o upstream gera repentinamente uma grande quantidade de dados (como um sinal repentino de alta frequência de um sensor), a correia transportadora pode transportá-los temporariamente e o downstream pode digeri-los de acordo com suas próprias capacidades para evitar ser sobrecarregado.
• confiabilidade: As mensagens são persistidas na esteira e mesmo que alguns serviços sejam reiniciados, os dados não serão perdidos.
• sequencialidade: Em uma esteira transportadora, a ordem dos itens é fixa. Isto é crítico para dados sensíveis à sequência, como instruções de controle de motor.

Como podemos usá-lo? Um experimento não linear

No início, algumas pessoas da equipe ficaram preocupadas: “Isso é muito complicado? Temos que manter um novo conjunto de middleware”. Mas, na prática, descobrimos que se tratava mais de blocos de construção do que de um arranha-céu.

Não começamos com uma revisão completa. Em vez disso, escolhemos um link com o ponto problemático mais óbvio para testar as águas – o monitoramento do status do braço robótico. Acontece que os dados de status são enviados de um serviço para outro e muitas vezes são perdidos devido a instabilidades na rede, fazendo com que o painel de monitoramento fique “fragmentado” de tempos em tempos. Simplesmente estabelecemos um tópico Kafka (que pode ser entendido como uma esteira transportadora dedicada), deixamos o serviço de publicação de status gravar dados aqui e o serviço de monitoramento os assina. Quase imediatamente, o problema da fragmentação desapareceu. Porque mesmo que o serviço de monitoramento esteja temporariamente offline, ele ainda poderá ler todas as atualizações de status não processadas do ponto de interrupção após a reinicialização.

Este pequeno sucesso nos deu confiança. Em seguida, migramos gradativamente o fluxo de instruções de pedidos e o fluxo de eventos de alarme. Gradualmente, o fluxo de dados de todo o sistema torna-se claramente visível, como se olhasse para um mapa logístico em tempo real. À primeira vista fica claro quais linhas estão congestionadas e quais estão ociosas.

Alguns fragmentos e sentimentos reais

É claro que houve alguma exploração no processo. Por exemplo, certa vez nos deparamos com "Em quantas esteiras transportadoras (tópicos) devemos dividir?" Posteriormente, descobrimos que, assim como em um workshop, todas as partes não serão misturadas em uma linha e é mais razoável gerenciá-las separadamente por domínio de dados e urgência. As instruções de controle do motor exigem baixa latência e uma linha separada de alta velocidade; os dados de log e auditoria são grandes em volume, mas têm baixos requisitos em tempo real; portanto, use outra linha de alta capacidade. Cada um segue seu caminho sem interferir um no outro.

Algumas pessoas também perguntam: "E se a própria correia transportadora quebrar?" O design distribuído do Kafka o torna inerentemente redundante. Os dados serão copiados em vários nós. Se um único nó falhar, outros nós poderão assumir o controle imediatamente e o serviço será quase imperceptível. É como colocar um motor sobressalente na transmissão.

Olhando agora para trás, a introdução de Kafka não tornou o sistema mais “complexo”, mas, em vez disso, tornou ordenado o caos originalmente invisível. A tensa relação de acoplamento direto entre microsserviços foi relaxada. Cada serviço pode se concentrar mais em sua própria lógica e a flexibilidade de toda a arquitetura foi significativamente aprimorada. Quando a linha de produção precisa ser ampliada e uma nova estação de inspeção é adicionada, basta inscrever o novo serviço no Tópico correspondente, que é tão simples quanto adicionar uma nova estação ao lado da correia transportadora, sem perturbar outras peças.

Vamos falar sobre escolhas

Existem muitas ferramentas de fila de mensagens no mercado, por que escolher o Kafka? Para nós, valorizamos seu desempenho equilibrado em alto rendimento, persistência e garantias de sequência. Pode não ser aquele com os recursos mais chamativos, mas é sólido o suficiente para cenários industriais que exigem processamento estável de fluxos de dados. É claro que nenhuma ferramenta é uma solução milagrosa e sua curva de aprendizado e custos de operação e manutenção exigem investimento. Mas se seus microsserviços também começarem a “agir descoordenadamente” devido a problemas de comunicação, pode valer a pena considerar a instalação de um conjunto dessas “correias transportadoras inteligentes” no sistema.

Afinal, uma boa tecnologia deve ser como uma transmissão mecânica confiável: silenciosa, precisa e facilitando a colaboração complexa.

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.