Paula Santana Rosa
Feb 24 · 9 min read

Desenvolvimento de sistemas e Arquitetura baseada em Eventos

Segura a emoção: em Arquitetura de Soluções não tem “bala de prata”! Ei, devs, venham comigo que eu vou explicar…

Antes de tudo: marquei os termos importantes para facilitar a compreensão de vocês! Em caso de qualquer dúvida ou sugestão… por favor, falem comigo! Peguem seus copos de água, seu lanchinho… e vamos em frente porque o assunto é denso.

Quando um desenvolvedor começa sua carreira, provavelmente conhece primeiro os Sistemas Monolíticos. E tudo bem, porque eles foram a maioria até uns anos atrás! Com o tempo, entendemos que, para alguns casos, este modelo arquitetural não atendia. Vamos entender um pouco do conceito de Arquitetura de Software e como saímos de um modelo para tantos que existem hoje em dia.

Afinal, o que é Arquitetura de Software?

Quando falamos em Arquitetura de Software, nos referimos basicamente aos seguintes pontos:

Ou seja, estamos olhando para todo o ecossistema em torno de uma ou várias aplicações que resolvem um problema, provendo um serviço de negócio.

Com a evolução da tecnologia e das necessidades dos negócios, a Arquitetura Monolítica de Software acabava não sendo a melhor escolha para suprir a demanda e gerava alguns problemas. Uma das alternativas criadas foi a Arquitetura de Microsserviços, que é uma arquitetura compostas por um conjunto de sistemas menores, sendo cada um com seu domínio de negócio.
E nos últimos anos esse modelo foi ganhando cada vez mais espaço e trazendo vários benefícios, como:

Entre muitos outros que, provavelmente, a maioria já ouviu falar. E, se você não ouviu, sugiro que leia microservices.io.
Beleza, então temos muitos serviços independentes, que maravilha… Exceto quando o número deles aumenta, porque aí a rede de interações síncronas entre eles pode ser uma baita dor de cabeça. Já imaginou ter problemas de disponibilidade, que começa a desencadear interrupções mais generalizadas e afeta o tempo de resposta, assim como os processos de uma ação?!

Só para ficar mais claro…

Arquitetura de Eventos

Em computação, um evento é toda ação que gera mudança de estado como, por exemplo, uma atualização de e-mail no seu cadastro, o clique do mouse e um log que foi gerado. Assim, toda as ações do sistema podem ser eventos.
Considerem 3 partes importantes deste modelo arquitetural:

A arquitetura de eventos é uma maneira de realizarmos comunicação entre sistemas que consiste, principalmente, em operações assíncronas, além de permitir aplicativos mais escalonáveis e gerar menos acoplamento entre os serviços, permitindo uma arquitetura fortemente flexível. É um modelo que independe de tamanho da sua arquitetura! Ele pode ser adaptado para sistemas de qualquer tamanho.

Tendência ou Realidade?

Segundo Gartner(Link), uma das referências sobre Arquitetura de Software, Arquitetura de Eventos era um dos assuntos Top 10 para se investir em 2018.

O Relatório de Tendências de 2019 da InfoQ (link) já assinalou o tema entre os que serão mais adotados por quem tem perfil “early majority”.

Fonte: www.infoq.com

Além disso, sabemos que empresas gigantes aplicam este modelo arquitetural em seus produtos. Alguns exemplos são Nubank, Netflix, Twitter, Linkedin, Ifood, Spotify, Airbnb e Uber.
E o que estas empresas têm em comum? Para começar, todas lidam com sistemas que recebem milhares de requisições, são referência de mercado e lidam com grande volume de dados. Podemos entender, com tudo isso, que a Arquitetura de Eventos já é uma realidade no mercado - especialmente quando se trata de tecnologia de ponta.

Mas não é tão novo assim...

Apesar de parecer uma solução inovadora, este tipo de comunicação já era utilizado entre sistemas Unix. Se você desenvolve, já aplicou alguns recursos que utilizam este tipo de comunicação “por debaixo dos panos”. É o caso dos delegates do Java.
Vamos entender um pouco mais o que envolve este padrão de arquitetura de software. Para isso, vamos às suas topologias principais.

Topologias

Mediador

Usada principalmente quando há necessidade de orquestração ou manipulação de etapas no processamento do evento. Tendo como tipos de componentes a fila, mediador, canais e processador (todos de eventos).
Exemplos de implementações : Apache Camel, Spring Integration ou Mule ESB.

Broker

Usada quando se tem um fluxo de eventos simples, onde não há necessidade de orquestração dos eventos. Este componente pode ser centralizado ou federado e contém os canais de eventos usados no fluxo, sendo os canais modelo de filas, tópicos de mensagens ou a combinação deles.
Exemplos de implementações:Apache ActiveMQ, Apache Kafka.

Existem outros padrões?

Provavelmente você vai ouvir falar de alguns padrões relacionados a este tipo de arquitetura como Event-sourcing (terceirização de eventos), Event Notification (notificação de eventos), Event-Carried State Transfer (transferência de estado transportado pelo evento) e é importante entender a diferença deles para saber quando e como usar.

Escolher o modelito certo é muito importante para não dar ruim né amores? O mesmo se aplica neste tipo de arquitetura.

Notificação de Evento: nele, o produtor do evento gera um evento e o envia para um broker de eventos, por exemplo, informando que houve uma alteração de endereço. Os interessados neste evento (no caso os consumidores) serão notificados. Neste modelo, os dados relacionados ao evento não estão nele! Diferente do caso da alteração do endereço, o consumidor queria saber qual é o novo bairro e a rua. Para isso, ele deverá realizar uma consulta no sistema que produziu o evento! O lado bom deste modelo é que já começamos a ter desacoplamento das aplicações, porém é necessário analisar o quanto chamadas adicionais ao produtor do evento possa onerá-lo

Transferência de estado transportado pelo evento: o evento leva os dados relacionados à ele. Neste caso, o consumidor não precisa consultar o produtor para obter mais informações. Com isso, o consumidor não depende de dados de outra aplicação e disponibilidade para fazer o que precisa ser feito, garantindo assim resiliência e disponibilidade no processo executado pelo consumidor, porém teremos de analisar o fato de que o consumidor deverá realizar gestão dos dados do evento, além de que estes dados são de outro domínio e de que isso gera um complexidade do lado do consumidor.

Fonte de eventos (Event Sourcing): modelo muito utilizado para armazenamento de eventos , criando um histórico de eventos. Na prática, isso nos permite realizar auditoria dos dados e retroceder determinado ponto de estado. Como quando existe alguma inconsistência, por exemplo, e é necessário validar o que foi realizado. Com um histórico, também podemos analisar comportamentos e gerar análises de negócio sobre as informações geradas. Este modelo é muito usado com o padrão CQRS (Command Query Responsibility Segregation), que separa escrita de leitura. Nesta mescla dos padrões vocês vão encontrar o event sourcing sendo a fonte de escrita, que muitas vezes possui um Handler, que faz a gestão e distribuição destes dados para bases de consulta. A abordagem de event sourcing hoje é amplamente aplicada e vai desde cases de Internet da Coisas a Data Science. Em alguns casos, entende-se que este modelo pode gerar complexidade, o que outros discordam. Fato é que o modelo dos dados é primordial, por isso, o schema será um problema — no sentido de como encontrar o modelo adequado para sua situação. Neste caso, como em muitas coisas na tecnologia, não temos algo fixo. A escolha e o que será enviado em termos de dado dependerá de cada caso.

Como funcionam os Modelos de Entrega?

Fila (Ponto a Ponto)

Neste modelo, consideramos que um produtor vai falar apenas com um consumidor em termos de negócio. Exemplo: compraram um produto e foi gerado um evento relacionado à compra do produto. Neste modelo de entrega, não poderíamos ter uma aplicação de transporte e outra de nota fiscal consumindo o mesmo evento. Ao invés disso, poderíamos falar apenas com uma aplicação, mesmo que esta esteja com vários consumidores ativos. E eles podem ser mais de um consumidor por máquina na aplicação ou várias máquinas da mesma aplicação, sempre com consumidores funcionando. Neste caso, ambos estão trabalhando para o mesmo negócio. Neste modelo apenas um cliente recebe o evento!

Tópico ( Publish / Subscriber)

Você já se inscreveu para receber notícias ou publicações de um site? Então! Neste modelo de entrega é bem semelhante: temos um produtor enviando eventos para um broker e este, por sua vez, entregando o evento para todos os interessados! Lembra do exemplo do pedido de compra? Neste, poderíamos ter tanto a aplicação de nota fiscal, quanto de transporte consumindo e reagindo ao evento de compra do produto.

Próximos passos

Se você é um desenvolvedor e nunca trabalhou com esse tipo de arquitetura, comece a pesquisar quais brokers/middleware de mensagens existem, quais são mais utilizados no mercado e quais deles são em Cloud e como cada um se comporta. Entender estes pontos pode ser um passo crucial para implementar este tipo de arquitetura.

Alguns nomes conhecidos no mercado são:

Implementando a coisa toda!

Outro ponto para ficar atento é como será feita a implementação e, quando falo de implementação, é de fato no como relacionado a código e configurações do broker/middleware escolhido, linguagem utilizada e como ela implementa consumo e produção de eventos/mensagens.

Em Java, por exemplo, temos uma especificação para trabalhar com mensageria chamado JMS. Além disso, podemos utilizar para aplicações em Spring Boot o Spring AMQP, que trabalha com esse protocolo de mensagens - além de outros que também podem ser utilizados.

Eu li e recomendo muito dois livros relacionados a arquitetura de eventos, sendo que um deles trás enfoque em um broker e explica bem sobre implementação que é Designing Event-Driven Systems, do Ben Stopford e o outro que é Software Architetcture Patterns, do Mark Richards.

Prós e Contras: entender ajuda a tomar decisões

Podemos elencar como benefícios da arquitetura orientada a eventos:

E como pontos negativos, a se pensar é que dependendo da situação:

Resumindo o rolê...

O que pretendo com esse conteúdo é dar um panorama geral dessa abordagem, mostrando que como desenvolvedor você deve entender as diferenças entre os modelos. Claro, sempre entendendo o que faz sentido ou não para uma situação.
Não é raro encontrar pessoas falando que KAFKA é a “salvação da lavoura” para todo e qualquer problema. Veja bem, não é que não seja uma boa escolha, mas é essencial informar que existem muitas possibilidades para resolver o mesmo problema. E, vai por mim, entender o padrão desta arquitetura auxilia MUITO para o corpo técnico envolvido. Sério!

****Este conteúdo foi baseado na minha palestra apresentada na Campus Party, caso queira visualizar todos os slides clique aqui.

Devs JavaGirl

Um grupo de mulheres que se interessam por Java, sejam desenvolvedoras seniores, plenas ou juniores, ou ainda estudando. Por que não? Contamos aqui tudo o que sabemos e o que estamos aprendendo.

Paula Santana Rosa

Written by

Devs JavaGirl

Um grupo de mulheres que se interessam por Java, sejam desenvolvedoras seniores, plenas ou juniores, ou ainda estudando. Por que não? Contamos aqui tudo o que sabemos e o que estamos aprendendo.