diferença entre microsserviços e API REST

Qual é a diferença entre microsserviços e API REST? vamos conversar

Imagine que você está construindo um robô. Cada junta requer um servo independente para controlar a rotação, e esses servos devem coordenar-se entre si para transmitir sinais. Neste momento, alguém lhe sugeriu: Que tal colocar todos os circuitos de controle em uma caixa e conectá-los de maneira uniforme? Ou deveríamos equipar cada servo com um pequeno controlador inteligente, deixá-los desempenhar suas respectivas funções e então se comunicar de forma simples e universal?

Esta pergunta lhe parece familiar? Na verdade, no mundo do software, essa confusão ocorre todos os dias. Isso mesmo, estamos falando das palavras “microsserviços” e “API REST” que muitas vezes são confundidas. Muitas pessoas não entendem a diferença entre eles e até pensam que são a mesma coisa. O resultado? Ao projetar o sistema, sempre sinto que algo está errado e mantê-lo mais tarde é como desvendar uma bagunça.

Então, vamos conversar casualmente hoje e tirar isso do caminho. Não se preocupe com a terminologia, falaremos apenas no vernáculo.

Primeiro descubra: quem são eles?

Vamos usar uma analogia. Você entra em um grande restaurante. Se esta loja tiver uma arquitetura de “microserviços”, o chef pode ser dividido em vários grupos independentes: o grupo de frios foca apenas em saladas, o grupo de churrasco foca em churrasco, e o grupo de sobremesas foca em fazer bolos.流程，彼此之间通过一种标准纸条（比如订单单）传递需求。 Este "sistema de notas em papel" é como uma API REST.

Você vê o caminho? Microsserviços são uma ideia arquitetônica – eles dividem um grande aplicativo em muitos pequenos serviços que são executados de forma independente e se concentram em funções específicas, assim como aqueles grupos em um restaurante com clara divisão de trabalho. Cada serviço cuida do seu próprio negócio e pode ser desenvolvido, implantado e até mesmo reiniciado de forma independente, sem afetar outras partes. A API REST é um protocolo de comunicação, uma “maneira de falar” baseada em HTTP acordada entre serviços, assim como a nota de pedido em formato padrão.

Simplificando, os microsserviços são uma estrutura de equipe do tipo "dividir e conquistar" e a API REST é a "linguagem de comunicação" comum dentro da equipe. Você pode usar a API REST para conectar microsserviços, mas a API REST também pode ser usada em outras arquiteturas. Não é exclusivo de microsserviços.

Então, por que separar? Qual é o benefício?

Você pode querer perguntar: não seria bom ter um aplicativo “grande e monolítico” que empacotasse todo o código? Por que se dar ao trabalho de dividir tudo?

Pense no seu robô. Se toda a lógica de controle estiver comprimida em uma placa-mãe, quando você quiser atualizar uma determinada junta, poderá ser necessário parar o robô inteiro, reescrever, testar e então implantar. Sem falar nos problemas, os riscos também são altos. Mas se você usar um microcontrolador independente (microsserviço) para cada junta (módulo funcional), a situação muda. Você pode atualizar a lógica de preensão do manipulador de forma independente, sem afetar em nada o módulo de movimento do chassi. Todo o sistema se torna mais flexível e robusto.

“Mas”, alguém murmurará, “se os serviços forem interrompidos, como eles poderão conversar entre si de maneira confiável?” Isso remonta ao que chamamos de “linguagem de comunicação”. A razão pela qual a API REST é popular é que ela é simples e universal, como o mandarim no mundo da Internet. Ele usa as ações comuns do protocolo HTTP – GET (obter), POST (criar), PUT (atualizar), DELETE (excluir) para transmitir intenções. Quando o serviço A precisa de dados, ele envia uma solicitação HTTP claramente formatada para o serviço B, e o serviço B retorna um pacote de dados em um formato padrão (geralmente JSON). Claro e amigável ao desenvolvedor.

Como os usamos?

existirpotência, fomos expostos a muitos cenários de integração. Por exemplo, há um projeto que exige que o sistema de controle central programe com flexibilidade dezenas de tipos diferentes de servomotores, ao mesmo tempo que fornece feedback de status em tempo real. O plano inicial era escrever toda a lógica de controle em um programa gigante. Qual foi o resultado? Cada vez que um novo modelo de motor era adicionado, o código tremia e os ciclos de teste eram dolorosamente longos.

Mais tarde, mudei para a arquitetura de microsserviços. Dividimos as funções de controle do motor, monitoramento de status, diagnóstico de falhas e registro em pequenos serviços independentes. Cada serviço se concentra em fazer bem uma coisa. Como eles conversam entre si? Isso ocorre por meio de uma API REST bem projetada e claramente documentada. Por exemplo, se o serviço de monitoramento de status quiser saber o torque em tempo real do motor nº 3, ele enviará uma solicitação GET /api/motors/3/torque ao serviço de controle do motor e obterá imediatamente uma sequência de dados clara. Atualizar diagnóstico? Enquanto o serviço de diagnóstico estiver ativado, todo o resto funcionará normalmente.

Este modelo torna as iterações rápidas e reduz o acoplamento entre as equipes. O colega responsável pelo controle motor pode se concentrar no seu trabalho. Desde que cumpra o “contrato de comunicação” da API previamente acordado, ele não tem medo de afetar outros módulos.

O que você deve prestar atenção ao escolher?

Então, se você está pensando em estruturar seu próprio projeto, não fique apenas olhando para chavões. Pergunte a si mesmo:

• Seu sistema é complexo? Algumas partes serão frequentemente expandidas ou alteradas no futuro? (Nesse caso, a independência de uma arquitetura de microsserviços pode ser uma vantagem.)
• Como é a estrutura da sua equipe? É adequado que várias equipes pequenas desenvolvam módulos diferentes em paralelo?
• Como os serviços precisam se comunicar entre si? Quão elevados são os requisitos de tempo real e de confiabilidade? (A API REST é uma escolha comum, mas não a única; às vezes, uma fila de mensagens ou outro protocolo é mais adequado.)

Não existe uma resposta única para todos. Assim como escolher um servo para um robô, depende dos requisitos de carga, precisão e velocidade de resposta. Microsserviços e API REST são uma combinação poderosa de ferramentas, mas somente compreendendo suas respectivas funções você poderá usá-los sem problemas.

Afinal, a tecnologia tem um propósito. A arquitetura clara e a comunicação eficiente têm como objetivo final tornar o sistema mais robusto e mais fácil de manter. Assim como uma estrutura mecânica precisa, cada componente opera adequadamente e é coordenado para produzir energia precisa. existirpotência, acreditamos que, ao desmontar as coisas com clareza e depois conectá-las da maneira mais comum, muitas vezes podemos avançar de forma mais constante e mais longe. Espero que este compartilhamento casual possa ajudá-lo a esclarecer seus próximos passos.

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, 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.