Eventos
12
min de leitura
18 de julho de 2019

Eventos, Event-Driven Architecture, e Async APIs

Ana Paula Borges
Líder Tecnológico de Inovação em Vendas @Ambev
Projeto API seguindo os conceitos RESTFull. Desenvolvimento da API em JavaScript, Java. Desenvolvimento de Microservices em Java. Desenvolvimento de integrações em IIB Broker. Serviços de modelagem para o protocolo SOAP. Desenvolvimento de sistemas em Graphql.
Mais sobre o autor

Um evento é toda e qualquer ação que provoque uma mudança sistêmica de estado. De acordo com Gartner, até 2020, a consciência situacional em tempo real e de origem de eventos será uma característica essencial para 80% das soluções empresariais digitais, e 80% dos novos ecossistemas empresariais exigirão apoio para o processamento de eventos.

Questões sobre Eventos, Event-Driven Architecture, e Async APIs estão ficando cada vez mais populares, mas por quê? E de que se trata tudo isso?

Quando trabalhamos com questões orientadas por eventos, o que nos interessa é um evento significativo para as atividades da organização, como o pedido de um cliente, a conclusão de uma transação de pagamento, entre outros. Chamamos esse evento de um evento comercial.

Event-Driven Architecture - ou EDA, como é conhecido pelos amigos mais próximos - é um padrão arquitetônico que promove a produção, detecção, consumo e reação a eventos comerciais.

EDA é uma forma de realizar a comunicação entre sistemas que consiste principalmente em operações assíncronas, além de permitir aplicações mais escaláveis e gerar menos acoplamento entre serviços, permitindo assim uma arquitetura altamente flexível.

É um modelo que não depende do tamanho de sua arquitetura, ou seja, pode ser adaptado a sistemas de qualquer tamanho. Há três componentes importantes do EDA:

  • Gerador(es) de eventos;  
  • Mediador ou corretor;
  • Consumidores de eventos.

Os geradores de eventos são responsáveis pela realização do evento. Pode ser, por exemplo, uma plataforma de dados do cliente, que, quando o cliente muda de endereço, é responsável pela geração do evento, que transmitirá esta ação aos consumidores. Os consumidores do evento são as partes interessadas no evento.

Tomemos, por exemplo, um cenário de seguro automóvel. Se um cliente se mudar para um endereço diferente, a parte interessada é o serviço de cotação, já que uma mudança na localização do cliente poderia afetar a taxa de seguro.

O mediador ou corretor é responsável por receber o evento e transmiti-lo aos consumidores. É importante que você compreenda bem sua própria necessidade e a combine com uma das topologias do EDA, mediador ou corretor, pois estabelecer corretamente o intermediário do evento é essencial para implementar com sucesso um EDA. Você sabe quando usar o mediador e quando usar o corretor? Vamos descobri-lo juntos!

Topologias de EDA

Mediador

O mediador é usado principalmente quando há necessidade de realizar manipulação ou orquestração no processamento de eventos. Nesta topologia, há quatro tipos de componentes principais: a fila, o mediador, os canais e os processadores (todos relacionados com os eventos). O fluxo do evento começa quando o cliente envia uma mensagem para a fila que é responsável pelo transporte do evento para o mediador. O mediador recebe o evento inicial e realiza sua orquestração enviando eventos assíncronos adicionais para os canais para realizar cada etapa do processo.

Os processadores, que ouvem nos canais, recebem o evento do mediador e realizam uma lógica comercial específica para processá-lo.

Há dois tipos de eventos nesta topologia, o evento inicial e o evento de processamento. Chamamos evento inicial o evento original que foi recebido pelo mediador, enquanto os eventos de processamento são aqueles que são gerados pelo mediador e recebidos pelos processadores. É necessário estar ciente de que o mediador do evento não realiza nenhuma lógica comercial, ele conhece apenas as etapas necessárias para processar o evento.

E é importante ter em mente que, independentemente de sua granularidade, o processador de eventos deve ser responsável pela execução de uma única tarefa comercial, e não pode contar com outros processadores para concluir sua tarefa.

Somos bastante teóricos, não somos? Que tal um exemplo de uso?

Imagine o cenário que mencionamos anteriormente, de uma seguradora - quando o cliente muda de endereço, é necessário recalcular o prêmio do seguro, pois pode ter mudado para um lugar mais perigoso, ou mesmo mais calmo, o que influencia diretamente as taxas pagas pelo segurado. Neste caso, podemos implementar uma solução com EDA, como mostrado na figura abaixo:

Neste exemplo, há o atendimento ao cliente, que é responsável por alterar os dados e acionar o evento de mudança de endereço na fila, após o qual o atendimento ao cliente segue seu fluxo normal. O mediador do evento pode ser notificado da chegada de um evento, ou mesmo verificar a fila para novas informações, tudo depende de como o usuário decide implementá-lo. O mediador, que conhece o fluxo que o evento deve seguir, notificará primeiro o serviço de cotação, que por sua vez recalculará a taxa do prêmio do seguro e devolverá o evento de processamento ao mediador.

O mediador verificará se ocorreu uma mudança na cotação e, se ocorreu, o serviço de notificação é o próximo a receber o evento e será responsável por notificar o cliente a respeito da mudança na tarifa do seguro. Se o valor não tiver sido alterado, o fluxo do evento termina aí mesmo. O mediador pode ser implementado, por exemplo, com o Apache Camel ou o Spring Integration.

Corretor

Quando temos um fluxo de eventos simples, no qual não precisamos realizar orquestração de eventos, usamos a topologia do corretor, que não tem um mediador central de eventos. Ela pode ser centralizada e conta com os canais que são utilizados no fluxo, que podem seguir o modelo de fila ou tópicos de mensagens, ou mesmo uma combinação dos dois. Os principais componentes da topologia do corretor são o corretor e os processadores.

Os corretores apóiam a comunicação multi-channel , e cada canal recebe um identificador, e o envio de apenas um tipo de mensagem para este canal é recomendado como boa prática. Agora, pensando no mesmo exemplo que mencionamos acima, vamos ver como as coisas funcionam se implementarmos a topologia do corretor:

Assim como com o mediador, o atendimento ao cliente colocará o evento de mudança de endereço na fila, mas neste cenário, não temos o mediador para orquestrar o evento. O serviço de cotação receberá o evento através da fila, o que pode ser feito através de uma estratégia de puxar ou empurrar, e realizará o processamento.

Se a tarifa do prêmio tiver sido alterada, o serviço de cotação colocará outro evento na fila de notificação, o que indicará que o serviço de notificação deve enviar a notificação X ao cliente Y. Se a tarifa do seguro não tiver sido alterada, o serviço de cotação encerrará o processamento sem acionar nenhum evento. Para esta solução, podemos usar o ActiveMQ, o Pub/Sub do Google, por exemplo.

Agora que já vimos as topologias, vamos dar uma olhada em alguns cenários que se encaixam em uma solução usando EDA?

De acordo com o livro de W. Roy Schulte Processamento de eventosExistem três cenários principais: divulgação de informações, que é quando temos em mente a necessidade de manter a consistência dos dados entre as diferentes aplicações e o evento principal não precisa passar por mudanças de dados antes de chegar aos processadores; consciência da situação, quando normalmente temos que analisar eventos de diferentes fontes para gerar uma nova notificação para um ou mais processadores; e integração de aplicações, na qual devemos considerar as abordagens que irão gerar um acoplamento mínimo entre as aplicações que estarão envolvidas na integração. Cada cenário exigirá uma forma diferente de implementação da arquitetura.

E quais são os princípios principais desta arquitetura?

  • Ela relata eventos atuais: as notificações devem sempre relatar um incidente.
  • Ele envia notificações: as notificações devem ser enviadas do gerador de eventos para os processadores, e não o contrário.
  • Ele responde imediatamente: o processador deve sempre agir imediatamente após receber a notificação, mesmo que a ação não signifique fazer nada.
  • Acomunicação flui apenas em uma direção: as notificações devem seguir o estilo "fogo e esquecimento", pelo qual o gerador enviará a notificação e seguirá seu fluxo normalmente, não esperando o processamento do evento pelo processador. A preocupação com os processadores que recebem a notificação com sucesso torna-se responsabilidade da fila ou do mediador.
  • É livre de comando: uma notificação informa a ocorrência de um evento. Ela não deve dizer o que o processador que receberá o evento deve fazer; cada processador deve saber o que fazer com o evento.

Muito bem, Ana. Você tem estado sempre em cima disso, mas o que devo fazer agora?

Primeiro, você deve compreender suas necessidades; não é porque este assunto foi discutido que você deve mudar toda sua arquitetura para implementá-lo. Então, você analisou as coisas e detectou uma lacuna? Vamos então escolher a melhor arquitetura para isso.

Uma solução síncrona pode resolver seu problema. Nós verificamos e percebemos que o EDA combina perfeitamente com o problema? Vamos escolher o padrão que melhor se adapte ao seu cenário.

Você quer saber os padrões?

Fique ligado em nosso blog, porque em breve (realmente!) teremos um artigo sobre isso.

E finalmente, mãos à obra! É necessário fazer provas de conceito e implementar a solução em si.

E você sabe qual é a melhor coisa? Você não tem que fazer isso sozinho! Entre em contato conosco, temos uma equipe de especialistas prontos para lhe ajudar.

Obrigado pela leitura!