comunicação kafka entre microsserviços

Naquela noite, o alarme da linha de montagem soou novamente.

Você fica na oficina, ouvindo os cliques descoordenados do braço robótico. Os dados de várias unidades servo são como pipas com cordas quebradas - as instruções foram enviadas, mas uma determinada junta está meio batida lenta. A temperatura não é anormal e a carga é normal, mas toda a trajetória do movimento está ligeiramente desviada, resultando na necessidade de retrabalho de um lote de peças.

Depois de verificar várias vezes, descobri que o problema não estava no motor em si, mas na comunicação entre vários módulos de controle - os dados foram perdidos por alguns milissegundos e as ações não puderam ser conectadas.

Desvios de controle como esse causados ​​por “comunicação não confiável entre microsserviços” são bastante comuns em sistemas mecânicos e de automação. Especialmente quando múltiplas unidades servo, sensores e CLPs precisam trabalhar juntos, se o fluxo de dados for atrasado, perdido ou fora de sequência, todo o sistema poderá apresentar instabilidade visível ou invisível.

Neste momento, você pode precisar de uma arquitetura de comunicação mais robusta para enviar dados em tempo real de forma estável, um após o outro, como peças em uma esteira transportadora, para que ninguém seja “deixado para trás” no meio do caminho.

E Kafka pode ajudar.

Não é mágica, apenas uma ideia de design: deixe os dados serem coletados, distribuídos e retidos em um fluxo contínuo, e cada microsserviço poderá acessá-los sob demanda, sem bloquear uns aos outros. Você pode pensar nisso como uma correia transportadora ordenada e de alta velocidade - todos os dados de posição do servo motor, feedback de torque e informações de temperatura são colocados em "pacotes de dados" um por um. Qualquer módulo que necessite desses dados pode retirar a embalagem necessária da esteira a qualquer momento sem afetar a leitura dos demais módulos.

Desta forma, mesmo que um serviço esteja temporariamente ocupado ou reiniciado, o fluxo de dados não será interrompido, apenas aguardará silenciosamente na esteira até ser atendido.

Quais são os benefícios? É óbvio.

Por exemplo, você pode expandir o sistema de forma mais flexível – adicionar uma unidade de monitoramento sem religar ou interromper as comunicações existentes, apenas deixá-la começar a ler informações do mesmo fluxo de dados. Ou quando um determinado módulo de controle precisa de dados históricos, ele pode rastrear diretamente os pacotes de dados anteriores sem ter que parar todo o sistema.

É claro que a implementação requer algumas considerações de design. Por exemplo, você precisa planejar a divisão dos tópicos de dados - cada motor deve ser um tópico separado ou deve ser dividido por tipo de dados? A política de retenção de dados deve ser definida de acordo com os requisitos em tempo real do cenário real. Há também a configuração de grupos de consumidores para garantir que os principais serviços de controle possam obter primeiro os dados mais recentes, enquanto os serviços de análise podem digerir lentamente os dados existentes.

Isso parece um pouco abstrato, mas se você colocar em um cenário real, será fácil de entender.

Suponha que você tenha uma linha de montagem e seis servo-eixos precisem trabalhar juntos para completar um movimento preciso. Se a comunicação tradicional ponto a ponto for usada, uma vez que a rede oscila entre o PLC de controle principal e um determinado driver, toda a cadeia de ação pode ficar desequilibrada. Se Kafka for usado como data center e cada eixo publicar seus próprios dados de status em tempo real, o PLC de controle principal só precisará assinar esses fluxos de dados para calcular a próxima instrução em tempo real. Mesmo que os dados de um eixo estejam alguns milissegundos atrasados, os outros eixos não ficarão presos - eles continuarão a ajustar de acordo com os dados existentes mais recentes e, em seguida, integrá-los-ão rapidamente quando os dados atrasados ​​chegarem, e a coerência da ação geral será mantida.

Algumas pessoas também perguntam: isso aumentará a complexidade do sistema?

Sim, você precisa gastar mais tempo projetando o fluxo de dados e a arquitetura de implantação no início. Mas, a longo prazo, altera a fiabilidade da comunicação de “depender do estado transitório da rede” para “depender do fluxo de dados persistente”, o que por sua vez reduz o risco de falhas esporádicas. É como se você usasse uma correia transportadora em vez de trabalhadores carregando peças mão a mão - o trilho precisa ser colocado inicialmente, mas uma vez em funcionamento, não é fácil interromper a produção porque a mão de alguém escorrega.

Como começar a usá-lo?

Não existe uma resposta padrão, mas geralmente você pode testá-la a partir de um subsistema. Por exemplo, primeiro deixe o monitoramento de temperatura e o relatório de status do servo passarem pelo fluxo Kafka e mantenha as instruções de controle principais ainda passando pelo canal original em tempo real. Depois de se familiarizar com as características dos fluxos de dados e das ferramentas de monitoramento, você poderá migrar gradualmente mais módulos de dados com requisitos moderados em tempo real. A chave é reservar logs e monitoramento suficientes para que você possa ver claramente se há “bloqueios” ou “vazamentos de pacotes” no fluxo de dados.

Falando nisso, você pode pensar: isso parece mais um trabalho de arquitetura de TI, o que isso tem a ver com controle mecânico?

Na verdade, o relacionamento está cada vez mais próximo. O sistema servo de hoje não é mais um simples ciclo de “execução de instruções”. Precisa integrar mais feedback em tempo real, dados ambientais e indicadores de manutenção preditiva. Se esses dados ainda forem sincronizados um por um através de métodos de comunicação tradicionais, a eficiência e a confiabilidade encontrarão gargalos. Plataformas de streaming de dados como Kafka fornecem uma ideia: tratar os dados como um fluxo contínuo de água em vez de gotículas de água dispersas. Cada parte do sistema pode ser acessada sob demanda, o que pode não apenas desacoplar, mas também manter a sincronização geral.

Claro, tudo isso é inseparável de uma base de hardware estável e confiável. O desempenho dos servomotores e acionamentos ainda é o pré-requisito para tudo isso - assim como uma correia transportadora funcionando suavemente, as peças nela contidas devem ser precisas e fortes.

Portanto, se você também está preocupado com atrasos e perdas de dados na colaboração entre vários dispositivos, você pode querer pensar além da perspectiva de simplesmente olhar para hardware ou redes e pensar se deve projetar um “sistema de transmissão” mais robusto para o próprio fluxo de dados.

Afinal, o que faz o robô se mover suavemente não é apenas a rapidez com que o motor gira, mas também a rapidez com que os dados são executados.

potênciaCom foco em servoacionamento e automação, construímos uma base de controle de movimento mais confiável para você, desde o hardware até o fluxo de dados.

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. 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.