A eficiência da sua aplicação não é determinada pela quantidade de usuários simultâneos que sua aplicação suporta.
Eficiência é medida pelo quanto você gasta pra isso.
Se sua jornada passa pelo desenvolvimento de aplicações distribuídas, RabbitMQ com certeza é um dos fortes candidatos a te ajudar nessa jornada. Seja com microsserviços ou em monolitos com partes distribuídas, RabbitMQ é seu aliado na hora de coordenar a distribuição de mensagens de forma resiliente.
O eShopOnContainers é uma referência sobre microsserviços na comunidade .NET.
O uso do RabbitMQ ou Azure Service Bus são viabilizados por um standard: AMQP.
A adoção de um standard forte é o que possibilita transitar com facilidade entre os 2.
Toda a comunicação assíncrona desse projeto é pautada no EventBus que por sua vez é implementado por um serviço AMQP.
A simplicidade do RabbitMQ desafia nossa capacidade cognitiva. São apenas 2 elementos: Exchanges e Filas, associadas por um Bind que configura o roteamento entre elas.
Essa simplicidade preoduz a falsa sensação de familiaridade.
É aqui que começam os equívocos que drenam o sucesso da sua implantação.
Você implementa controles que não precisava e dá voltas para fazer aquilo que já é comportamento default, nativo.
Essas implementações viram frankensteins! E se voltam contra você. Por fim falta força e tempo para refazer tudo, e pior. Suas energias acabam.
Por décadas nos ensinaram que fazer grandes queries e usar processamento batch era uma prática sadia, comum e até otimizada. Altera-se uma flag, um status, algumas datas, e pronto, o registro está pronto para a próxima etapa de processamento.
Então, agendada para rodar periodicamente, uma query, muito otimizada varre quase toda a base de dados em busca dos registos que possuam o tal estado mágico.
Esse é a estratégia default no passado.
Mas não é, nem de longe, uma estratégia eficiente, sequer inteligente. Quanto maior o dataset, maior é a degradação de performance ao longo do tempo.
Ao mesmo passo que exaltamos e achamos incríveis os serviços que nunca param, nossos sistemas sofrem de narcolepsia, parando e dormindo a cada 5 minutos para esperar A GRANDE QUERY, ser processada.
Essa forma de trabalhar é ineficiente no mundo do big data, é ineficiente no mundo das milhares de transações por minuto. Esse formato exige muito mais infraestrutura do que deveria, e dá para fazer muito mais, gastando muito menos.
Pensar que possa ser mais eficiente processar cada mensagem individualmente é disruptivo.
Fazer uma esteira de processamento contínuo, sem a necessidade de batch, otimiza e reduz o consumo ao seu banco de dados.
Esse é um dos segredos para aumentar a escala de processamento, mantendo ou até reduzindo sua infra.
Reduzir acoplamento é algo que falamos muito no dia-a-dia do desenvolvimento, mas aqui extrapolamos essa ideia ao limite, mostrando como o processamento assíncrono, garante a resiliência do seu workflow, mesmo que contenha operações síncronas.
Essas empresas usam RabbitMQ em seus projetos
* Dados fornecidos pela StackShare API e AMQP.org
Fique ligado para a programação completa deste ano, que está chegando em breve.
🔥 gaGO.io | 🐳 Docker Definitivo | 🎖 Microsoft MVP | 👥MTAC | 💼Software & Solution Architecture
Começar minha carreira na Petrobrás me possibilitou entender quais são as preocupações de projetos grandes e diferenciar, CRUD's de sistemas realmente complexos.
Meu primeiro contato com o RabbitMQ não foi assistido, amparado por alguém que já usasse anteriormente. Nda disso: Eu tive de tomar a decisão com base nos meus estudos. Tínhamos um problema com o processo de importação de mídias (músicas, vídeos etc).
Ele dependia de um programador que abria o visual studio, alterava algumas strings e executava o projeto com o debugger ativo. Eu não precisava somente de escalabilidade, eu precisava também de automação.
Encontrar uma ferramenta para auxiliar na escala do processo de importação foi uma tarefa que me tomou pelo menos 3 semanas.
Nesas 3 semanas eu me dediquei quase que exclusivamente a essa escolha, antes disso eu havia feito pequenas investidas para entender quais eram as possibilidades.
A primeira vez que tentei entender o RabbitMQ não foi amor à primeira vista. Eu ainda estava embuído do ranço e do rancor pela ineficiência do MSMQ e ingenuamente acreditei que pudesse ser mais do mesmo. No entanto, o fato da SpringSource estar por trás do RabbitMQ me chamou a atenção positivamente.
Ao olhar quem estava usando a solução no mercado, eu entendi que estava diante de algo imponente, e não poderia descartar sem antes estar muito certo da minha decisão.
Na reta final o RabbitMQ entre os finalistas, e para decidir entre eles eu fui obrigado a entender de fato o que o RabbitMQ faz e como faz.
Entre os novos conceitos, o mais disruptivo e com certeza o que me conquistou foi o acknowledgement, ou simplesmente Ack: Uma feature tão simples quanto poderosa, capaz de suprimir meses de desenvolvimento.
A cereja do bolo, para consolidar a decisão era o standard AMQP, que era parte de um consórcio com os principais players do mercado de “filas”, incluindo Microsoft, Red Hat, VMWare, WSO2 e muitos outros.
Desde então eu fiz inúmeras implantações, de diversos tamanhos e para diversas finalidades.
E também passei a falar sobre RabbitMQ para a comunidade .NET.
sobre o evento
Parte desse processo envolve a minha experiência diária usando RabbitMQ, e eu uso para diversos assuntos em diversos momentos.
Isso permite descobrir coisas que você não encontra no mundo lá fora.
2 dias dedicados a RabbitMQ e Mensageria
Sábado
09 de Janeiro de 2021Como o processamento contínuo pode melhorar a relação com o consumo de hardware para alcançar grandes cargas de trabalho e como o modelo de grandes queries e processamento batch é oneroso.
Como mapeamos tecnologicamente as iterações do negócio em um mundo baseado em mensageria.
Entendendo todos os componentes do RabbitMQ e como se comportam. Virtual Host, Filas, Exchange, Binds e Policies
ALMOÇO - 12PM
Hands on
Publicando e Consumindo Mensagens
Permitindo escala horizontal de serviços e demonstrando quais são os tradeofs de escalar horizontalmente. Como resolver necessidade de lock.
Reprocessamento e tolerância a Dontime. Como lidar com aplicações que podem ficar offline. O que fazer? Como configurar? O que é necessário?
Domingo
10 de Janeiro de 2021Recap de Todo o dia 1
Exemplos e Tira-dúvidas
ALMOÇO - 13PM