Quando ou onde RabbitMQ é usado?
Usando RabbitMQ na vida real
O caso de uso mais comum para RabbitMQ é um único produtor, uma única fila de consumidor. Pense nisso como um canal em que um aplicativo coloca mensagens em uma extremidade do canal e outro aplicativo lê as mensagens que saem da outra extremidade. As mensagens são entregues na ordem de primeiro a entrar, primeiro a sair. Essas mensagens podem ser comandos ou conter dados importantes. Parece fácil, mas onde esse tipo de arquitetura pode ser aplicado? É hora de entender quando e por que o enfileiramento de mensagens se destaca!
Filas de mensagens entre microsserviços
As filas de mensagens geralmente são usadas entre microsserviços, mas o que isso significa? O estilo de arquitetura de microsserviços divide o aplicativo em pequenos serviços, com o aplicativo concluído sendo a soma de seus microsserviços.
Os serviços não estão estritamente ligados uns aos outros. Em vez disso, eles usam, por exemplo, filas de mensagens para se manter em contato. Um serviço envia mensagens de forma assíncrona para uma fila e essas mensagens são entregues ao destino correto quando o consumidor está pronto. A arquitetura de microsserviço é frequentemente comparada e contrastada com a arquitetura monolítica, em que todo o sistema é agrupado em um único software.
Um aplicativo não é apenas responsável por uma tarefa específica; na verdade, ele executa todas as etapas necessárias para concluir uma função específica. Monólitos se comunicam dentro do sistema, já que todas as partes estão executando no mesmo processo. Este sistema é altamente acoplado, uma vez que cada função depende das outras.
Em um exemplo de loja virtual construída em um estilo de arquitetura monolítica, um sistema lida com todas as funções, incluindo estoque, pagamentos, avaliações e classificações e assim por diante, conforme mostrado no diagrama a seguir:
Uma loja virtual construída na arquitetura de microsserviço, por outro lado, significa que cada parte do sistema é uma atividade individual. Um microsserviço lida com revisões e classificações. Então, há outro estoque, e depois outro para pagamentos e assim por diante, conforme mostrado no diagrama a seguir:
Cada par de solicitações e respostas se comunica de forma independente. Isso é conhecido como comunicação sem estado. Embora muitos microsserviços estejam envolvidos, eles não dependem diretamente uns dos outros. Outro caso de uso típico para RabbitMQ é como uma fila de tarefas, que abordaremos na próxima seção.
Evento e tarefas
Eventos são notificações que informam aos aplicativos quando algo aconteceu. Um aplicativo pode se inscrever em eventos de outro aplicativo e responder criando e gerenciando tarefas para si mesmo. Um caso de uso típico é quando o RabbitMQ atua como uma fila de tarefas que lida com operações lentas. Vamos dar uma olhada em dois exemplos disso:
- Imagine um aplicativo de mídia social como o Instagram. Cada vez que alguém publica uma nova postagem, a rede (seguidores) precisa ser informada sobre a nova postagem. Esta operação pode consumir muito tempo. Milhões de pessoas podem estar tentando realizar a mesma tarefa ao mesmo tempo. O aplicativo pode, com o uso de filas de mensagens, enfileirar uma tarefa na fila para cada postagem conforme ela chega. Quando o trabalhador recebe a solicitação, ele recupera uma lista de seguidores do remetente e atualiza cada um deles.
- Como outro exemplo, pense em uma ferramenta de campanha de boletim informativo por email que está enviando milhares de emails para milhares de usuários. Com um cenário possível em que muitos usuários acionam mensagens em massa ao mesmo tempo. A ferramenta de campanha de boletim informativo por e-mail precisa ser capaz de lidar com esse volume de mensagens. Todos esses e-mails podem ser adicionados a uma fila push com instruções para o trabalhador sobre o que enviar e para quem. Cada email é tratado, um por um, até que todos os emails sejam enviados.
Explorando os benefícios do enfileiramento de mensagens
- Desenvolvimento e manutenção mais fáceis: Dividir um aplicativo em vários serviços permite responsabilidades separadas e dá aos desenvolvedores a liberdade de escrever código para um serviço específico em qualquer idioma escolhido. Será mais fácil manter o código escrito e fazer alterações no sistema; ao atualizar um único esquema de autenticação, apenas o módulo de autenticação deve ter código adicionado para teste, sem interromper quaisquer outras funções.
- Isolamento de falha: Uma falha pode ser isolada em um único módulo e, portanto, não afetará outros serviços. Por exemplo, um aplicativo com um serviço de relatório temporariamente fora de funcionamento não afetará os serviços de autenticação ou pagamento. Como outro exemplo, fazer alterações no serviço de relatórios ainda permite que os clientes realizem transações essenciais, mesmo quando eles não podem visualizar relatórios.
- Níveis aprimorados de velocidade e produtividade: Diferentes desenvolvedores podem trabalhar em diferentes módulos ao mesmo tempo. Além de acelerar o ciclo de desenvolvimento, a fase de teste também é impactada pelo uso de microsserviços e filas de mensagens. Isso ocorre porque cada serviço pode ser testado por conta própria para determinar a prontidão do sistema geral.
- Escalabilidade aprimorada: os microsserviços também permitem o dimensionamento sem esforço à vontade. É possível adicionar mais consumidores se a fila de mensagens estiver crescendo. Adicionar novos componentes a apenas um serviço é fácil de fazer sem alterar nenhum outro serviço.
- Fácil de entender: como cada módulo em uma arquitetura de microsserviço representa uma única funcionalidade, é fácil conhecer os detalhes relevantes para uma tarefa. Por exemplo, a contratação de um consultor para um único serviço não exige que eles entendam todo o sistema.
Nenhum comentário:
Postar um comentário