REST ou AMQP de microsserviços, caso em que

Eu li muitos artigos sobre arquitetura de microsserviços e fiquei pensando quando usar o AMQP ou o REST.

Eu li que o acoplamento frouxo entre serviços é uma coisa boa e o AMQP parece ser uma boa escolha nesse caso. Mas se usarmos o AMQP, isso significa que não precisamos mais dos pontos de extremidade REST (mas significa que perdemos o conceito HATEOAS).

Mas o REST é realmente uma boa maneira de criar meus serviços? Porque não usarei pontos de extremidade ... Nesse caso, um é melhor que o outro?

Quando devo usar um ou outro?

Ao descartar o REST, você perde muito mais do que apenas o HATEOAS. Se seus microsserviços forem públicos (e é uma boa idéia para eles serem públicos ou pelo menos tenderem a ser públicos um dia¹), o uso de qualquer coisa que não seja REST e SOAP seria problemático:

• Alguns desenvolvedores nunca usaram o AMQP,

• Alguns usaram o AMQP, mas geralmente estão muito mais familiarizados com o REST e SOAP,

• As bibliotecas AMQP para alguns idiomas não são particularmente diretas,

• A experimentação manual com o serviço é muito limitada: posso usar o CURL para fazer qualquer solicitação ao Amazon S3; o que devo instalar na minha máquina se quiser jogar com uma variante AMQP do S3?

• Depurar REST e SOAP é fácil. Eu apenas acompanho as trocas HTTP e as analiso. Não tenho certeza de quais ferramentas devo usar para depurar trocas AMQP.

O AMQP é ótimo, mas é feito com um objetivo muito específico de trocas com base em eventos. Embora seja tecnicamente possível fazer RPC com AMQP, esse não é seu objetivo principal.

O aspecto assíncrono também é importante. Às vezes, é um benefício: não quero bloquear a interface do usuário de um aplicativo enquanto faz solicitações aos servidores. Às vezes, isso torna as coisas mais difíceis do que precisam: se eu precisar recuperar um backup de arquivo do Amazon S3 porque o local estava corrompido e depois restaurar o backup, meu arquivo em lote precisará necessariamente do CURL para concluir seu trabalho antes de continuar, e uma operação síncrona (com um tempo limite específico) faz todo o sentido.

Mantenha o REST para operações principais:

• Obtendo um produto,

• Armazenando uma fatura,

e use o AMQP para as tarefas nas quais as mensagens realmente fazem sentido:

• Processando todas as faturas a partir de setembro e notificando o aplicativo quando o relatório estiver pronto para ser exibido (considerando que a operação geralmente leva de dois a dez minutos),

  ^{O benefício do AMQP aqui é seu aspecto assíncrono. Uma solicitação HTTP pendente por dez minutos tem uma boa chance de causar um tempo limite e outros problemas.}

• Distribuir as informações de que os backups foram corrompidos para todos os interessados, como o pessoal de suporte, os administradores de banco de dados, a equipe de monitoramento, os desenvolvedores do aplicativo que usa esse banco de dados, etc.

  ^{O benefício do AMQP aqui é, entre outros, a capacidade de adicionar assinantes sem alterar o aplicativo que rastreia backups e aciona o alerta quando encontra um corrompido.}

^{¹ Um serviço público da Web não é necessariamente usado por usuários externos a uma empresa. Em empresas de grande ou médio porte, seu serviço é frequentemente usado por outras divisões da mesma empresa e tem os mesmos requisitos que aquele que seria usado por terceiros: deve desconfiar de qualquer ligação (o fato de alguém que você nunca saber de quem liga para o seu serviço e trabalha na mesma empresa que você não significa que ele não explorará seus problemas de segurança), ele deve ser documentado adequadamente (porque o mesmo indiano não necessariamente sabe o seu número de telefone e não necessariamente sabe inglês) etc.}

Use ambos.

Os serviços Web JSON estilo REST são ótimos para interoperabilidade com javascript, ios etc.

O AMQP é ótimo para processos de longa execução, eventos e orquestração de microsserviços.

Mas ambos são apenas invólucros de comunicação para o serviço real, você pode expor o mesmo serviço de várias maneiras e provavelmente deveria.

O AMPQ pode funcionar bem exposto nos Websockets, que podem parecer muito com um ponto de extremidade REST se você for apertar os olhos.

O REST é uma tecnologia padrão particularmente adequada para interoperabilidade entre componentes - essa é a parte principal, excelente para criar um serviço da Web que outra pessoa possa consumir. No entanto, ele sofre dos problemas usuais dessa interoperabilidade, pois é menos eficiente que um protocolo personalizado.

Se você estiver escrevendo uma arquitetura de back-end em que os serviços são consumidos apenas por você, poderá usar o protocolo que desejar - não será mais restringido usando um que seja tão interoperável. Você pode usar um MQ ou algo mais fortemente acoplado e com desempenho. Qual deles você depende do seu caso de uso, um barramento de mensagens é muito bom para um conjunto distribuído de serviços que processam dados nos quais o cliente não se importa com quem recebe as mensagens que envia.

O AMQP também suporta comunicação ponto a ponto (por exemplo, consulte o python-qpid-protontutorial). Você pode implementar uma interface RESTful usando isso, já que o REST!= HTTP .

O AMQP também tem um desempenho muito melhor que o HTTP.