Ao esbarrar com uma nova tecnologia, você pode se perguntar: Será que é para mim? Com RabbitMQ não é diferente. Mas será que RabbitMQ é para o teu projeto? Nesse post eu vou mostrar minha visão sobre esse questionamento, mostrando os benefícios e quais são os dilemas a respeito do uso de RabbitMQ.

Disclaimer – RabbitMQ é RabbitMQ

A primeira coisa que precisa estar bem clara é que se você usa ou já usou Azure Service Bus ou Kafka, mas nunca usou RabbitMQ, seu conhecimento tende a ser pouco ou nenhum. sobre o RabbitMQ.

O que você aproveita aqui são seus conhecimentos sobre aplicações distribuídas e sua natureza peculiar, e isso é ótimo, já é metade do caminho.

História do AMQP

O RabbitMQ é parte da segunda geração de message brokers, e veio para sanar alguns gaps da geração anterior, a geração do MSMQ.

O RabbitMQ nasce sob o prisma do AMQP, um standard nascido em 2003, na JPMorgan Chase e mais tarde adotado pela Cisco, Apache foundation (com algumas implementações), Rabbit Technologies e Microsoft.

O standard AMQP nasce da necessidade de um modelo que pudesse ser agnóstico e interoperável. Isso foi demonstrado com o AMQP 1.0. pelo AMQP Working Group em 30 de outubro de 2011, em uma conferência em New York. Nesse evento Microsoft, Red Hat, VMware, Apache, INETCO e IIT Software demonstraram um software rodando o protocolo em uma demonstração de interoperabilidade. No dia seguinte, em 1 de novembro de 2011, a formação do OASIS Technical Committee foi anunciada.

O standard conta com mais de 23 empresas como Bank of America, Barclays, Cisco Systems, Credit Suisse, Deutsche Börse, Goldman Sachs, HCL Technologies Ltd, Progress Software, IIT Software, INETCO Systems Limited, Informatica (incluindo 29 West), JPMorgan Chase, Microsoft Corporation, my-Channels, Novell, Red Hat, Software AG, Solace Systems, StormMQ, Tervela Inc., TWIST Process Innovations ltd, VMware (que adquiriu a Rabbit Technologies) e WSO2.

Mensageria – Para que usamos?

É muito comum que seu primeiro interesse seja escala. Ganhar escalabilidade com sua aplicação e tolerar centenas de vezes sua capacidade atual de responder às demandas de negócio com o mesmo código que já possui. Mas eu encaro essa capacidade secundária em relação ao que vou mostrar hoje nesse post.

Se de um lado você é capaz de aumentar sua capacidade de processamento, em dezenas ou até centenas de vezes. A verdade é que a esmagadora maioria das aplicações sequer precisa disso.

E é aqui que eu enxergo o melhor valor no uso do RabbitMQ:

Reduzir o acoplamento entre duas partes do seu software.

É nesse campo de atuação que até as menores aplicações podem se beneficiar.

O que é acoplamento?

Acoplamento é a relação de dependência entre duas partes. No software quando uma aplicação depende de outra dizemos que há um acoplamento entre elas. Elas estão acopladas.

Alto Acoplamento

Acoplamento forte é quando o nível de dependência é tão grande que a dependência é vital para o funcionamento da aplicação que depende dela. Pequena indisponibilidade faz da aplicação que depende sequer funcionar.

Baixo Acoplamento

Encontramos um baixo acoplamento quando essa relação de dependência existe mas uma eventual indisponibilidade do serviço que dependemos não afeta a nossa própria disponibilidade.

Aqui usamos RabbitMQ e mensageria para transformar cenários de alto acoplamento em cenários de baixo acoplamento.

Nenhum acoplamento ou Acoplamento indireto

Nesse caso, há uma relação de causa e efeito, mas a interdependência embora existe é indireta.

Nos casos em que usamos arquiteturas orientadas a eventos, os eventos podem ser produzidos por qualquer um serviço do nosso parque.

Uma aplicação que depende de um determinado evento (e que possivelmente também produz novos eventos) não sabe quem produziu os eventos que consome, da mesma forma que não sabe quem precisa dos eventos que ela mesma produzirá. Portanto ela não depende nem é dependência direta de outros serviços. O serviço em questão é uma peça de um grande quebra-cabeça.

Nesse contexto o único acoplamento é com o formato da mensagem que ela consome e com o formato das mensagens que ela produz. Esse acoplamento com as mensagens se traduz em acoplamento com os próprios inputs e outputs. O que é natural, necessário e quase impossível de abstrair.

Como RabbitMQ reduz o acoplamento na minha aplicação?

Na medida que o RabbitMQ assume o papel de portador da sua mensagem, a relação de dependência direta acaba. Sua aplicação depende do portador apenas (o RabbitMQ).

Nesse desenho, o serviço que antes receberia um request http, agora consome uma ou várias filas, e não precisa sequer estar online. Ou mesmo que esteja operacional, não precisa conseguir atender na capacidade e volume de mensagens que o cliente demanda.

Enquanto a produção de mensagens for maior que a capacidade de processamento, as filas vão acumulando mensagens e crescendo. Na medida que a pressão sobre a produção de mensagens é reduzida, e a capacidade de processamento passa a ser maior que a produção de mensagens, nesse momento as filas vão reduzindo seu tamanho, esvaziando até chegar à zero.

Esse desenho permite aumentar a disponibilidade das nossas aplicações, mas também a capacidade de lidar com grandes cargas de trabalho. Se a carga de trabalho for muito maior que a capacidade de processamento, o que teremos no máximo é uma demora maior para processar as mensagens, mas não deixamos de recebê-las. Ou seja, não ficamos indisponíveis.

Outro aspecto que tira o sono de quem ainda nunca usou RabbitMQ é o quanto ele aguenta de mensagens? Bom, podemos brincar na casa do bilhão de mensagens.

Nesse post de 2014 temos um case de um 1 milhão de mensagens por segundo, o case conta ainda com 6 bilhões de mensagens SMS processadas com RabbitMQ em 2012 e o case de 40 bilhões de mensagens por dia no iMessage da Apple.

Eu vou abordar isso com calma nos próximos posts, mas RabbitMQ está por trás do WhatsApp, Instagram e NY Times, por exemplo. Mas também em clientes menores como a Seguradora Líder, que cuida do DPVAT ou Claro Música, antiga iMusica, ambos cenários em que eu fiz a escolha e implantação.