Como usar Arquitetura orientada a eventos na Digibee Integration Platform

A Arquitetura orientada a eventos (Event-driven architecture, EDA) é uma abordagem de design onde aplicações ou microsserviços desacoplados se comunicam de forma assíncrona por meio de eventos. Um evento representa uma mudança de estado, como a criação de uma nova conta de usuário ou o envio de uma avaliação de produto. Esses eventos são emitidos sem que o produtor saiba quais consumidores responderão a eles.

Os principais componentes da EDA incluem:

  • Produtores de eventos (Event producers): Fontes dos eventos acionados por mudanças de estado ou ações.

  • Consumidores de eventos (Event consumers): Serviços que reagem aos eventos e executam ações em resposta.

  • Brokers de eventos (Event Brokers): Atuam como intermediários, garantindo a entrega dos eventos dos produtores para os consumidores.

Neste artigo, você vai explorar os princípios fundamentais da EDA e vai aprender a implementá-los em suas integrações usando a Digibee Integration Platform, por meio de um caso prático.

Benefícios da Arquitetura orientada a eventos

Embora os benefícios a seguir sejam descritos no contexto de integrações, eles se aplicam amplamente à EDA em geral:

  • Processamento assíncrono: Permite que as integrações lidem com eventos de forma independente, aumentando a escalabilidade.

  • Desacoplamento: Produtores e consumidores não precisam ter conhecimento mútuo, promovendo flexibilidade.

  • Escalabilidade: As integrações podem ser escaladas de forma modular, permitindo o aumento independente de serviços para lidar com variações na carga.

  • Confiabilidade: Falhas são isoladas em serviços individuais, garantindo o funcionamento contínuo das outras integrações.

  • Respostas em tempo real: Consumidores podem priorizar suas funções e reagir aos eventos conforme eles ocorrem.

Alavancando a Arquitetura orientada a eventos com a Digibee

A Digibee utiliza uma arquitetura orientada a eventos baseada no padrão publisher/subscriber (pub/sub), onde eventos são publicados em um broker e consumidos por assinantes.

Os seguintes conectores colaboram para simplificar o processamento de eventos:

  • Event Publisher: Um conector que publica eventos com configuração mínima, incluindo o nome e a especificação do payload do evento.

  • Event Trigger: Escuta eventos específicos e inicia processos com base no payload do evento.

  • Pipeline Executor: Um conector que permite chamadas síncronas e assíncronas para outros pipelines previamente implantados.

Integração com Brokers de Eventos de Terceiros

A Digibee pode ser integrada com brokers de eventos de terceiros, como RabbitMQ, AWS SQS e Kafka, permitindo que você combine as capacidades da Digibee com soluções externas. Consulte a documentação sobre conectores de Queues and messaging para mais informações.

Por exemplo, o JMS Trigger utiliza filas JMS externas. Enquanto que o Event Publisher + Event Trigger utiliza as filas internas da Digibee. Embora as filas sejam hospedadas em locais diferentes, ambas as abordagens funcionam de maneira semelhante no acionamento e processamento de eventos.

Cenários para uso do padrão Pub/Sub

  • Acionar múltiplas tarefas simultaneamente: Publicando eventos para diversos consumidores , permitindo que as tarefas sejam executadas de forma independente.

  • Desacoplar integrações: Facilita a comunicação sem dependências diretas, eliminando a necessidade de espera por respostas.

  • Coordenar processos assíncronos: Permite que integrações "colaborem" em tarefas sem a necessidade de comunicação síncrona imediata.

Colocando a teoria em prática

Para compreender plenamente como a EDA pode ser aplicada em cenários reais, vamos explorar um caso prático. Este exemplo é dividido em duas partes: o pipeline Publicador (Publisher) e pipeline consumidor (Subscriber), cada um desempenhando um papel específico na integração geral.

O diagrama de sequência abaixo oferece uma visão geral do processo, mostrando como cada registro é enviado individualmente ao pipeline consumidor para processamento.

Parte I: O pipeline Publicador (Publisher)

Imagine uma empresa de varejo que precisa processar dados diários de pedidos e publicá-los como eventos para que outras integrações possam consumi-los. O objetivo é automatizar esse processo implementando um pipeline que:

  • Consulta um banco de dados pelos dados dos pedidos do dia.

  • Valida a resposta da consulta.

  • Publica cada registro em um pipeline consumidor para processamento adicional.

Vamos detalhar o processo passo a passo:

  1. Configuração do trigger

O pipeline é acionado todas as noites à meia-noite, utilizando o trigger Scheduler com a variável Midnight.

  1. Consulta ao banco de dados

O primeiro passo do fluxo envolve um conector de banco de dados que executa uma consulta para buscar os dados de pedidos do dia.

  1. Validação da resposta da consulta

  • Se a consulta retornar registros (rowCount > 0): O pipeline prossegue para a próxima etapa.

  • Se a consulta não retornar registros, o pipeline retorna uma mensagem indicando que "não há registros para processar".

  • Se a consulta retornar um erro, o pipeline segue pelo caminho de erro, onde o conector Throw Error emite o erro encontrado.

  1. Processando cada registro

O conector For Each itera sobre o conjunto de dados, processando cada registro individualmente.

  • Dentro da iteração, um conector JSON Generator (ou qualquer outro conector adequado ao caso de uso) transforma os dados conforme necessário.

  • Por fim, o conector Event Publisher envia o registro processado para o pipeline consumidor , pronto para fins de integração adicionais.

  1. Saída final

Após o processamento de todos os registros, o pipeline conclui sua execução.

Parte II - O pipeline Consumidor (Subscriber)

Uma vez que o evento é publicado pelo pipeline Midnight Scheduler, o pipeline consumidor entra em ação:

  1. Event Trigger

O pipeline é acionado quando um novo evento é publicado pelo Scheduler (pipeline #1).

  1. Etapa de validação

Como boa prática, é importante validar o payload recebido (com o Validator V2) contra o schema esperado, pois o pipeline consumidor pode receber eventos de múltiplos publicadores.

  1. Lógica subsequente

Após a validação, o payload é transformado conforme necessário e segue pelo fluxo para processamento adicional.

Considerações finais

Ao desacoplar produtores e consumidores de eventos e permitir a comunicação assíncrona, a Arquitetura Orientada a Eventos (EDA) permite que suas integrações lidem com grandes volumes de eventos, se adaptem a cargas de trabalho variáveis e mantenham a tolerância a falhas.

Incorporar esses princípios em sua estratégia de integração não só melhora o desempenho do fluxo de trabalho, mas também o prepara para escalar e evoluir conforme as necessidades da sua organização.

Recomendamos fortemente a exploração dos cursos de Arquitetura Orientada a Eventos I e II, bem como dos webinars de EDA disponíveis na Digibee Academy. Você também pode explorar mais possibilidades em nosso Portal de Documentação ou visitar nosso Blog para descobrir mais recursos e insights.

Se você tiver feedback sobre este "Caso Prático de Uso" ou sugestões para artigos futuros, adoraríamos ouvir você em nosso formulário de feedback.

Atualizado

Isto foi útil?