desvantagens da arquitetura de microsserviços

Esse velho sistema está quebrado novamente, e você tem que admitir, às vezes as coisas simplesmente não acontecem.

Na tarde de sexta-feira, a linha de produção parou repentinamente. Não por falha do equipamento, mas porque o módulo de processamento de pedidos e o módulo de gerenciamento de estoque “brigaram” - um dizia que o material era suficiente e o outro mostrava que estava esgotado. Os engenheiros levaram três horas para descobrir que a sincronização de dados entre os dois microsserviços estava atrasada. As máquinas estão ociosas, os pedidos estão acumulados e todos estão atentos ao tique-taque do relógio.

Você já encontrou um momento assim? A arquitetura de microsserviços parece bastante moderna. Está bem dividido, cada serviço é implantado de forma independente e pode ser expandido de forma flexível. Mas no chão de fábrica real, muitas vezes as coisas não são tão bonitas.

Pense nisso: para dissociar, você divide o todo original em uma dúzia ou até dezenas de pequenos serviços. Eles se comunicam pela Internet. O que é uma rede? É uma linha que ocasionalmente treme e um canal que pode estar congestionado. Se um serviço responder algumas centenas de milissegundos mais devagar, a reação em cadeia poderá paralisar todo o processo. Sem falar na consistência dos dados – cada serviço possui seu próprio banco de dados e, quando você deseja ter uma visão completa desde a matéria-prima até a remessa, os dados devem ser reunidos como um quebra-cabeça. Às vezes as peças do quebra-cabeça não cabem.

Também existem testes. Antigamente bastava testar um processo de inscrição completo, mas agora? Você tem que simular interações entre dezenas de serviços. O mesmo se aplica à implantação. As atualizações de versão são como um voo de formação preciso. Se uma atualização de serviço for incompatível, toda a formação pode ficar confusa.

"Então, estamos presos aqui? Apenas convivendo com essas complexidades?"

Claro que não. Problemas existem para serem resolvidos.

A chave é como pensamos sobre a “divisão”. Não há nada de errado com os conceitos centrais dos microsserviços: foco, autonomia e elasticidade. Contudo, muitos processos de implementação caíram na armadilha do desmantelamento pelo desmantelamento. A verdadeira solução pode não ser adicionar mais ferramentas ou um monitoramento mais complexo, mas retornar à essência da questão: o que exatamente você deseja que este sistema faça por você?

No mundo das máquinas e da automação, valorizamos o que é confiável, direto e poderoso. Um servo motor recebe instruções, executa-as com precisão e responde rapidamente. Uma caixa de direção funciona de forma estável e fiel dentro de uma faixa de ângulo definida. Eles não realizam comunicações redundantes e não dependem de redes externas instáveis. Eles fazem o melhor que podem no âmbito de suas responsabilidades.

Isso nos dá uma perspectiva de analogia muito diferente: talvez sua arquitetura de software também precise de um pouco desse pensamento “mecatrônico”. Em vez de subdividir infinitamente, devemos encontrar as partes que realmente precisam ser independentes e podem ser independentes com base nos limites funcionais e na frequência das mudanças, e transformá-las em módulos que sejam tão confiáveis ​​quanto unidades servo e tenham interfaces claras. O resto, mantenha a coesão e reduza a sobrecarga desnecessária de chamadas remotas.

É como projetar um braço robótico de precisão. Você não transformará cada fio do circuito de controle, feedback do sensor e saída de energia em um serviço remoto conectável. Você integrará as partes altamente inter-relacionadas que exigem colaboração em nível de milissegundos em um controlador local sólido e exporá apenas as partes que claramente precisam interagir com sistemas externos e mudar em ritmos diferentes por meio de interfaces bem definidas.

Que diferença isso pode fazer?

A complexidade está presa onde ela pertence. As interações centrais de alta frequência são concluídas localmente, tão rápidas quanto um raio e tão estáveis ​​quanto uma rocha. Apenas a colaboração entre domínios e de baixa frequência ocorre online. O escopo do problema é menor e a solução de problemas é mais fácil.

Os dados têm um proprietário. Os dados dos principais processos mantêm forte consistência dentro da sua “unidade funcional”. O que é fornecido externamente é uma interface determinística de consulta de status, em vez de um monte de logs originais que precisam ser emendados posteriormente.

Além disso, o teste e a implantação tornam-se práticos. Os módulos principais podem ser rigorosamente integrados e testados como uma placa de circuito. Os verdadeiros microsserviços independentes têm limites claros e responsabilidades únicas, de modo que a complexidade dos testes e da implantação também é bastante reduzida.

Parece um pouco idealista? Na verdade, é mais pragmático. Exige que dividamos os serviços não do ponto de vista técnico de “se podem ser separados”, mas do nível empresarial de “devem ser separados”. Cada vez que você divide, você tem que responder: essas duas partes realmente mudam em velocidades diferentes? A colaboração entre eles é estável o suficiente para tolerar a sobrecarga e os riscos da rede?

Freqüentemente vemos essas mudanças nos casos de clientes da Kpower. Um fabricante de equipamentos que anteriormente sofria atrasos de rede entre microsserviços reorganizou sua “lógica de controle de movimento” e “lógica de status de pedido”. O primeiro tem requisitos de tempo real extremamente elevados e está integrado num núcleo sólido; este último precisa se comunicar com o ERP de nível superior e é concebido como um serviço independente. O resultado? A linha de produção voltou a ter um ritmo suave, como se tivesse sido substituída por um sistema servo que respondesse com mais precisão.

Então, quando você estiver pensando em arquitetura, pergunte-se algumas perguntas simples:

• Este serviço é dividido para resolver um problema real e de mudanças frequentes ou para acompanhar uma determinada tendência tecnológica?
• Cada chamada entre os dois serviços vale a incerteza que a rede pode trazer?
• Se você colocá-los juntos, isso realmente criará um caos incontrolável?

A resposta geralmente é mais direta do que você pensa. Uma boa arquitetura não deve fazer as pessoas sentirem a sua existência. É como uma máquina bem lubrificada. Você só pode ver sua potência estável e nem sempre se preocupará com a possibilidade de um determinado parafuso se soltar.

Não deveria ser um grilhão de pensamento, mas um empoderamento dos negócios. Partindo de pontos problemáticos reais e usando um pensamento semelhante ao projeto de máquinas de precisão para examinar os limites do acoplamento e da separação, você poderá descobrir que o caminho para a confiabilidade, a eficiência e a simplicidade sempre existiu.

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.