Se você viu meu último post e se animou por acreditar que usar RPC sob AMQP seja uma ideia incrível, calma que lá vem um balde de água fria!

Com toda certeza eu não vou falar bem da abordagem! E se você resolveu que não vai ler, e ainda vai adotar RPC sob AMQP assim mesmo. Esse post é o que os teus colegas trarão para a discussão no trabalho! 🙂

RPC (Remote Procedure Call) sob AMQP, trata-se de usar a infraestrutura de mensageria para implementar um fluxo síncrono de Request/Response sob um o RabbitMQ ou qualquer outra implementação de AMQP.

Fluxo Assíncrono

Mensageria pode entregar para você pelo menos 5 grandes benefícios.

• Disponibilidade
• Eficiência
• Resiliência
• Confiabilidade
• Escalabilidade

Projetos grandes conseguem explorar todos 5 benefícios, enquanto projetos menores tiram proveito de 2, 3, talvez até 4 desses benefícios.

Escalabilidade quase sempre é irrelevante para projetos pequenos. O benefício está lá, mesmo assim é irrelevante, não serve de nada se o projeto não precisa de escala.

Eu acredito que basta 1 benefício para justificar a adoção! E é por isso que uso RabbitMQ em diversos projetos!

Ao cogitar adotar mensageria, nos depararmos com o nosso código, e nos deparamos com os comportamentos síncronos em um emaranhado de funções de alto e baixo níveis.

Aliás parafraseando Uncle Bob: O que são classes, se não um agrupamento de funções que manipulam um mesmo conjunto de estados?

Pois bem, uma action MVC é uma função que recebe um request e retorna um response.

Seu ORM tem métodos que são funções que recebem filtros e retornam objetos ou recebem objetos e retornam sucesso, até quando o retorno é void, há um retorno: O não lançamento de uma exceção, ou seja, um caso de sucesso.

Quando lidamos com cenários assíncronos precisamos enxergar essa troca de mensagens de outra forma.

Alguém envia uma mensagem e sequer sabe se deu certo ou não seu processamento.

É um ato de fé!

E é aí que bate o desespero.

Essa angústia é natural. Mas lembre-se você tem tempo para testar e validar sua solução. É essa forma desacoplada que viabiliza a internet com a intensidade que conhecemos hoje. Não seria possível ter experiências como ifood, uber, instagram, whatsapp, telegram, e um milhão de outros aplicativos e serviços, se não fosse a mensageria e o processamento assíncrono.

O que eu posso dizer sobre isso: É normal e vai passar!

O feedback pode vir via uma coluna, uma tabela, um cache, tem diversas formas de notificar a conclusão da tarefa. E em geral fazemos isso.

O ponto mais importante é saber que no momento em que você envia uma mensagem para o broker.

O consumidor pode não estar lá!

E precisa poder não estar lá.

Ele tem o direito de não estar
nem UP
nem RUNNING.

Mesmo que esse fluxo exija processamento quase que instantâneo. Você não pode criar esse acoplamento. Ou pelo menos não deveria.

Vamos supor que seu consumidor seja um serviço de envio de e-mail ou uma chamada a uma API de pagamento. Você envia uma mensagem para a fila, muito provavelmente fará um insert em banco antes disso e ponto e…. e F0d@-se!!!!

Sério, isso mesmo: F0d@-se!

Desculpe o termo, não é comum aqui! Mas é isso mesmo.

O teu registro foi armazenado antes do envio para a fila, portanto você vai enviar um ID de correlação, esperando que o serviço que vai processar a mensagem, após o processamento, realize algum tipo de update nesse mesmo conjunto de dados. Talvez o update de uma flag ou um campo de status. Você modela, você define.

Se o tempo entre receber a demanda e processá-la for de menos de 1 segundo ou de 10 minutos, isso não nos diz respeito.

Quando você aprende a lidar com esse cenário, você aprende a trazer resiliência para sua aplicação.

O fato de você não precisar que o serviço esteja online, ativo, funcionando, faz com que uma eventual queda dele, não atrapalhe sua aplicação.
Ou seja, você aumenta também sua disponibilidade.

Se você tinha no passado muitos problemas com esse fluxo, e, ao mesmo tempo, as retentativas solucionam esse problema (por uma instabilidade externa) ou a natureza em background faz com que você tolere um maior tempo de espera ou latência, você acaba de ganhar confiabilidade.

Se você tinha dificuldade porque sua aplicação Web ficava pesada, lenta, processando tarefas de background, e agora ela fica mais responsiva porque a tarefa está sendo realizada no worker, parabéns, você ganhou eficiência.

Aliás, se você precisava alocar mais hardware para banco e escalar horizontalmente por conta da demanda por um processo que acontecia na thread do usuário e agora foi movido para um trabalho assíncrono com filas, e consequentemente não afeta sua infraestrutura porque você limitou a escala:
Novamente você ganhou eficiência.

Já, se você percebe que a demanda está aumentando, e o acúmulo de mensagens na fila tem durado demais, é hora de subir mais instâncias. Sem necessidade de reconfiguração ou deployment. Só duplicando as instancias atuais (no docker swarm ou kubernetes é só aumentar o número de Pods/Containers).
Ótimo, você ganhou escalabilidade.

Mas e com RPC?

Com RPC você precisa esperar a resposta de forma síncrona, com lock na thread que enviou a mensagem original. O fluxo se baseia no Cliente, criando uma fila de resposta, enviando uma mensagem para o servidor (via exchange, fila) e fica aguardando um retorno na fila de reposta. Na medida que a fila de resposta recebe o feedback, seu processamento prossegue.

E essa espera faz com que você:

• Não seja resiliente: A queda do Server (Worker) representa queda do cliente (aplicação que depende).
• Não é confiável: Porque cai, porque é possível ocorrer timeout.
• Não é eficiente: Porque precisa processar no momento em que o usuário solicita (já que ele está esperando a resposta), sem a oportunidade de processar depois.
• Não é disponível: Porque é frágil

Entretanto, ainda assim você não perde escalabilidade.

Se escalabilidade não for uma questão para você, parabéns!

Você jogou fora todos os benefícios de sua implantação de mensageria.

O único benefício que você ganhou é a capacidade de retentar, sem precisar de um load balancer ou proxy reverso muito inteligente, ou uma política de retry implementada no código.

Conclusão

A sua familiaridade com modelos síncronos, faz com que naturalmente você busque sincronismo no mundo da mensageria, com o objetivo de reduzir o escopo de alterações e modificações em seus sistemas.

Eu entendo, mas não posso deixar de ser claro e dizer que na maioria esmagadora das vezes em que você faz isso, você está rasgando dinheiro, jogando fora todos os benefícios da mensageria.

Até hoje eu não achei sequer 1 implementação de RPC que fosse de fato necessária.

Em todas, eu disse TODAS, se tratava apenas de desenvolvedores que achavam que “bastava colocar o RabbitMQ” que mesmo usando RPC, teria todos os benefícios.
Ledo engano.

Esse fenômeno é comum inclusive com meus alunos. Assim que aprendem sobre RPC, logo vislumbram que essa seria a forma mais rápida, mais indolor de adotar RabbitMQ em seus projetos.

Na prática, ou a gente faz o que de fato é necessário ser feito, ou vamos rasgando dinheiro pelo caminho. Mensageria exige mais mudanças sempre que esbarra em alto acoplamento.

Quanto maior o acoplamento, mais difícil, quanto menor, mais fácil.