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:
Configuração do trigger
O pipeline é acionado todas as noites à meia-noite, utilizando o trigger Scheduler com a variável Midnight.
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.
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.
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.
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:
Event Trigger
O pipeline é acionado quando um novo evento é publicado pelo Scheduler (pipeline #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.
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?
