Quando seus servo motores começam a “conversar”: como os microsserviços se comunicam entre si?

Imagine que você está montando um braço robótico, com cada junta controlada por um servo independente. Os motores dos dedos precisam conhecer o ângulo do pulso, e os motores do pulso precisam se coordenar com o cotovelo - como eles “conversam”? No mundo dos sistemas mecânicos, essa conversa geralmente é feita por meio de cabeamento ou controladores centralizados. Mas no mundo digital, quando dois microsserviços precisam colaborar, as coisas se tornam um pouco como ter dois estranhos coordenando suas ações em tempo real em lados opostos do mundo.

A ponte do mecânico para o digital

Em projetos mecânicos, estamos acostumados a utilizar sinais físicos – tensão, pulso, realimentação do encoder. Mas no mundo dos microsserviços, a comunicação torna-se pacotes invisíveis. Algumas pessoas podem pensar diretamente na maneira mais simples: deixar o serviço A chamar diretamente a interface do serviço B. Assim como quando você pressiona um botão, a luz acende. Isso pode funcionar, mas somente se o serviço B estiver sempre disponível, a rede estiver sempre aberta e as velocidades dos dois corresponderem. A realidade é que as redes sofrerão atrasos, os serviços serão reiniciados e o tráfego aumentará. As chamadas diretas muitas vezes se transformam em “Liguei para você, mas você não ouviu”, e então todo o processo fica paralisado.

Portanto, nos últimos anos, todos começaram a mudar seu pensamento - em vez de permitir que os serviços “ligassem” diretamente, deixem-nos “enviar e-mails”. Ou seja, por meio de uma fila de mensagens ou de uma abordagem orientada a eventos, o serviço A envia a mensagem para uma plataforma intermediária e o serviço B a coleta quando estiver livre. É como deixar um bilhete na oficina: “Aviso de temperatura do motor 3, cuide disso”. O colega responsável pelo processamento irá ajustá-lo ao ver a nota, sem se preocupar se as duas pessoas estão presentes ao mesmo tempo.

Em uma analogia mecânica, esse método é um pouco como instalar uma pequena caixa de correio para cada motor. Sua caixa de correio está cheia? Então nenhuma nova mensagem poderá ser salva por enquanto. Mas pelo menos as mensagens não serão perdidas e o sistema ficará mais desacoplado. Mas surge uma nova questão: e se houver demasiadas “notas de papel” para manusear? Se uma mensagem for particularmente urgente, como posso entrar na fila?

entrarpotênciaperspectiva de solução

existirpotênciaEm nossa prática técnica, descobrimos que os projetos iniciais de muitos clientes são como agrupar todos os fios - pode funcionar a curto prazo, mas a manutenção é uma bagunça. A comunicação entre microsserviços não deveria ser tão frágil. Tendemos a nos orientar para um modelo mais próximo do “reflexo neural”: assíncrono, orientado a eventos, mas com baixa latência no caminho crítico.

Por exemplo, você tem um serviço que coleta dados de vibração do servo motor e outro serviço que é responsável pela manutenção preditiva. O serviço de dados de vibração não precisa esperar a resposta do serviço de previsão. Basta enviar os pacotes de dados, marcar a prioridade e seu trabalho estará concluído. O serviço de previsão pode recuperar os dados após alguns milissegundos ou pode processá-los mais tarde devido aos poucos recursos de computação. Mas o serviço de dados vibratórios não bloqueia, ele continua coletando o próximo grupo. Todo o sistema é como uma oficina flexível, com cada estação de trabalho operando de forma autônoma e colaborando indiretamente através de uma esteira transportadora (pipeline de mensagens).

Alguém perguntou: "E se o próprio canal de mensagens falhar?" Isso remete ao design redundante. Uma boa arquitetura de comunicação de microsserviços permitirá o backup de mensagens em vários caminhos, como hastes de transmissão de backup em um sistema mecânico.potênciaAo ajudar os clientes na implantação, muitas vezes é sugerido um modelo de "publicação/assinatura" - um serviço publica um evento e vários serviços relacionados podem assiná-lo e processá-lo conforme necessário. Isso evita um único ponto de dependência e facilita o dimensionamento.

Por que isso parece simples, mas é tão fácil de fazer?

Porque os cenários da vida real raramente são tão simples como “dois serviços”. Na maioria das vezes, existem dezenas ou mesmo centenas de serviços interligados. A aciona B, B aciona C e D, e o resultado de C flui de volta para A... Neste momento, se toda comunicação usar espera síncrona, o sistema será como uma junta apertada por muitos parafusos, rígida e propensa ao colapso.

Por isso, costumamos brincar que projetar comunicação de microsserviços é como organizar uma dança para um grupo de servos - você não pode deixar cada motor esperar pelo sinal completo de um motor, caso contrário a dança ficará presa. Você tem que deixá-los ouvir a mesma música (fluxo de eventos), cada passo na mesma batida, ocasionalmente olhar para a localização de seus companheiros (consulta de status), mas correr de forma autônoma na maior parte do tempo.

No Kpower, primeiro ajudaremos os clientes a desenhar diagramas de fluxo de dados, assim como desenhar diagramas de transmissão mecânica. Quais comunicações exigem sincronização em tempo real (como sinais de desligamento de emergência), quais podem tolerar atrasos (como uploads de log), quais garantem a ordem (como instruções passo a passo) e quais podem ser processadas fora de ordem (como amostragem de dados). Após categorizar, combine diferentes protocolos e ferramentas de comunicação. Esta não é uma abordagem única, mas, como um conjunto de engrenagens, cada ponto de engate deve ter o perfil e a velocidade corretos do dente.

Às vezes, menos é mais

Curiosamente, quando você pergunta a projetistas mecânicos experientes como simplificar o sistema, eles costumam dizer: “Reduza a ligação de transmissão”. O mesmo acontece na comunicação de microsserviços – nem todos os serviços precisam se comunicar diretamente. Os caminhos podem ser convergidos por meio de um serviço de agregação (gateway API) ou barramento de eventos. É como adicionar uma caixa de distribuição a máquinas complexas, tornando a linha principal mais clara e facilitando a manutenção.

A Kpower descobriu durante a revisão do projeto que uma camada de comunicação superprojetada costuma ser mais problemática do que insuficiente. Por exemplo, para “seguro”, uma fila de mensagens é adicionada entre cada serviço. Como resultado, mais de uma dúzia de cadeias de mensagens precisam ser rastreadas durante a operação e manutenção. Posteriormente, ajustamos nossa estratégia para dar prioridade à garantia de alta confiabilidade dos links principais, enquanto os links não essenciais podiam ser rebaixados. Na verdade, isso torna o sistema mais robusto, assim como uma boa máquina - usando aço temperado para peças principais e ligas comuns para peças secundárias, o desempenho geral de custos e a confiabilidade são melhorados.

Então, da próxima vez que você se preocupar em como os microsserviços “conversam”, você também pode pensar em como projetar a colaboração mecânica: esclarecer a divisão do trabalho, estabelecer um protocolo de sinal claro, deixar algum espaço de buffer e adicionar mais segurança para peças-chave. Deixe o resto para parceiros como a Kpower para ajudá-lo a transformar seu projeto em uma realidade estável. Afinal, seja maquinário ou código, uma boa comunicação é a base para um bom funcionamento.

Fundada em 2005, a Kpower tem se dedicado a ser 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.