Arquitetura de Microsserviços: Padrão Saga Orquestrado

Nesta aula, serão abordados conceitos da Event-Drive Architecture (EDA) ou Arquitetura Orientada a Eventos, e como o Padrão Saga e o Padrão Outbox se encaixam nesses conceitos.

Nesta aula, será abordado o conceito e aplicação do Apache Kafka, uma das maiores e mais robustas ferramentas para streaming de dados atualmente.

Nesta aula, serão abordados os conceitos de tópicos, producers, consumers, consumer groups, offsets, partições, réplicas, nós e cluster no Apache Kafka, assim como uma explicação de como se comportam.

Nesta aula, entraremos no conceito de idempotência e como ele se aplica ao Apache Kafka, os problemas que a falta de tratamento de eventos idempotentes podem trazer, e também estratégias de como tratar.

Para finalizar esta seção, faremos um breve comparativo entre o Apache Kafka e o RabbitMQ, e também especificar a diferença entre filas e tópicos.

Nesta aula, irei apresentar os arquivos de base para começarmos o desenvolvimento do projeto, e também as ferramentas que serão utilizadas.

Nesta aula, irei mostrar como e de onde foi tirada as definições dos serviços do Kafka e do Redpanda Console, e também iremos criar os nossos 3 serviços de PostgreSQL e nosso serviço de MongoDB. Iremos acessar os 3 bancos de dados PostgreSQL com o DBeaver, e iremos acessar o MongoDB via cli (interface de linha de comando) diretamente do Docker.

Nesta aula, iremos conectar nossas aplicações Spring Boot ao MongoDB e ao PostgreSQL, e também já iremos configurar nossas conexões utilizando Variáveis de Ambiente.

Nesta aula, iremos apenas criar as configurações de acesso ao Apache Kafka nas aplicações Spring através do arquivo de configuração, application.yml.

Nesta aula, iremos definir os nomes de todos os tópicos existentes na nossa arquitetura, e já iremos inseri-los no nosso arquivo application.yml para deixar o mapeamento correto em cada serviço. Iremos também criar o enum ETopics no Orchestrator-Service para mapear todos os tópicos da arquitetura.

Nesta aula, criaremos a classe KafkaConfig, e também as configurações de Producers e Consumers, que serão replicadas em todos os demais projetos.

Com a classe KafkaConfig criada e os consumers/producers definidos, iremos apenas mapear e criar todos os tópicos que deverão subir assim que as aplicações forem inicializadas.

Nesta aula iremos criar o serviço dos 5 microsserviços no nosso docker-compose já aplicando as configurações das variáveis de ambiente.

Nesta aula, iremos simplesmente subir todas as aplicações e validar, via logs dos containers, se todas as aplicações se conectaram aos bancos de dados e ao Kafka com sucesso, totalmente dentro do Docker, e também validaremos se os tópicos foram criados com sucesso.

Nesta aula, iremos estruturar os diretórios dos microsserviços, dividindo as camadas de configuração e core, assim como as divisões de responsabilidades nos serviços.

Nesta aula, iremos realizar a criação de todas as DTOs que serão compartilhadas entre os microsserviços, e que possuirão atributos em comum e necessários para o desenvolvimento.

Nesta aula, iremos realizar a criação do utilitário de JSON dos microsserviços, para converter String em JSON, e JSON em Objeto. Também iremos realizar a configuração de exception de validação de erros.

Nesta aula, criaremos os producers de todas as aplicações, que terão a mesma estrutura, apenas com tópicos diferentes.

Nesta aula, criaremos os consumers de todas as aplicações, que terão a mesma estrutura, apenas com tópicos diferentes. Também iremos rodar todas as aplicações testando os consumers criados.

Nesta aula, serão criadas as DTOs das requisições realizadas pelos endpoints de Order (pedidos) e Events (notificações). Também já serão definidas as anotações do MongoDB nas classes de Document (Order e Event), e também já criaremos as classes Repository do Spring Data MongoDB.

Nesta aula, iremos criar a nossa classe OrderService e EventService, responsáveis por gerar um pedido, gerar um evento e enviar ao Producer do Kafka para iniciar toda a nossa Saga.

Nesta aula, iremos criar o método para salvar um evento de notificação, logo após ser consumido pelo tópico notify-ending.

Nesta aula, criaremos todos os Endpoints da API. Iremos criar o endpoint POST para criar um pedido, e também os endpoints GET para recuperar os eventos salvos, tanto pelos filtros de ID do Pedido (orderId) e ID da Transação (transactionId), e também para buscar todos os eventos em ordem de criação decrescente.

Nesta aula, iremos executar a aplicação após todo o desenvolvimento, e testaremos todos os endpoints: criar pedido, buscar pedido pelo ID do pedido, buscar pedido pelo ID da transação e buscar todos os pedidos. Iremos também testar nosso consumer simulando uma resposta da nossa saga, e vendo tudo sendo atualizado no MongoDB com sucesso.

Nesta aula, criaremos nossas 2 entidades de banco de dados: Product e Validation, responsáveis por guardar os produtos existentes, e validar se um pedido está com os produtos corretos para seguir na saga.

Nesta rápida aula, iremos apenas criar um arquivo SQL que sempre será executado quando subirmos a aplicação, para que tenhamos nossos produtos já inseridos no banco de dados toda vez que a aplicação subir.

Nesta aula, iniciaremos a criação da nossa classe ProductValidationService, e também já estaremos criando toda a validação de sucesso dos produtos da saga.

Nesta aula, continuaremos o desenvolvimento da nossa classe ProductValidationService, e iremos finalizá-la criando a lógica para a realização do rollback da validação dos produtos da saga.

Nesta aula, iremos testar rodar a aplicação, e também iremos utilizar o Redpanda-Console para publicar eventos de sucesso e falha, para testar a lógica dos status de envio ao Producer. Iremos também validar os dados no PostgreSQL.

Nesta aula, iremos criar a nossa entidade de banco de dados Payment, que irá registrar dados de pagamento. E também já incluiremos o PaymentRepository para habilitar as funcionalidades de acesso ao banco de dados.

Nesta aula iremos criar nossa PaymentService, e já realizaremos toda a lógica para criar um pagamento com status PENDING (PENDENTE).

Nesta aula iremos continuar o desenvolvimento da PaymentService, e já realizaremos toda a lógica para criar atualizar um pagamento para o status SUCCESS (SUCESSO). Também já realizaremo o cálculo do total de itens do pedido, e do valor total do pedido.

Nesta aula, criaremos a lógica de realização de estorno (rollback), para mudar o status do pagamento para REFUND (reembolso). Iremos também

Essa aula é apenas um adendo à lógica de realização de estorno, o rollback do caso de falha, pois há um bug na lógica desenvolvida. Aqui, iremos basicamente realizar a correção e simular o problema que foi corrigido no ambiente.

Nesta aula, iremos criar as 2 entidades de banco de dados necessárias para este microsserviço, são elas Inventory e OrderInventory. Elas irão guardar dados dos valores disponíveis em estoque para cada produto. Já estaremos também criando as classes Repository de acesso ao banco de dados.

Nesta aula, iremos apenas criar o script SQL que irá inserir os valores de estoque disponíveis para cada produto. Assim que a aplicação subir, teremos os dados já definidos.

Nesta aula, criaremos a classe InventoryService, e desenvolveremos a lógica para criar os itens de estoque do pedido, que registrarão os dados necessários para informar a quantidade de itens do pedido, a quantidade de itens em estoque no momento, e a nova quantidade após a atualização, para mantermos o controle do pedido e do estoque.

Nesta aula, criaremos a lógica para atualizar o estoque (dar baixa). Iremos também validar quando um produto está fora de estoque conforme a quantidade desejada no pedido.

Nesta aula, implementaremos o método de rollback do inventário para voltar o estoque aos valores anteriores no caso de alguma falha, e já iremos também ligar o consumer com os métodos de atualização e rollback de estoque.

Nesta aula, iremos rodar a aplicação com o PostgreSQL, Kafka e Redpanda-Console para testar os consumers para atualizar e realizar rollback no estoque, e validar todos os casos que desenvolvemos.

Nesta aula, iniciaremos o desenvolvimento da classe Saga Handler, que irá realizar o mapeamento de toda a lógica de orquestração dos tópicos para cada serviço em cada status diferente.

Nesta aula, iniciaremos o desenvolvimento da classe Saga Execution Controller, que irá realizar a lógica para logar a saga e recuperar o próximo tópico da execução.

Nesta aula, iniciaremos o desenvolvimento da classe OrchestratorService, que irá realizar a lógica para receber os dados da saga e redirecionar para o producer conforme a necessidade da execução atual.

Nesta aula, iremos apenas rodar o microsserviço de orquestração e verificar se o que desenvolvemos está devidamente obedecendo à lógica que esperamos.

Nesta aula, iremos executar toda nossa arquitetura desenvolvida até então, rodando com Docker-Compose, executando os endpoints e o Kafka, e visualizando tudo com o Redpanda-Console e as bases do PostgreSQL!

Nesta aula, iremos comparar tudo que foi desenvolvido no conteúdo prático do curso ao longo das 9 seções, e iremos comparar tudo que foi desenvolvido com os temas teóricos sobre Transações Distribuídas, Padrão Saga, Kafka e conceitos apresentados, para validar se o que foi implementado está condizente com o material de estudo teórico.

Nesta aula, irei dar algumas dicas de como encontrar, compreender e estudar a infinidade de padrões existentes para a implementação de arquitetura de microsserviços, e dicas do que continuar estudando neste tema, e nos demais que também foram abordados durante o curso.