Quando o sistema do servidor encontra os microsserviços: divida essas coisas

Imagine que você se depara com um enorme sistema mecânico. Todos os motores, sensores e módulos de controle estão fortemente acoplados, afetando todo o corpo. Quer ajustar os parâmetros de um determinado servo? Pode ser necessário reorganizar todo o programa de controle. Não é como tentar substituir apenas uma engrenagem de um relógio e ter que desmontar o relógio inteiro?

Projetos mecatrônicos sob arquitetura tradicional frequentemente enfrentam esse dilema.

Existe uma maneira de fazer com que cada parte do sistema – como o módulo codificador responsável pelo feedback de posição, a unidade de acionamento que gerencia a saída de torque ou a trajetória do movimento – seja uma banda bem treinada que possa praticar de forma independente e funcionar perfeitamente em conjunto?

É sobre isso que falaremos hoje: os principais componentes da arquitetura de microsserviços na interseção de hardware e software.

Não é mágica, é método: o que exatamente existe em um microsserviço?

Quando muitas pessoas ouvem “microsserviços”, elas pensam que é um conceito puro no campo do software. Na verdade. Quando você mapeia isso para o cenário de controle de um servo motor, um braço robótico ou uma linha de produção automatizada, ele se torna muito específico. Vamos desmontar e dar uma olhada.

O primeiro núcleo: unidades de negócios implantadas de forma independente.

No mundo dos microsserviços, cada função central torna-se um “serviço” independente. Por exemplo, um serviço que trata especificamente do “controle de malha fechada de posição” e um serviço que trata especificamente do “monitoramento e proteção de temperatura” são separados. Cada um deles possui processos independentes e podem ser escritos em diferentes linguagens de programação ou até mesmo frameworks. o que isso significa? Se precisar de proteção de temperatura, você só precisa atualizar aquele pequeno serviço sem perturbar todo o enorme sistema de controle. O sistema não cai e todo o resto continua normalmente.

É como uma máquina-ferramenta complexa. O acionamento do fuso, o sistema de alimentação e a unidade de resfriamento possuem gabinetes de controle independentes, mas se comunicam por meio de interfaces padrão. Enquanto uma unidade está sendo mantida, outras partes ainda podem funcionar.

O segundo núcleo: mecanismo de comunicação leve.

Como os serviços “conversam” entre si? Eles geralmente se comunicam por meio de APIs (interfaces de programação de aplicativos) leves e bem definidas, geralmente HTTP/REST ou filas de mensagens semelhantes. No contexto eletromecânico, isso pode ser entendido como um protocolo de comunicação padronizado e de baixa latência. Cada serviço expõe apenas as “janelas de diálogo” necessárias e a implementação interna fica oculta. Seguro e claro.

O terceiro núcleo: gerenciamento descentralizado de dados.

Cada microsserviço normalmente gerencia seu próprio banco de dados ou armazenamento de dados dedicado. O serviço de planejamento de movimento possui seu próprio banco de dados de trajetória e o serviço de diagnóstico de falhas possui sua própria biblioteca de registros. Isso evita o congestionamento e a complexidade de agrupar todos os dados em um banco de dados gigante. A propriedade dos dados é clara, de quem é o filho que é levado.

O quarto núcleo: automação e elasticidade.

Como gerenciar vários pequenos serviços? Isso requer a ajuda de tecnologias de conteinerização (como Docker) e ferramentas de orquestração (como Kubernetes). Eles automatizam a implantação, o dimensionamento e o gerenciamento desses serviços. Para linhas de produção que precisam funcionar 24 horas por dia, 7 dias por semana, se uma instância de serviço falhar, o sistema de orquestração poderá reiniciar automaticamente uma ou alternar o tráfego para uma instância íntegra, aumentando significativamente a resiliência do sistema.

O quinto núcleo: capacidades de evolução independente.

Esse é um dos maiores encantos dos microsserviços. As equipes podem desenvolver e lançar de forma independente os serviços pelos quais são responsáveis, e a velocidade de iteração é muito rápida. Quer experimentar um novo filtro para seu servoconversor? Basta testar e implantar nesse serviço de controle independente, sem afetar outros módulos funcionais.

Do acoplamento forte à colaboração livre: como acontece a transição?

Vendo isso, você pode estar pensando: “Parece ótimo, mas como isso ajudará nosso projeto específico?”

Dê um exemplo. No passado, você poderia ter usado um programa PLC gigante para controlar uma linha de montagem inteira com vários servo-eixos e robôs. Modificar a lógica de ação de uma estação de trabalho pode exigir testes de regressão de todo o programa, o que é de alto risco e demorado.

Depois de adotar a arquitetura de microsserviços, você pode separar o "serviço de posicionamento visual", "serviço de controle de pinça" e "serviço de gerenciamento de torque do eixo de aperto" de forma independente. O posicionamento visual foi atualizado? Implante apenas esse serviço. O modelo da pinça foi alterado. A lógica de controle precisa ser ajustada? Toque apenas nesse serviço. Eles cooperam através de um contrato de interface claro. Por exemplo, após a conclusão do posicionamento do serviço de visão, basta enviar uma mensagem de coordenadas ao serviço de controle da garra.

Essa divisão reduz a complexidade e torna a seleção de tecnologia mais flexível. Um determinado serviço requer velocidade de computação extremamente alta e pode ser escrito em C++; outro serviço precisa se conectar rapidamente ao sistema MES da camada superior e pode ser escrito em Go ou Python. Não há problema um para o outro.

Seleção e implementação: não alcançadas da noite para o dia

É claro que os microsserviços não são uma solução mágica. Introduz novos desafios, como a latência na comunicação de rede entre serviços e a consistência dos dados em sistemas distribuídos. Para controle servo de malha fechada com requisitos extremamente altos em tempo real (talvez no nível de microssegundos), é necessário um projeto cuidadoso. O circuito principal de controle em tempo real pode ser retido em um módulo único ou mais compacto, e funções não em tempo real, como monitoramento, gerenciamento e registro, podem ser microsserviços.

Isto exige que os decisores técnicos, como um projetista mecânico experiente, saibam onde são necessárias ligações rígidas e onde podem ser utilizadas juntas flexíveis.

existirpotênciaNos muitos projetos de mecatrônica e automação em que participamos e apoiamos, vimos que esse pensamento arquitetônico está ajudando os engenheiros a construir sistemas mais flexíveis, robustos e mais fáceis de evoluir. Não se trata de derrubar e recomeçar, mas de uma arte passo a passo de dividir e reorganizar.

Em última análise, todas as arquiteturas técnicas têm o mesmo objetivo: tornar os sistemas mais confiáveis, o desenvolvimento mais eficiente e as mudanças mais fáceis. Na próxima vez que você enfrentar um sistema de controle complexo, talvez possa pensar sobre isso - quais partes podem se tornar um "microsserviço" que pode respirar de forma independente e crescer livremente? O processo em si é como resolver um interessante quebra-cabeça de engenharia.

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.