Quando seu projeto de microsserviço encontra problemas de servo motor

A arquitetura de microsserviços divide grandes sistemas em pequenos serviços independentes, o que é uma abordagem inteligente. Mas muitas vezes nos concentramos apenas na "divisão" e na "colaboração" no nível do software, mas esquecemos que as unidades de hardware que realmente acionam o equipamento - como servo motores e engrenagens de direção - são a chave para, em última instância, transformar instruções digitais em ações físicas. Se a resposta do hardware não consegue acompanhar o ritmo do software, por mais bonito que seja o diagrama da arquitetura, é apenas uma ideia no papel.

Como o hardware e o software “conversam”?

Alguém pode perguntar: o servo motor não apenas recebe o sinal e depois gira? Quanto isso tem a ver com arquitetura de microsserviços? Na verdade, isso importa muito. Na prática tradicional, muitas vezes concentramos o controle de hardware em um serviço. No entanto, à medida que o sistema se expande, este serviço pode facilmente tornar-se inchado. Quando um motor precisar ajustar seus parâmetros, todo o módulo de controle poderá ser afetado. A ideia dos microsserviços é: Por que não separar o controle de cada hardware chave em um pequeno serviço? Deixe que um serviço dedicado gerencie um motor dedicado, que é responsável apenas por receber instruções e feedback de status. Se houver algum problema, isso não afetará outros equipamentos. Assim como uma banda com uma clara divisão de trabalho, cada músico cuida apenas da sua parte, mas juntos criam uma peça harmoniosa.

Mas embora a ideia seja boa, existem vários obstáculos na sua implementação: Primeiro, os protocolos de hardware são frequentemente relativamente fixos. Como fazer com que ele se adapte de forma flexível à invocação de diferentes serviços? Segundo, em cenários com elevados requisitos de tempo real, o atraso na comunicação entre os serviços retardará a resposta do motor? Terceiro, se um determinado serviço motor falhar, o sistema pode mudar rapidamente para um plano de backup para evitar o desligamento de toda a linha de produção?

Uma ideia de integração mais "pé no chão"

Em vez de forçar o hardware a se adaptar à arquitetura de software, é melhor mudar a ideia - construir uma camada de “tradutor” entre o hardware e os microsserviços. Esta camada de tradução pode compreender as instruções de cada serviço e convertê-las em uma linguagem que o motor possa entender; também informa o status do motor em tempo real para informar ao serviço upstream: "As instruções foram recebidas e estão sendo executadas." Desta forma, o nível de software pode continuar a desfrutar da flexibilidade proporcionada pelos microsserviços, enquanto o nível de hardware mantém uma lógica de condução estável e confiável. Ambos os lados desempenham suas próprias funções e estão conectados suavemente através da camada intermediária.

potênciaAo resolver esses problemas, é comum trabalhar de trás para frente a partir de cenários reais. Por exemplo, num cenário de colaboração de braços robóticos, os servos de cada articulação podem ser controlados por diferentes serviços. Primeiro, garantiremos que o serviço de controle de cada servo seja leve e focado o suficiente e, em seguida, coordenaremos sua sequência de ações por meio de um canal de mensagens unificado. Em vez de depender de um agendamento central complexo, os serviços podem notificar uns aos outros por meio de eventos padrão: “Estou no lugar, é a sua vez”. O resultado é uma resposta mais rápida, menor acoplamento e uma atualização do serviço sem desligar todo o braço robótico.

Por que os detalhes determinam o sucesso ou o fracasso?

Na arquitetura de microsserviços, todos muitas vezes prestam atenção à divisão de serviços, ao design de API e à implantação em contêineres - estes são, obviamente, importantes. Mas o que realmente afeta a experiência do usuário é muitas vezes esse aspecto: se o dispositivo se move com precisão e em tempo hábil. O controle do servo motor é essencialmente uma busca dupla de precisão e desempenho em tempo real. Precisão significa que cada rotação deve parar na posição exata; tempo real significa que o atraso desde a emissão da instrução até o início da ação é pequeno o suficiente. Na arquitetura de microsserviços, isso requer uma estreita cooperação entre comunicação de rede, serialização e emissão de instruções de driver. Se algum link estiver lento, o que o usuário poderá ver é meio segundo de hesitação do braço robótico.

Portanto, o tempo de resposta do hardware deve ser levado em consideração durante a fase de projeto. Por exemplo, definir uma prioridade mais elevada para os principais serviços de controlo de motores e atribuir uma ligação de comunicação mais estável; ou reserve instruções de cache leve localmente para que o motor possa continuar a executar ações inacabadas mesmo se a rede flutuar brevemente. Esses detalhes não aparecerão no diagrama de arquitetura, mas afetam diretamente a “sensação” do sistema.

Torne o sistema "vivo"

Um bom sistema deve ser capaz de respirar e se adaptar. A arquitetura de microsserviços oferece flexibilidade de software, e unidades de hardware, como servomotores e engrenagens de direção, podem realmente ter flexibilidade semelhante por meio de pacotes razoáveis ​​orientados a serviços. Quando a carga de um determinado motor aumenta repentinamente, seu serviço de controle pode enviar ativamente um sinal de “solicitação para desacelerar” ao upstream; quando o sistema detecta que um determinado grupo de ações é repetido com frequência, ele pode comandar automaticamente uma sequência para reduzir o movimento ineficaz do motor. O hardware não é mais um terminal que executa comandos rigidamente, mas se tornou um nó inteligente que pode fornecer feedback e ajustes. Essa combinação de design de software e hardware torna todo o sistema verdadeiramente “vivo” e pode não apenas lidar com fluxos de trabalho conhecidos, mas também se adaptar a emergências desconhecidas.

Afinal, a arquitetura técnica serve, em última análise, objetivos reais. Os microsserviços não são um fim, mas um meio; servomotores não são apenas peças, mas uma extensão das capacidades do sistema. Quando os dois encontrarem uma forma adequada de diálogo, você descobrirá que: coisas originalmente complexas tornaram-se mais simples, processos originalmente rígidos tornaram-se flexíveis e aqueles problemas de coordenação de hardware que antes lhe causavam dores de cabeça tornaram-se gradualmente a parte mais estável do sistema. E tudo isso, muitas vezes o ponto de partida é apenas olhar o problema de outro ângulo – começando com uma linha de código, um sinal e uma rotaçã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. 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.