Com a popularização da arquitetura de microserviços, outras opções para desenvolver um sistema complexo com alta disponibilidade ganham mais destaque; uma dessas formas é a arquitetura orientada a eventos.
A arquitetura de microserviços é baseada em baixo acoplamento de serviços, em que cada serviço tem seu próprio processo. Um sistema típico de microserviços possui diversos serviços independentes que se comunicam para realizar ações no sistema. Existem duas formas de comunicação entre microserviços: command e query. Com o Command, um serviço "solicita" que outro serviço realize uma ação, podendo ter uma resposta ou não. Já no Query, um serviço "solicita" a outro serviço algum dado e sempre há uma resposta contendo esse dado. Contudo, essa forma de se comunicar pode criar problemas de desempenho, alto acoplamento e problemas de escalabilidade.
Nesse tipo de cenário, a arquitetura orientada a eventos pode auxiliar no desenvolvimento do sistema. Uma arquitetura orientada por eventos usa eventos para acionamento e comunicação entre serviços desacoplados e é comum em aplicações modernas criadas com microsserviços. Um evento é a indicação de que algo aconteceu no sistema e não há uma resposta para o evento.
A arquitetura orientada a eventos possui três componentes principais: o Producer, que cria o evento; o Channel, responsável por distribuir os eventos para as partes interessadas; e o Consumer, que recebe o evento pelo Channel e processa aquele evento.
Existem diversas vantagens na arquitetura orientada a eventos. Como mencionado anteriormente, existiam alguns problemas na forma tradicional de comunicação na arquitetura de microserviços; já na arquitetura orientada a eventos, esses problemas são minimizados. Por exemplo, os problemas de desempenho são reduzidos porque a arquitetura orientada a eventos é assíncrona, o canal não espera uma resposta do consumidor. No problema de acoplamento entre serviços, isso também é eliminado, pois o produtor envia o evento para o canal, que por sua vez envia os eventos para tópicos ou filas, e nenhum dos dois (Producer e Channel) tem ideia de quem está consumindo aquele evento. Quanto à escalabilidade, pode-se adicionar quantos consumidores forem necessários para processar os eventos do canal.
Comumente, a arquitetura orientada a eventos está ligada ao padrão Pub/Sub, que é um serviço de mensagens assíncrono e escalonável que separa os serviços que produzem mensagens dos serviços que as processam. Esse padrão possui como componentes o Publisher, que atua como o Producer, o Broker que atua como o Channel e o Subscriber que atua como o Consumer. A principal diferença entre eles é que a arquitetura orientada a eventos descreve toda a arquitetura do sistema, enquanto o Pub/Sub é um padrão de envio de mensagens usado pelo sistema.
Geralmente, a arquitetura orientada a eventos trata-se de serviços, mas os eventos podem ser utilizados como armazenamento de dados. O Event Sourcing e o CQRS oferecem um padrão para armazenar dados como eventos. Nos bancos de dados tradicionais, não podemos armazenar todas as alterações que foram feitas naquele dado, já no Event Sourcing podemos capturar todas as alterações feitas naquele dado como eventos; nesse padrão, não há atualizações ou remoções de dados, apenas inserções. No CQRS, temos a separação dos comandos de atualização/inserção/remoção das consultas; assim, temos uma base de dados para inserir/atualizar/remover dados e outra base de dados para consultar os dados. Isso é utilizado para melhorar o desempenho e a simplicidade do sistema. As bases de dados são sincronizadas usando um mecanismo central de sincronização.
Embora apresente diversas vantagens, utilizar a arquitetura orientada a eventos pode ser complexo e não é recomendado para equipes que não possuem maturidade na compreensão de arquitetura de software, pois isso pode causar complexidade desnecessária para o sistema. Outro caso em que a arquitetura orientada a eventos não é recomendada é em casos em que o sistema requer comunicação síncrona entre serviços.
Referências
https://aws.amazon.com/pt/event-driven-architecture/
https://cloud.google.com/pubsub/docs/overview?hl=pt-br#:~:text=O%20Pub%2FSub%20%C3%A9%20um,com%20lat%C3%AAncias%20de%20100%20milissegundos.
Top comments (6)
Pode ter conjestionamento nesta arquitetura, caso ocorra muitas requições ? ou pode inserir algo dinâmico, como um load balancer ?
Geralmente a arquitetura orientada a eventos não sofre com congestionamento, pois ela é altamente escalável. Esse é um dos motivos para usar a arquitetura orientada a eventos no lugar da arquitetura de micro serviços padrão, porque em micro serviços teríamos que adicionar um load balancer para gerenciar um cenário com diversas requisições, na arquitetura orientada a eventos isso não é necessário.
Sobre custos, esse tipo de arquitetura pode minimizar custos por não precisar de máquinas ligadas no tempo todo ?
Sim, um dos benefícios da arquitetura orientada a eventos é a redução de custos, porque o Consumer ou Producer só irá ser utilizado quando algum evento for criado.
De aplicações que AWS possui pode se dizer que Lambda está relacionada a está arquitetura ?
Sim, geralmente o Lambda atua como Consumer ou Producer.