Quando seu projeto de microsserviços C++ encontra problemas de direção: uma nota de resposta informal

Esqueci que dia era, mas estava depurando uma matriz de servos. Os três servomotores deveriam girar sincronizadamente de acordo com as instruções, mas em vez disso pareciam estar dançando seus próprios passos de dança aleatórios. Atraso na comunicação? Tensão instável? Ou há algo errado com a lógica? Olhei para o fluxo de dados na tela e de repente percebi que o problema talvez não fosse com o hardware, mas com os “nervos” que os conectavam.

Somos sempre assim: gastamos muito tempo calibrando com precisão a caixa de direção e projetando a estrutura mecânica para ser forte, mas é fácil ignorar o “cérebro” que faz tudo se mover. Em projetos complexos, especialmente aqueles que envolvem controle em tempo real, as aplicações monolíticas tradicionais são como colocar todas as peças em uma caixa, afetando todo o corpo. Uma pequena alteração em um determinado módulo pode fazer com que todo o sistema precise ser depurado novamente.

O que costumamos fazer quando nos deparamos com essa situação?

A primeira reação da maioria das pessoas é mexer. Adicione um trecho de código tolerante a falhas aqui e ajuste a prioridade do thread ali. Mas você logo descobrirá que isso apenas adia o problema. À medida que os sensores aumentam e a lógica de controle se torna mais complexa, os programas ficam inchados e frágeis. Você não se atreve a atualizar facilmente no início, porque cada compilação e implantação é uma aventura.

Existe uma maneira mais legal? Imagine if the logic that controls the servo motor, the unit that processes sensor data, and the unit that manages motion trajectories can all run like independent Lego modules, focusing on each and talking through a clear interface. Esse é o charme da arquitetura de microsserviços na área de controle embarcado e mecânico.

Mas, falando francamente, construir tal arquitetura em um ambiente C++ é como abrir caminho em uma floresta nos primeiros dias. Você deve considerar o que usar para comunicação entre processos (gRPC? ZeroMQ? TCP simples?), como lidar com a serialização de dados, como isolar erros sem espalhar, sem mencionar a questão básica, mas complicada, de gerenciamento de recursos. Construí-lo do zero levaria pelo menos semanas e envolveria incontáveis ​​ciclos de depuração até altas horas da noite.

Por que você precisa de um bom ponto de partida?

Dito isto, lembrei-me de uma implementação de referência de código aberto que já havia encontrado. Não tem truques, apenas mostra claramente como pode ser a aparência de um aplicativo de microsserviços em C++. Cada serviço tem responsabilidades claras. Por exemplo, o serviço que lida especificamente com a geração de sinais PWM é completamente separado do serviço que analisa instruções de posição. Os dados são transferidos entre eles por meio de mensagens leves. Mesmo que um determinado serviço não responda temporariamente, todo o sistema não irá congelar.

Os benefícios desta estrutura são práticos. Por exemplo, se você precisar adicionar um novo link de feedback do sensor ao braço robótico, não será necessário reconstruir todo o programa. Você só precisa desenvolver um serviço independente para processar os novos dados e, em seguida, conectar-se ao sistema existente por meio da interface estabelecida. Ao atualizar ou depurar uma função específica, você também pode reiniciar o módulo de serviço correspondente de forma independente, sem afetar outras tarefas de controle em execução. Isso significa maior disponibilidade para equipamentos que precisam operar 24 horas por dia.

Certa vez, um amigo perguntou: "Isso seria muito pesado para dispositivos embarcados com recursos limitados?" Esta é uma boa pergunta. A chave está no método de implementação. Processos leves, comunicação eficiente de memória compartilhada e prevenção de sobrecarga desnecessária de serialização - tudo isso pode ser resolvido em uma arquitetura bem projetada. Esse projeto de referência mostra como equilibrar dissociação e eficiência para que os benefícios da modularidade não sejam compensados ​​por perdas de desempenho.

Em que devemos nos concentrar?

Ao observar um exemplo de microsserviço C++, não observe apenas quantos protocolos de comunicação ele implementa. O que é mais importante é se os limites de erro estão claramente projetados. A falha de um serviço afetará outros serviços? O fluxo de dados tem tempo limite razoável e mecanismos de fallback em circunstâncias anormais? Isto é crítico para sistemas que controlam máquinas físicas.

Depois, há observabilidade. Cada serviço pode gerar logs e métricas de status significativos de forma independente? Quando há um desvio no movimento da caixa de direção, você consegue localizar rapidamente o link de processamento de dados que está com problema? Um bom design torna o diagnóstico tão intuitivo quanto olhar para um painel.

É a facilidade de construção e implantação. Ele permite compilar e testar facilmente serviços individuais de forma independente? Todo o sistema pode ser iniciado no ambiente de desenvolvimento ou simulador com um clique? A redução do atrito na implantação permite que você se concentre mais na própria lógica de negócios, ou seja, fazer com que esses motores e estruturas mecânicas funcionem com precisão da maneira esperada.

Um pensamento aleatório

O valor desse repositório de exemplo de código aberto é que ele fornece um ponto de partida para pensar. Você pode discordar de algumas de suas implementações, mas pode evitar a confusão de começar do zero. Assim como um desenho com uma grade de coordenadas desenhada, você pode representar suas necessidades específicas diretamente nele, sem ter que medir novamente as proporções todas as vezes.

Voltando ao problema do servo estar fora de sincronia no início. Mais tarde, descobri que uma tarefa não crítica no circuito de controle principal bloqueava ocasionalmente o envio de instruções em tempo real. Se o sistema fosse modular naquela época, a tarefa não crítica poderia ter sido "atordoada" ocasionalmente em seu próprio mundinho, sem arrastar toda a cadeia de controle de movimento. Para consertar, basta reiniciar esse serviço individual em vez de desligar todo o dispositivo.

Esse pode ser o presente que a arquitetura de software traz aos projetos de hardware: a possibilidade de lidar com a complexidade com tranquilidade. Quando cada componente conhece as suas responsabilidades e tem métodos de comunicação claros, todo o sistema pode demonstrar uma vitalidade flexível e robusta. O que resta é que você pense mais em fazer o mecanismo funcionar perfeitamente - essa é a parte mais divertida, não é?

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.