A confusão dos microsserviços no mundo dos servo motores

Você já olhou para aquele braço robótico desobediente e ficou preocupado? Obviamente o programa está escrito corretamente e as instruções estão corretas, mas quando ele se move, ele congela, responde lentamente e até ocasionalmente “finge ser surdo e mudo”. O velho mestre da oficina balançou a cabeça enquanto segurava um cigarro na boca: “Este sistema é como um ser humano. Uma vez que a mente fica confusa, as mãos e os pés não obedecem ao comando”. O problema por trás disso muitas vezes não é o motor em si, mas os dados e o gerenciamento – aqueles sinais e coordenação invisíveis que bloqueiam seu ritmo no local silencioso.

Quando o hardware encontra a “ilha de informações”

Imagine: existem dezenas de servomotores e servos na oficina, cada um parecendo um trabalhador teimoso trabalhando duro. Cada um deles recebe instruções e dados de feedback, mas não há um “líder de esquadrão” para coordenar. O resultado? O motor A está girando, mas o motor B ainda está lendo a barra; os dados de posição retornam à metade e são substituídos por novas instruções. A manutenção é ainda mais problemática – se você quiser verificar a curva operacional de um determinado equipamento no mês passado, terá que passar por três sistemas de gravação diferentes, e os formatos de dados não se reconhecem.

Não é culpa da máquina. O sistema centralizado tradicional é como usar um caderno grosso para registrar tudo: as palavras são escritas cada vez com mais densidade e a busca fica cada vez mais lenta. Mesmo você não consegue encontrar o que escreveu ontem. E quando a produção precisar mudar e os equipamentos aumentarem, mais cedo ou mais tarde esse “caderno” não poderá ser aberto.

Microsserviços: Atribua um “assistente dedicado” a cada motor

Assim, nos últimos anos, mais e mais pessoas começaram a falar sobre “microsserviços”. Simplificando, é dividir aquele caderno grosso em vários cartões pequenos - cada cartão só pode registrar uma coisa, mas as informações podem ser transferidas rapidamente entre os cartões. Aplicado ao sistema motor, significa que cada dispositivo (ou cada grupo de dispositivos) possui um módulo de serviço independente responsável pelo seu próprio controle, monitoramento e registro de dados. Os módulos comunicam entre si de uma forma leve, tal como os trabalhadores numa oficina que utilizam um walkie-talkie para falar de forma clara e direta.

Os benefícios disso são sentidos quase imediatamente:

• flexível: Quer atualizar a lógica de controle de um determinado motor? Você só precisa atualizar os módulos correspondentes sem desligar e reiniciar todo o sistema.
• claro: ao solucionar problemas, você pode localizar rapidamente qual "cartão de serviço" apresenta o problema, em vez de procurar uma agulha no palheiro entre centenas de milhares de linhas de código.
• Fácil de expandir: Dois novos robôs são adicionados à linha de produção? Basta conectar diretamente o novo módulo de serviço correspondente e quase não há necessidade de modificar o sistema original.

Mas por que alguns ainda estão hesitantes?

Todos entendem o princípio, mas na prática o limite não é baixo. Um amigo que fez uma tentativa semelhante certa vez reclamou comigo: "Os microsserviços são bons, mas foram necessários dois meses apenas para construir o ambiente e projetar o protocolo de comunicação. A pós-manutenção é ainda mais problemática - depois que há mais serviços, o monitoramento, o registro e o rastreamento de falhas se tornam novos problemas."

Este é precisamente o verdadeiro dilema enfrentado por muitas equipes técnicas: os conceitos são avançados, mas as ferramentas não conseguem acompanhar. Até recentemente, estávamos expostos apotênciaCom um conjunto de microsserviços fornecidos com base na plataforma Azure, as coisas começam a parecer diferentes.

Um manual desencadeia mudanças

potênciaA documentação técnica "microsserviços com Azure" foi originalmente compartilhada conosco por um cliente. Capa azul clara, não muito grossa. Antes de abri-lo pensei que fosse mais um manual técnico cheio de código e teoria. Mas depois de ler algumas páginas, me senti completamente diferente.

Ele não fala sobre palavras complicadas como "nativo da nuvem" e "containerização", mas desenha diretamente uma cena: suponha que sua oficina tenha cinco servomotores responsáveis ​​​​pelo manuseio, posicionamento, montagem, inspeção e embalagem. O manual descreve em linguagem simples como estabelecer um serviço independente para cada motor, como deixá-los “falar” através dos serviços básicos do Azure e ainda detalha como definir o formato dos dados e qual é o atraso normal da mensagem.

Ainda mais raro é discutir francamente possíveis problemas que possam surgir. Por exemplo: se a rede ocasionalmente oscilar, como evitar erros de julgamento entre os serviços? Se o serviço de um motor parar repentinamente, como evitar que outros equipamentos sejam afetados? O manual não evita essas “tarefas sujas”, mas em vez disso fornece vários conjuntos de estratégias de enfrentamento, das mais simples às mais complexas, como um velho engenheiro experiente falando com você sobre operações práticas.

Tentativas imperfeitas e progresso visível

Seguimos as instruções do manual e conduzimos experimentos em pequena escala - usando três servos para construir uma linha de montagem simples com garras. Foi realmente difícil nos primeiros dois dias: o registro do serviço ocasionalmente expirava e os registros de log não estavam organizados. Mas no terceiro dia, depois de ajustar alguns parâmetros, os efeitos começaram a aparecer.

O mais intuitivo é a velocidade de resposta. No passado, sob controle centralizado, demorava cerca de 100-150 milissegundos desde a emissão de um comando de ação até a resposta de todos os motores (ainda havia flutuações no meio). E agora? Cada servo recebe comandos de forma independente, e a resposta média está dentro de 50 milissegundos, e a curva é muito mais suave. A visualização de dados também se tornou simples: a temperatura operacional, a curva de carga e o histórico de alarmes de cada dispositivo podem ser visualizados em tempo real em uma página de monitoramento independente, eliminando a necessidade de peneirar manualmente registros mistos.

Um colega que participou do teste disse com um sorriso: “Parece que uma secretária é designada para cada máquina”. Embora a metáfora não seja rigorosa, o estado de clareza e organização e cada um desempenhando as suas próprias funções é de facto difícil de proporcionar na arquitectura tradicional.

Por que Azure? Por que escolher este guia?

Existem muitas plataformas no mercado que oferecem suporte a microsserviços.potênciaPor que escolher o Azure como base? O manual não o promove deliberadamente, mas lista objetivamente algumas considerações práticas: compatibilidade com os sistemas existentes da empresa (o ambiente de TI de muitas fábricas já é parcialmente baseado em sistemas Microsoft), componentes pré-fabricados relativamente ricos do Azure no campo da IoT industrial e custo - para aplicações de pequeno e médio porte, seu método de faturamento em camadas é muitas vezes mais econômico.

O valor do manual em si reside no fato de que ele não é apenas uma instrução operacional, mas também um conjunto de estruturas de pensamento. Ele ensina como “desmontar” um sistema mecânico complexo em unidades de microsserviços e como manter a eficiência geral da colaboração após a divisão. Esse tipo de pensamento pode até ser transferido para outros projetos.

É claro que nenhuma ferramenta é uma solução mágica. A arquitetura de microsserviços trará novas complexidades, como maior dependência da rede e maior dificuldade no monitoramento distribuído. O manual também lembra claramente: nem todos os cenários são adequados para microsserviços imediatos. Para sistemas pequenos com pequeno número de dispositivos e lógica simples, a arquitetura tradicional pode ser mais econômica; mas para situações com muitos dispositivos, lógica complexa e expansões posteriores frequentes, as vantagens deste método serão verdadeiramente destacadas.

Escrito em: A tecnologia é um meio, não um fim

Ao se comunicarem com a equipe técnica da Kpower, eles enfatizaram repetidamente: “O que oferecemos não é um conjunto fixo, mas um caminho comprovado”. Esta afirmação parece modesta, mas é verdade. O maior medo na área industrial é falar no papel - por mais sofisticada que seja a ideia, se não for adaptada ao ambiente da oficina, tudo será conversa fiada.

Voltemos ao problema do braço do robô ficar preso no início. Olhando para trás agora, a razão pode não ser que o motor não seja potente o suficiente ou que o programa esteja escrito incorretamente, mas que o “método de cooperação” de todo o sistema seja antigo. Tal como acontece com um grupo de pessoas que trabalham em conjunto, se todos tiverem de esperar que o líder do grupo fale antes de poderem agir, a eficiência naturalmente não será elevada. O que os microsserviços desejam é permitir que cada membro atue de forma autônoma sob regras claras, mantendo a sincronização geral.

O manual azul claro está agora na mesa da nossa oficina e os cantos das páginas já estão enrolados. Não resolve todos os problemas, mas abre uma porta – uma porta que torna o hardware mais inteligente, os dados mais suaves e a manutenção mais fácil. Talvez sua oficina também precise dessa chave.

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.