Node.js: mensageria e arquitetura orientada a eventos

Entendendo comunicação assíncrona e mensageria - Apresentação

Apresentando o instrutor e o curso

Seja bem-vindo ao curso de Node.js Arquitetura Orientada a Eventos. Meu nome é Thiago Martins, sou engenheiro de software sênior, especialista em back-end, principalmente em Node.js e NestJS, e serei o instrutor deste curso.

Audiodescrição: Thiago é um homem branco, com cabelo castanho curto e barba curta. Ele usa óculos e, ao fundo, há duas poltronas e uma estante de livros.

Se você é uma pessoa desenvolvedora interessada em se aprofundar na técnica de integração entre sistemas e na comunicação entre sistemas, principalmente de maneira assíncrona, utilizando ferramentas e padrões de mensageria, este curso é para você.

Explorando a comunicação entre sistemas

O que aprenderemos ao longo deste curso? Primeiramente, vamos entender como integrar sistemas utilizando tanto a comunicação síncrona quanto a assíncrona. O foco será na comunicação assíncrona, mas é importante compreender a diferença entre as duas.

Em seguida, aprenderemos sobre os padrões de integração. Uma das ideias deste curso é trazer uma carga teórica relevante, mas não maçante, para que possamos entender que, ao comunicar e criar soluções de comunicação entre sistemas, já existem padrões estabelecidos há muitos anos que são úteis tanto para desenhar quanto para implementar essas comunicações.

Discutindo filas, mensagens e padrões de distribuição

Além disso, vamos discutir sobre filas e mensagens, abordando as garantias de entrega de sistemas, como At Least Once, At Most Once e Exactly Once, que serão detalhadas ao longo do curso.

Também falaremos sobre padrões de distribuição de mensagens nessas arquiteturas de mensageria, como o Fun In, Fun Out e o FIFO (First In, First Out).

Implementando padrões e casos de uso

Discutiremos as diferenças e os casos de uso entre filas ordenadas e paralelas, e implementaremos vários desses padrões mencionados, em memória, utilizando Event Emitter. Isso será feito em conjunto com um projeto que utilizaremos, que será um e-commerce, servindo como pano de fundo para entender quais são os casos de uso em que a mensageria faz sentido e os problemas que ela resolve.

Utilizando RabbitMQ e aplicando conceitos avançados

Na segunda parte do curso, começaremos a utilizar o RabbitMQ, que é a implementação que possivelmente teremos em sistemas em produção. Aprenderemos como aplicar as Worker Queues no RabbitMQ, entenderemos o que é o Fair Dispatching e como implementá-lo. Também faremos a implementação de Publisher Subscribe dentro do RabbitMQ. Utilizaremos o conhecimento da primeira parte, sobre os padrões de integração, para implementar e demonstrar como fazemos com o RabbitMQ.

A parte interessante é que, ao sairmos da teoria para a implementação, algumas mudanças e modificações são necessárias. Por fim, discutiremos como utilizamos Dead Letter Exchanges ou Dead Letter Queues no RabbitMQ, e como podemos aplicar algumas configurações específicas utilizando políticas. Discutiremos por que elas são mais benéficas do que configurar as filas diretamente no RabbitMQ.

Preparando-se para o curso

Para que possamos absorver e aprender melhor todos os conceitos que propomos apresentar neste curso, é interessante que já tenhamos um conhecimento prévio em Node.js e TypeScript, pois toda a implementação utilizará ambos. Também é importante ter familiaridade com Docker e Docker Compose, pois para levantar a infraestrutura do RabbitMQ utilizaremos o Docker Compose com uma imagem já pré-definida.

Esperamos que estejam animados, será um curso interessante, com uma boa carga de teoria e prática. Nos encontramos no próximo vídeo para começarmos a discutir o assunto.

Entendendo comunicação assíncrona e mensageria - A importância da comunicação entre sistemas

Para iniciar nosso curso de mensageria com Node.js, é relevante discutirmos um ponto frequentemente negligenciado por nós, pessoas desenvolvedoras ou da área de tecnologia. Trata-se de um tema central para a mensageria: a comunicação entre sistemas. Abordaremos um assunto que talvez já seja familiar, mas é necessário discutir alguns detalhes para que fique claro por que precisamos de mensageria.

Começamos com a pergunta: por que dois sistemas precisam se comunicar? Isso ocorre porque, atualmente, qualquer sistema na internet não contém toda a lógica dentro de si. Por exemplo, se um sistema possui uma parte de pagamento, dificilmente terá toda essa lógica internamente. Assim, sistemas precisam se comunicar. Essa comunicação acontece através da internet. Consideremos um exemplo: um e-commerce que precisa acessar um sistema de pagamento. Quando alguém fecha uma compra, é necessário processar o pagamento, geralmente por meio de APIs REST que utilizam o protocolo HTTP. O e-commerce envia uma requisição ao sistema de pagamento e possivelmente recebe uma resposta.

Explorando os desafios da comunicação entre sistemas

Um detalhe crucial que muitas vezes negligenciamos é que essa comunicação entre sistemas possui diversos pontos de falha. Quando o sistema de e-commerce envia uma requisição, ela sai da máquina onde está hospedado, passa pelo DNS, que transforma o endereço digitado em um endereço IP, e segue para o roteador, o servidor de internet e o backbone da internet, podendo atravessar cabos interoceânicos até chegar ao outro sistema. A requisição pode falhar ao sair do roteador ou do backbone até o outro sistema. Na resposta, quando o sistema de pagamento precisa responder, também pode haver falhas.

Parte desses problemas é resolvida por protocolos como o TCP, que realiza um handshake (aperto de mão) para garantir que os sistemas estão se comunicando e conseguem enviar pacotes. No entanto, isso não garante que a mensagem sempre chegará, pois falhas podem durar mais tempo e o TCP não assegura a entrega. Vamos utilizar um exemplo para explorar como resolver esse problema.

Analisando a comunicação síncrona em um e-commerce

Imagine uma loja de e-commerce chamada Megaloja, que vende computadores e celulares. Abordaremos um cenário em que Joãozinho quer comprar um computador na Megaloja. Ele adiciona itens ao carrinho, como um monitor, e clica para finalizar o pedido. Vamos analisar dois modelos de comunicação: síncrono e assíncrono, destacando suas diferenças.

Na comunicação síncrona, quando Joãozinho confirma o pedido, o front-end envia uma requisição ao sistema de pedidos. Joãozinho aguarda enquanto o sistema de pedidos verifica o estoque antes de confirmar o pedido. O sistema de pedidos envia uma requisição ao sistema de estoque, que confirma a disponibilidade. Em seguida, verifica-se se o pagamento pode ser processado, enviando uma requisição ao sistema de pagamento. Cada requisição leva tempo, e durante esse processo, Joãozinho vê uma tela de carregamento. Finalmente, ele recebe a confirmação de que o pedido foi concluído.

Destacando as limitações da comunicação síncrona

Esse processo pode ser rápido, em milissegundos, mas também pode demorar segundos ou, em casos de falhas críticas, até minutos. Se isso ocorrer com frequência, em situações de pico, como na Black Friday, o sistema pode ficar sobrecarregado, resultando em requisições perdidas e usuários frustrados.

Vemos claramente um problema na comunicação síncrona, que não é tão adequada em alguns cenários, como quando vários sistemas se integram e precisam se comunicar para responder ao usuário final. Por isso, temos a alternativa da comunicação assíncrona, que é o foco do nosso curso. Basicamente, funciona da seguinte maneira: quando uma pessoa usuária faz uma requisição para a compra de um produto e clica em confirmar o pedido, o nosso sistema de pedidos já responde imediatamente, informando que o pedido está confirmado e em processamento. Possivelmente, já tivemos essa experiência ao comprar em alguma loja ou e-commerce, onde, após clicar, pode demorar um pouco para processar o pedido. Depois, acompanhamos as etapas, como a confirmação do pagamento, a verificação do estoque, o envio do produto e a emissão da nota fiscal. Nesse meio tempo, a pessoa usuária já vê uma tela de confirmação e sai satisfeita, enquanto, nos bastidores, o sistema de pedidos se comunica com outros sistemas por meio de mensagens.

Explicando a comunicação assíncrona e suas vantagens

Essas mensagens são enviadas do sistema de pedidos para o sistema de estoque através de um componente chamado fila, ou, de forma mais genérica, um canal. Um canal é uma comunicação, um caminho lógico entre dois sistemas, pelo qual passa uma mensagem que deve ser comunicada entre ambos. O sistema de pedidos envia uma mensagem na fila para checar o estoque. Quando a mensagem chega ao sistema de estoque e é verificada, outra mensagem é enviada para uma segunda fila chamada "estoque verificado". Essa segunda fila envia uma mensagem de resposta para o sistema de pedidos. A partir daí, outras ações podem ser realizadas, como verificar o pagamento. O mesmo processo de envio de mensagem ocorre através de uma nova fila chamada "confirmar pagamento", que chega ao sistema de pagamento. Após o processamento, uma resposta é enviada por meio de outro canal chamado "pagamento confirmado", retornando ao sistema de pedidos.

Dessa forma, garantimos que a pessoa usuária não precise esperar muito tempo para ver que seu pedido está confirmado e possa acompanhar as etapas do processo, recebendo notificações por e-mail. No entanto, ainda há a possibilidade de falhas na requisição durante o caminho, pois continuamos utilizando a internet, que é suscetível a falhas em diversos pontos. Em sistemas de mensageria, temos algumas garantias de entrega. Por exemplo, se o sistema de pedidos envia uma mensagem para o sistema de estoque, há pontos de falha, como a mensagem não chegar à fila de compras. Se isso ocorrer, o sistema de fila geralmente possui mecanismos para que o produtor da mensagem reenvie-a caso não haja confirmação de recebimento. Se a mensagem falhar ao sair da fila para o segundo sistema, o sistema de mensageria mantém o estado e pode reenviar a mensagem até que ela chegue ao sistema de estoque. Existem mecanismos de confirmação que abordaremos em detalhes mais adiante no curso, mas, por enquanto, é importante saber que essa é uma característica crucial dos sistemas de fila e mensageria: a garantia das entregas. Assim, conseguimos dar uma resposta imediata aos clientes e processar as informações em segundo plano, além de garantir uma comunicação mais confiável entre os sistemas.

Comparando comunicação síncrona e assíncrona

Uma analogia útil entre comunicação síncrona e assíncrona é a seguinte: a comunicação síncrona é análoga ao telefone, onde, para que duas pessoas se comuniquem, ambas precisam estar presentes ao mesmo tempo. Não é possível ligar para alguém e se comunicar se a pessoa não atender, e se a ligação cair, a comunicação é interrompida. Já a comunicação assíncrona é semelhante ao envio de e-mails. Uma pessoa escreve um e-mail, que é enviado para o servidor, e a outra pessoa só abrirá o e-mail quando for conveniente para ela, podendo demorar um ou dois dias. Não é necessário que ambas estejam presentes ao mesmo tempo para se comunicar. Após algum tempo, a pessoa pode responder ao e-mail, e a comunicação estará completa.

Concluindo a introdução ao curso de mensageria

Essa introdução visa esclarecer o poder da mensageria e sua utilização. No próximo vídeo, discutiremos em mais detalhes os componentes principais dos sistemas de fila. Nos vemos no próximo vídeo.

Entendendo comunicação assíncrona e mensageria - Componentes de um sistema de mensageria

Agora que já discutimos uma introdução sobre mensageria, os tipos de comunicação e os problemas que eles resolvem, vamos detalhar os principais componentes de um sistema de mensageria. É importante destacar que os termos, elementos gráficos e padrões que utilizamos não são invenções nossas. Eles são baseados em padrões estabelecidos há mais de 20 anos por Gregor Hope e co-autores no livro famoso Enterprise Integration Patterns (Padrões de Integração entre Sistemas Empresariais). Este livro é considerado a "bíblia" da mensageria, semelhante ao livro Design Patterns do Gang of Four para orientação a objetos. Recomendamos fortemente a leitura deste livro para um aprofundamento, pois ele oferece muitos detalhes e exemplos adicionais que serão úteis ao longo deste curso.

Vamos começar com algumas definições simples, partindo do básico e, gradualmente, adicionando mais elementos de sistemas de mensageria que resolvem problemas que surgem com o tempo. Um sistema de mensageria, de maneira resumida, baseia-se na comunicação entre duas aplicações. Já discutimos isso anteriormente: temos uma aplicação de um lado e outra do outro, que se comunicam através de um canal. Este canal é um caminho lógico entre os dois sistemas, pelo qual uma mensagem é enviada. Essa mensagem pode ser um texto, um JSON, um objeto, entre outros formatos, que comunica algo entre os sistemas.

Definindo termos e conceitos básicos

É importante conhecer os termos originais em inglês, pois são bastante genéricos e aplicáveis a vários contextos e ferramentas de mensageria. O lado que envia uma mensagem é chamado de sender (remetente), a mensagem em si é o message (mensagem), o canal ou fila é chamado de channel (canal), e o lado que recebe a mensagem é o receiver (receptor). Os nomes são básicos e intuitivos.

Vamos avançar mais um passo agora. Digamos que nosso sistema, ou mega loja, que é nosso e-commerce que vende computadores e celulares, tenha uma característica específica: quando um pedido é feito, precisamos verificar se o item está em nosso estoque. Na verdade, temos dois subsistemas, pois essa mega loja tinha um sistema mais antigo que vendia apenas computadores e, depois de um tempo, passou a vender celulares também. Portanto, são dois sistemas de estoque diferentes.

Implementando o roteador para pedidos

Quando um pedido é feito, precisamos identificar o tipo desse pedido. Se for um computador, devemos checar o estoque no sistema de computadores ou de informática. Se for um celular, é necessário verificar no sistema de estoque de smartphones. Após isso, teremos a resposta se o pedido pode ser atendido. Como resolvemos isso em um sistema de mensageria, considerando que, pelo que vimos, só existe uma mensagem enviada do sistema de pedido para o sistema de estoque?

Introduzimos um novo componente chamado roteador, ou router em inglês. Funciona da seguinte maneira: quando um pedido é criado no sistema, o sistema de pedido envia uma mensagem para esse componente, que é o roteador. Ele verifica se o ID do item do pedido começa com C ou com S. Sabemos que itens com ID começando com C são computadores, e os que começam com S são smartphones. Assim, ele faz um roteamento simples: se o ID do item começa com S, envia para a fila ou canal "checar_S", que é para smartphones. Esse canal, por sua vez, envia uma mensagem para verificar o estoque no subsistema de inventário de smartphones. Do outro lado, se o ID começar com a letra C, envia uma mensagem para outra fila chamada "checar_C", que verifica se o computador está no inventário de computadores ou de informática.

Abordando a complexidade de pedidos com múltiplos itens

Aqui já temos a resolução de parte do problema. No entanto, existe um ponto além que precisamos abordar: quando fazemos um pedido em um sistema online, ele não contém apenas um item. Um pedido pode incluir um computador, um celular e um mouse, por exemplo. O que vimos até agora é que o roteador estava verificando apenas o ID do pedido e enviando para uma das duas filas, mas isso só funciona se houver um único item no pedido.

A questão é: como resolvemos para checar o inventário de cada item do pedido, e não do pedido como um todo? Não conseguimos utilizar a fila da maneira como está. No próximo vídeo, veremos como resolver esse problema.

Sobre o curso Node.js: mensageria e arquitetura orientada a eventos

O curso Node.js: mensageria e arquitetura orientada a eventos possui 409 minutos de vídeos, em um total de 83 atividades. Gostou? Conheça nossos outros cursos de Node.JS em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Entendendo comunicação assíncrona e mensageria
• Entendendo padrões de distribuição
• Garantindo entregas
• Introdução ao RabbitMQ
• Usando work queues
• Aplicando Pub/Sub
• Configurando roteamento