Mensageria com Python e RabbitMQ: integração assíncrona entre serviços

Explorando o projeto prático - Introdução

Apresentando o instrutor e o curso

Olá! Seja bem-vindo ao curso de mensageria do RabbitMQ. Meu nome é Stephen Batista. Atualmente, sou engenheiro de software em uma empresa de meios de pagamento e possuo 20 anos de experiência na área de desenvolvimento de software. Trabalhei em diversas empresas e com vários tipos de negócio. Hoje, estou trazendo este curso relacionado ao RabbitMQ.

Introduzindo o RabbitMQ e o projeto do curso

O RabbitMQ é uma das ferramentas de mensageria mais utilizadas no mundo, e temos certeza de que, com este curso, nós vamos aprender bastante. Neste curso, vamos trabalhar com um projeto real de e-commerce e fazê-lo operar de forma assíncrona. Ou seja, não vamos integrar diretamente com o meio de pagamento, com o pedido ou com o estoque, mas sim através da mensageria do RabbitMQ.

Explorando os conceitos do curso

Neste curso, nós vamos aprender conceitos como Producer (Produtor), Consumer (Consumidor), Dead Letter (Carta Morta) e várias outras coisas que certamente nos proporcionarão ainda mais experiência. Esperamos vocês neste curso!

Explorando o projeto prático - Fluxo atual da aplicação

Apresentando o projeto de checkout de E-Commerce

Olá, seja bem-vindo. Antes de começarmos a trabalhar, é importante entendermos qual é o projeto em que vamos atuar para que possamos fazer as modificações necessárias. O projeto em questão é um Checkout de E-Commerce.

Vamos imaginar que temos o nosso Checkout. Ele é responsável por receber as solicitações do mobile e do carrinho de compras no site. Com isso, já recebemos os dados do pedido e do cartão. O Checkout é responsável por realizar as seguintes integrações:

Explicando as integrações do sistema

A primeira integração é com o modo de pagamento, chamado de Payment. Ele é responsável por validar se a compra que a pessoa cliente está realizando pode realmente ser efetuada. Isso é importante porque, se não realizarmos o pagamento primeiro, não podemos retirar do estoque nem criar o pedido. Portanto, essa é a primeira ação que realizamos.

A segunda integração é com a parte do inventário, chamada de Inventory. O Inventory é responsável por retirar os itens do estoque.

A terceira integração é com o pedido, chamada de Order.

Descrevendo a estrutura organizacional e responsabilidades

Atualmente, o software com o qual trabalharemos possui três tipos de integração. Vamos imaginar que temos um sistema mobile. Tudo que está destacado em azul está fora do nosso time. Estamos simulando que trabalhamos para uma grande empresa, mas não somos responsáveis por todos os sistemas. Nossa responsabilidade é apenas a parte de checkout. Nosso time é o time de checkout, e há um time de integração com pagamento, um time responsável pelo estoque, um time responsável pelo pedido, um time de mobile e também um time do site.

Esses dois últimos times se integram no checkout para evitar múltiplas integrações. Eles já trazem alguns dados prontos, como os dados dos produtos que queremos comprar, os dados do cartão de crédito e o endereço para entrega. Ou seja, todos esses dados já chegam na parte de integração com o sistema do aplicativo ou do site. Além disso, para registro, temos nosso banco de dados. Tudo que passa pelo checkout é registrado aqui.

Funcionamento e desafios do sistema atual

A ideia principal é que o checkout funcione como uma fachada. O que é uma fachada? Ela engloba todas essas integrações: integração de pagamento, integração de estoque e integração de pedido. O último passo é que, quando compramos um pedido, ele sistematicamente faz com que o produto seja entregue ao cliente final, ou seja, o produto comprado pelo e-commerce é entregue na casa do cliente.

Atualmente, este é o software que temos. Já temos esse checkout construído, e é isso que mostraremos depois. No entanto, o checkout possui alguns problemas. Imagine que isso é um microserviço. Nós cuidamos desse microserviço do checkout, mas hoje toda a comunicação é síncrona, ou seja, envia, espera, envia, espera. A empresa enfrenta esse problema atualmente, e é isso que vamos abordar no curso de mensageria: como resolver este problema.

Explorando o projeto prático - Saga

Introduzindo o conceito de saga

Existe um conceito muito importante, mas que poucas pessoas conhecem, que é o conceito de saga. O que é uma saga? Saga é um processo que desejamos alcançar. Nesse caso, nossa saga é criar o pedido final. Passamos pelo pagamento, pelo inventário, mas a ideia é criar o pedido final. Essa é a nossa saga.

Existem dois tipos de saga. Uma delas é a que estamos implementando, chamada de orchestration saga (saga de orquestração). Essa saga de orquestração ocorre quando há um centralizador, no caso, o checkout, que conhece a ordem e o fluxo das regras. O checkout sabe que precisa fazer uma integração com o método de pagamento. Se der certo ou errado, ele sabe o que fazer. Se der certo, ele sabe que o próximo passo é o inventário. Se der certo novamente, ele sabe que o próximo passo é a ordem. Isso que acabamos de implementar é o que chamamos de saga.

Explicando a transição para saga de coreografia

O que queremos mudar neste projeto é para outro tipo de saga, que é a saga de coreografia. Nesse tipo de saga, o processo começa em um ponto, vai para outro processo, que, nesse caso, é outro software ou aplicação, e então segue para outro processo. É uma coreografia. Cada objeto atual sabe para qual próximo chamar, mas não conhece a saga final. Por isso, é chamada de coreografia.

Muito provavelmente, o que faremos, dados os problemas que já identificamos, é mudar o sistema atual. Observamos que ele apresenta problemas, pois quando um dos sistemas falha, tudo fica muito lento. Ou, se um desses sistemas falhar, não conseguimos avançar. Muitas vezes, enfrentamos apenas um problema de pagamento momentâneo. Imagine perder uma venda apenas porque, momentaneamente, houve um problema de pagamento. Isso é muito ruim. Por isso, vamos mudar nosso tipo de saga.

Implementando a nova estrutura de coreografia

O que acontecerá aqui, basicamente, é que vamos deletar essas setas.

Basicamente, o que nós vamos fazer é integrar outros serviços dentro do nosso time. Por exemplo, teremos o serviço de pagamento. De forma assíncrona, o checkout enviará uma solicitação e esquecerá, pois o serviço de pagamento será responsável por processar diretamente.

Após isso, o serviço de pagamento saberá que deve chamar o serviço de inventário de forma assíncrona. Provavelmente, teremos outro serviço, que é o serviço de inventário. Este serviço de inventário, de alguma forma, chamará diretamente o sistema de inventário.

Detalhando a comunicação entre serviços

Além disso, teremos um último serviço, que é o serviço de pedido, que chamará o sistema de pedidos. Na verdade, a comunicação entre os serviços é direta e indireta, dependendo do contexto.

Nós estruturamos nossa coreografia de forma que o checkout chama o serviço de pagamento de maneira assíncrona, que por sua vez chama diretamente o serviço de pagamento. De forma indireta e assíncrona, o serviço de pagamento chama o serviço de inventário, que então chama diretamente o endpoint de inventário. O mesmo se aplica ao sistema de pedidos.

Dessa forma, mudamos de uma orquestração, onde um único ponto central sabe como chamar os serviços, para uma coreografia. Cada serviço sabe para onde deve enviar suas solicitações.

Concluindo com a solução de mensageria

Tudo que está destacado em verde faz parte do nosso time. Vamos resolver isso através de mensageria.

Sobre o curso Mensageria com Python e RabbitMQ: integração assíncrona entre serviços

O curso Mensageria com Python e RabbitMQ: integração assíncrona entre serviços possui 156 minutos de vídeos, em um total de 35 atividades. Gostou? Conheça nossos outros cursos de Python 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:

• capitulo