O que é arquitetura orientada a eventos (EDA)?
A arquitetura orientada a eventos (EDA) é um padrão de arquitetura moderno criado com base em serviços pequenos e sem acoplamento que publicam, consomem ou encaminham eventos.
Um evento representa uma mudança de estado ou uma atualização. Por exemplo: um item colocado em um carrinho de compras, um arquivo carregado em um sistema de armazenamento ou um pedido que está pronto para ser enviado. Os eventos podem conter o estado (como o nome do item, o preço ou a quantidade em um pedido) ou simplesmente identificadores (por exemplo, “o pedido de n.º 8942 foi enviado”) necessários para pesquisa de informações relacionadas.
Ao contrário dos modelos tradicionais orientados a solicitações, a EDA promove um acoplamento fraco entre os serviços produtores e consumidores. Isso facilita a escalabilidade, a atualização e a implantação independente de componentes separados de um sistema.
Por que uma arquitetura sem acoplamento é importante?
Muitas organizações acreditam que aplicações, bancos de dados e tecnologias monolíticas impactam negativamente a inovação e a melhoria da experiência do usuário. Aplicações e bancos de dados herdados reduzem suas opções de adoção de estruturas com tecnologia modernas e restringem sua competitividade e inovação. No entanto, quando você moderniza aplicações e armazenamentos de dados, a escalabilidade e o desenvolvimento deles são facilitados.
Uma estratégia de dados sem acoplamento melhora a tolerância a falhas e a durabilidade, o que ajuda a acelerar o tempo de lançamento no mercado (TTM) para seus novos recursos de aplicações.
Para obter mais informações sobre as vantagens da modernização de aplicações monolíticas, consulte Enabling data persistence in microservices (Como habilitar a permanência de dados em microsserviços) nas Recomendações da AWS.
Quais são os benefícios da arquitetura orientada a eventos (EDA)?
A arquitetura orientada a eventos (EDA) promove um acoplamento fraco entre os componentes de um sistema, ocasionando uma maior agilidade. Os microsserviços podem ser dimensionados de forma independente, falhar sem afetar outros serviços e reduzir a complexidade dos fluxos de trabalho. Os eventos podem ser roteados, armazenados em buffers e registrados de maneira flexível para fins de auditoria. Os fluxos de eventos baseados em push podem operar em tempo real. Isso reduz os custos associados à criação e à operação de códigos para sondagens contínuas dos sistemas em busca de alterações.
Escalabilidade e falhas independentes
Ao desacoplar serviços, os componentes em uma arquitetura orientada a eventos podem ter escalabilidade e sofrerem falhas de maneira independente, aumentando a durabilidade de uma aplicação. Isso se torna cada vez mais importante à medida que o número de integrações entre os serviços cresce. Se ocorrer falhas em um serviço, o restante poderá continuar funcionando.
A arquitetura orientada a eventos também pode facilitar a criação de sistemas quase em tempo real, ajudando as organizações a abandonar o processamento baseado em lotes. Os eventos são gerados quando o estado de uma aplicação é alterado. À medida que os eventos tem sua escala vertical aumentada, o mesmo acontece com a camada que os processa.
Os eventos geralmente são publicados em serviços de mensagens, os quais se comportam como um buffer elástico entre microsserviços e ajudam a tratar da escalabilidade. Os eventos também podem ser enviados para um serviço de roteador que pode filtrar e encaminhar mensagens com base no conteúdo do evento. Como resultado, as aplicações baseados em eventos podem ser mais escaláveis e oferecer maior redundância quando comparadas às aplicações monolíticas.
Desenvolvimento com agilidade
Com a arquitetura orientada a eventos e roteadores de eventos, os desenvolvedores não precisam mais programar códigos personalizados para pesquisa, filtro e encaminhamento de eventos. Um roteador de eventos filtra e envia eventos de forma automática para os consumidores. O roteador também elimina a necessidade de coordenação intensa entre os serviços produtores e consumidores, aumentando a agilidade do desenvolvedor.
A arquitetura orientada a eventos é baseada em push, o que significa que tudo acontece sob demanda à medida que os eventos são enviados ao roteador e aos sistemas downstream, sem a necessidade de comunicação aos serviços dependentes. Por causa disso, a infraestrutura e os recursos podem ter aumento ou diminuição da escala vertical com base no volume de eventos, o que reduz os custos para processamento de workloads e operação de aplicações implementadas.
Desenvolvimento de sistemas elásticos
A arquitetura orientada a eventos também é altamente elástica. Outras equipes podem expandir recursos e adicionar funcionalidades sem que os microsserviços existentes sejam afetados. Ao publicar eventos, uma aplicação pode se integrar aos sistemas existentes, com as aplicações futuras podendo se integrar facilmente como consumidores de eventos, sem que a solução existente sofra alterações.
Os produtores de eventos não têm conhecimento dos consumidores de eventos, portanto, expandir o sistema causa menos conflitos e novos recursos ou integrações não adicionam dependências que retardam o desenvolvimento futuro.
Redução da complexidade
Os microsserviços permitem que desenvolvedores e arquitetos decomponham fluxos de trabalho complexos. Por exemplo, eles podem dividir uma aplicação monolítica de comércio eletrônico em processos de aceitação de pedidos e pagamentos com serviços separados para estoque, logística e contabilidade.
Uma workload que pode ser complexa de gerenciar e orquestrar em uma aplicação monolítica se torna uma série de serviços simples e sem acoplamentos os quais são gerenciados independentemente e se comunicam de forma assíncrona por meio de mensagens de eventos.
Uma abordagem orientada a eventos torna possível montar e orquestrar serviços que processam dados em taxas diferentes. No exemplo a seguir, um microsserviço de aceitação de pedidos interage com um sistema de processamento de pagamento por meio de uma fila.
No exemplo, o serviço de aceitação de pedidos pode armazenar grandes volumes de pedidos recebidos em uma fila com armazenamento em buffer das mensagens.
O serviço de processamento de pagamentos, que normalmente é mais demorado devido à complexidade do tratamento de pagamentos, pode receber um fluxo constante de mensagens da fila. O serviço de pagamento transita entre vários estados do sistema devido à repetição e à lógica de tratamento de erros. O serviço de fluxo de trabalho orquestra e gerencia as etapas de pagamento com base no estado do sistema e, eventualmente, produz mais eventos de interesse para os serviços de estoque, logística e contabilidade.
Auditoria com facilidade
Um roteador de eventos atua como um local centralizado para auditar sua aplicação e definir políticas em uma arquitetura orientada a eventos. Essas políticas podem restringir quem é capaz de publicar e assinar um roteador e controlam quais usuários e recursos têm permissão para acessar seus dados. Você também pode criptografar seus eventos em trânsito e em repouso.
Redução dos custos
As EDAs são baseadas em push e, portanto, tudo acontece sob demanda à medida que o evento se apresenta no roteador. Dessa forma, você não paga por pesquisas contínuas para verificação da presença de um evento. Isso significa menor consumo de largura de banda da rede, menor utilização de CPU, menos capacidade ociosa da frota e menos handshakes SSL/TLS.
Como funciona uma arquitetura orientada a eventos (EDA)?
Veja a seguir um exemplo de arquitetura orientada a eventos (EDA) para um site de comércio eletrônico:
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
O site do exemplo mostra três componentes principais dos produtores de eventos e os eventos que eles produzem. Nesse cenário, um roteador de eventos ingere e filtra os eventos e, em seguida, envia um ou mais eventos para os consumidores de eventos.
A arquitetura orientada a eventos permite que o site reaja a alterações de uma variedade de fontes durante os períodos de pico de demanda, sem que ocorra travamento da aplicação ou provisionamento de recursos em excesso.
Quais tipos de workloads são adequados para a arquitetura orientada a eventos (EDA)?
As arquiteturas orientadas a eventos (EDAs) podem fornecer uma maneira eficaz de atender às demandas de workloads altamente escaláveis e disponíveis. A EDA também se aplica bem a workloads com padrões de tráfego variados ou “por picos”.
Como a arquitetura orientada a eventos (EDA) melhora as aplicações?
A arquitetura orientada a eventos (EDA) promove um acoplamento fraco entre os componentes, o que a torna uma boa abordagem para criação de aplicações modernas e distribuídas.
Os produtores de eventos desconhecem ou não se preocupam com quaisquer atividades dos consumidores subsequentes dos eventos que produzem. Os próprios eventos representam uma mudança de estado e podem ou não conter dados. Os eventos desconhecem as consequências de sua existência. Os consumidores prestam atenção e processam eventos de interesse. Você pode buscar novos consumidores on-line para fornecer novas funcionalidades sem que haja interrupção dos fluxos de trabalho existentes.
As EDAs promovem a decomposição de sistemas monolíticos em modelos de domínio menores. Os desenvolvedores podem se atualizar com menos carregamentos cognitivos e se tornar produtivos mais rapidamente. Quando as funções essenciais não tem acoplamento, também há menos risco da implantação de atualizações e novos recursos.
Quais são alguns casos de uso comuns da arquitetura orientada a eventos (EDA)?
Comunicação de microsserviços para back-ends móveis e Web
Geralmente, sites de varejo ou de mídia e entretenimento precisam aumentar a escala verticalmente para lidar com tráfego variável. Os clientes visitam um site de comércio eletrônico e realizam um pedido. O evento de pedido é enviado a um roteador de eventos. Todos os microsserviços subsequentes podem coletar o evento de pedido para processá-lo. Algumas ações podem incluir: envio do pedido, autorização do pagamento e transmissão dos detalhes do pedido para uma transportadora.
Como cada um dos microsserviços pode ter escalabilidade e apresentar falhas de maneira independente, o processo pode aumentar a escala verticalmente durante os períodos de pico de pedidos sem apresentar pontos únicos de falha.
Automação do fluxo de trabalho empresarial
Muitos fluxos de trabalho empresariais, como transações de serviços financeiros, requerem a repetição das mesmas etapas. Você pode instaurar e automatizar essas etapas com a arquitetura orientada a eventos (EDA).
Por exemplo, quando um cliente solicita abertura de uma nova conta em um banco, o banco deve executar algumas verificações de dados (como: identificação, endereço etc.). Algumas contas também exigirão um estágio de aprovação humana. Você pode orquestrar todas essas etapas por meio de um serviço de fluxo de trabalho que executa as etapas automaticamente quando solicitações de aberturas de contas são recebidas.
Também é possível adicionar um fluxo de trabalho para processar dados da solicitação do cliente de forma assíncrona utilizando machine learning para extração de dados relevantes, o que economizará horas de coleta e validação manual de dados.
Integração de aplicações SaaS
Um dos principais desafios para ambientes de software como serviço (SaaS) é a falta de visibilidade da atividade e dos dados do usuário. Para liberar dados em silos, as arquiteturas orientadas a eventos podem ingerir eventos de aplicações SaaS ou enviar eventos para suas aplicações SaaS. Por exemplo, você pode criar um middleware para ingerir dados de pedidos de parceiros que são recebidos e enviar os pedidos diretamente para uma aplicação interna de processamento de pedidos.
Automação de infraestrutura
Ao executar workloads com uso intensivo de computação (como análises financeiras, pesquisas genômicas ou transcodificações de mídia), você pode precisar atender aos recursos de computação aumentando o processamento em paralelo e, então, reduzindo-o após a conclusão do trabalho.
Por exemplo, em setores altamente regulamentados, as empresas com EDA podem ativar recursos de postura de segurança em resposta a um incidente ou tomar medidas de correção sempre que uma política de segurança enviar um evento de alerta.
Quando as arquiteturas orientadas a eventos (EDAs) devem ser usadas?
As arquiteturas orientadas a eventos (EDAs) são ideais para aumentar a agilidade e a mobilidade. Geralmente, elas se encontram em aplicações modernas que usam microsserviços ou em qualquer aplicação que tenha componentes sem acoplamento.
Integração de sistemas heterogêneos
Se você tem sistemas em execução em pilhas diferentes, pode usar uma EDA para compartilhar informações entre eles sem acoplamento. O roteador de eventos estabelece caminhos indiretos e interoperabilidade entre os sistemas, para que eles possam trocar mensagens e dados ao mesmo tempo que permanecem independentes.
Replicação de dados entre regiões e contas
Você pode usar uma EDA para coordenar sistemas entre equipes que operam e implantam em diferentes contas e regiões da AWS. Ao usar um roteador de eventos para transferir dados entre sistemas, você pode desenvolver, escalar e implantar serviços independentemente de outras equipes.
Monitoramento e geração de alertas de estados de recursos
Em vez de conferir continuamente seus recursos, você pode usar uma EDA para monitorar e receber alertas sobre anomalias, alterações e atualizações. Esses recursos podem incluir buckets de armazenamento, tabelas de banco de dados, funções com tecnologia sem servidor, nós de computação e muito mais.
Distribuição e processamento paralelo
Se você tem muitos sistemas que devem operar em resposta a um evento, pode usar uma EDA para distribuir o evento sem precisar programar um código personalizado para envio por push a cada consumidor. O roteador envia o evento por push para os sistemas e cada um pode processar esse evento em paralelo com uma finalidade diferente.
Quais são os padrões comuns da arquitetura orientada a eventos (EDA)?
Diversas funções rápidas
Crie diversas funções rápidas e poucas funções demoradas. Tornar as funções para suas workloads altamente especializadas significa que elas são concisas e, geralmente, reduzem o tempo de processamento. Cada função deve tratar o evento que foi passado para ela, sem conhecimento ou expectativas do fluxo de trabalho geral ou do volume de transações. Isso torna a função independente da origem do evento com acoplamento mínimo a outros serviços.
Processamento sob demanda em vez de lotes
Muitos sistemas tradicionais são projetados para serem executados periodicamente e realizar o processamento das transações em lotes que se acumulam ao longo do tempo. Por exemplo, uma aplicação bancária pode ser executada de hora em hora para processamento de transações de caixa eletrônico para registro em livros contábeis centrais.
Na arquitetura orientada a eventos (EDA), o processamento personalizado pode responder a todos os eventos. Isso permite que o serviço aumente a escala verticalmente da simultaneidade, conforme necessário, para o processamento de transações quase em tempo real.
Recuperação de interrupções
No caso de uma interrupção, um serviço pode ser chamado de forma automática para tentar processar um evento novamente. Como o serviço pode receber o mesmo evento mais de uma vez, as funções projetadas devem ser idempotentes. Isso garante que o resultado não seja alterado após a primeira vez que o serviço recebe um evento.
Por exemplo, se um varejista tentar processar um cartão de crédito duas vezes devido a uma nova tentativa, o serviço processará o pagamento apenas na primeira tentativa. Na nova tentativa, o serviço verificará o status do pagamento e descartará o evento.
Quais são alguns desafios da arquitetura orientada a eventos (EDA)?
Ao adotar uma arquitetura orientada a eventos (EDA), talvez seja necessário repensar como sua aplicação é projetada.
Latência variável
Ao contrário das aplicações monolíticas, que podem processar tudo em um mesmo espaço de memória e único dispositivo, as aplicações orientadas a eventos se comunicam entre redes. Esse projeto introduz uma latência variável. Embora as aplicações monolíticas possam ter uma latência menor ou menos variável, isso geralmente ocorre com prejuízos para a escalabilidade e disponibilidade.
Os produtos com tecnologia sem servidor da AWS são altamente disponíveis, o que significa que operam em mais de uma zona de disponibilidade em uma região da AWS. No caso da interrupção de um produto, os outros fazem failover automaticamente para zonas de disponibilidade alternativas e repetem as transações. Como resultado, em vez de as transações falharem, elas podem ser concluídas com êxito, mas com maior latência.
As workloads que requerem performances consistentes de baixa latência não são boas candidatas para a EDA. Dois exemplos são as aplicações de negociação de alta frequência em bancos ou a automação robótica inferior a um milissegundo em armazéns.
Consistência eventual
Um evento representa uma mudança de estado. Com muitos eventos ocorrendo por meio de diferentes serviços em uma arquitetura em um determinado momento, essas workloads geralmente tem consistência eventual. Isso torna mais complexo processar transações, lidar com duplicações ou determinar o estado geral exato de um sistema.
Algumas workloads não são adequadas para a EDA devido à necessidade de propriedades ACID. No entanto, muitas workloads contêm uma combinação de requisitos que são eventualmente consistentes (por exemplo, o total de pedidos no horário atual) ou altamente consistentes (por exemplo, o estoque atual). Para os recursos que necessitam de alta consistência de dados, existem padrões de arquitetura para oferecer suporte a isso. Por exemplo:
- O DynamoDB pode fornecer leituras altamente consistentes, às vezes com uma latência mais alta, e também pode oferecer suporte a transações para ajudar a manter a consistência de dados.
- Você pode usar bancos de dados relacionais para recursos que exigem propriedades ACID, embora qualquer banco de dados relacional seja menos escalável do que um armazenamento de dados NoSQL.
Retorno de valores para os chamadores
Em muitos casos, as aplicações baseadas em eventos são assíncronas. Isso significa que os serviços do chamador não aguardam solicitações de outros serviços antes de continuar com outro trabalho. Essa característica fundamental das EDAs permite escalabilidade e flexibilidade. No entanto, torna a transmissão de valores de retorno ou resultados de fluxos de trabalhos mais complexa do que em fluxos síncronos.
Em muitos casos, retornar um valor é menos importante do que garantir êxito ou fracasso no processamento de um evento. Os recursos que garantem o processamento de eventos podem ser mais importantes do que retornar valores para um chamador.
Geralmente, em workloads interativas, como aplicações móveis e Web, o usuário final espera receber um valor de retorno ou o estado atual de uma transação. Para essas workloads, existem diversos padrões de projetos que podem retornar eventos interativos ao chamador. Entretanto, essas implementações em uma arquitetura orientada a eventos são mais complexas do que usar um valor de retorno assíncrono tradicional. A plataforma muitas vezes pode mitigar essa complexidade.
Depuração entre serviços e funções
A depuração em sistemas orientados a eventos é diferente da depuração de uma aplicação monolítica. Como acontece com todas as aplicações baseadas em microsserviços e diferentes sistemas e serviços que transferem eventos, pode ser um desafio registrar e reproduzir o estado exato de diversos serviços quando ocorre um erro. Como cada chamada de serviço e de função tem arquivos de log separados, pode ser mais complicado determinar o que aconteceu com um evento específico que causou um erro.
Orquestração
É comum que fluxos de trabalho simples se tornem mais complexos ao longo do tempo. Em uma aplicação monolítica tradicional, isso pode resultar em grupos de funções e serviços acoplados mais fortemente, além de roteamento e exceções de tratamento de códigos complexos.
Para acompanhar o estado do sistema, os fluxos de trabalho que envolvem lógica de ramificação, os diferentes tipos de modelos de falha e a lógica de repetição, normalmente, um orquestrador é utilizado. Ao criar uma aplicação com tecnologia sem servidor e orientada a eventos, é importante identificar quando isso está acontecendo a fim de realizar a migração dessa lógica para uma máquina de estado para orquestração adequada.
Quais produtos da AWS usam uma arquitetura orientada a eventos (EDA)?
Os produtos da AWS geralmente produzem ou consomem eventos, facilitando a criação de soluções com uma arquitetura orientada a eventos (EDA).
Além disso, serviços como o Amazon EventBridge, o Amazon SNS, o Amazon SQS e o AWS Step Functions incluem recursos que ajudam os clientes a programarem menos códigos clichês e criarem EDAs mais rapidamente.
Amazon EventBridge
Você pode usar o Amazon EventBridge para criar barramentos de eventos para aplicações orientadas a eventos em escala ao utilizar eventos de aplicações SaaS, outros produtos da AWS ou aplicações personalizadas.
O EventBridge aplica regras para encaminhamento de eventos de fontes de eventos para destinos diferentes. Os destinos podem incluir produtos da AWS, como o AWS Lambda, o Step Functions e o Amazon Kinesis, bem como qualquer endpoint HTTP por meio de destinos de API do EventBridge.
Uma integração popular para casos de uso de EDA é o Step Functions, no qual os eventos acionam fluxos de trabalho específicos.
AWS Step Functions
O AWS Step Functions inclui o Workflow Studio, um designer de fluxo de trabalho visual de baixo código que os desenvolvedores usam para orquestrar diferentes produtos da AWS. Você pode usar o Workflow Studio para criar aplicações distribuídas, automatizar processos de TI e de negócios, e criar pipelines de dados e machine learning usando produtos da AWS.
Amazon SNS
O Amazon Simple Notification Service (Amazon SNS) é recomendado para criação de aplicações que reagem a eventos de throughput alta e baixa latência publicados por outras aplicações, microsserviços ou produtos da AWS. Você também pode usar o Amazon SNS para aplicações que precisam de distribuições muito elevadas para milhares ou até milhões de endpoints.
Amazon SQS
O Amazon Simple Queue Service (Amazon SQS) oferece um serviço seguro, durável e disponível de filas hospedadas o qual você pode usar para integrar e desacoplar sistemas e componentes de softwares distribuídos. O Amazon SQS oferece estruturas comuns, como fila de mensagens não entregues e tags de alocação de custos.
Próximas etapas da arquitetura orientada a eventos da AWS
Obtenha acesso instantâneo ao nível gratuito da AWS.
