Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
Introdução
Arquitetura Orientada a Eventos ou Event-Driven Architecture (EDA) e Event Sourcing são termos que frequentemente são confundidos, mas têm propósitos distintos. EDA é um padrão de comunicação para desacoplar serviços por meio de eventos. Event Sourcing é uma estratégia de persistência de dados que captura mudanças de estado como eventos imutáveis. Este artigo esclarece suas diferenças e demonstra como eles se complementam.
Arquitetura Orientada a Eventos (EDA)
EDA é um paradigma de arquitetura de software centrado na produção e detecção de eventos, permitindo escalabilidade, tolerância a falhas e baixo acoplamento. Eventos representam mudanças significativas de estado (ex: PedidoPago) e se propagam por canais de eventos (como RabbitMQ ou Kafka).
Problema: Acoplamento Forte em Sistemas Tradicionais
Em um sistema monolítico de compras, um serviço de checkout pode chamar diretamente endpoints RPC para pagamento, logística e notificações. Isso cria acoplamento forte:
EDA resolve esses problemas ao:
Isso transfere as dependências para o message broker, melhorando a resiliência. Mesmo que um consumidor esteja offline, o evento persiste na fila.
Conceitos-chave da EDA
Event Sourcing se concentra em persistir o estado da aplicação armazenando cada mudança como um evento imutável. Diferente da EDA, ele opera no nível da aplicação, não entre serviços.
Princípios Fundamentais
Um sistema de navegação usando Event Sourcing armazena eventos como EventoDeChegada e EventoDePartida. Se a localização de um navio estiver incorreta, desenvolvedores podem reverter o evento errado e reproduzir os subsequentes para corrigir o estado.
Vantagens
Quando Usar Ambos Juntos
EDA e Event Sourcing são complementares:
Exemplo: Um sistema de compras pode usar EDA para publicar eventos PedidoPago e Event Sourcing para armazenar ajustes granulares (ex: reembolsos, descontos).
Conclusão
EDA e Event Sourcing abordam necessidades distintas:
Juntos, formam uma base poderosa para sistemas modernos, habilitando comunicação distribuída e gestão robusta de estado. Sempre combine EDA com padrões como para garantir consistência entre serviços.
Referências
Arquitetura Orientada a Eventos ou Event-Driven Architecture (EDA) e Event Sourcing são termos que frequentemente são confundidos, mas têm propósitos distintos. EDA é um padrão de comunicação para desacoplar serviços por meio de eventos. Event Sourcing é uma estratégia de persistência de dados que captura mudanças de estado como eventos imutáveis. Este artigo esclarece suas diferenças e demonstra como eles se complementam.
Arquitetura Orientada a Eventos (EDA)
EDA é um paradigma de arquitetura de software centrado na produção e detecção de eventos, permitindo escalabilidade, tolerância a falhas e baixo acoplamento. Eventos representam mudanças significativas de estado (ex: PedidoPago) e se propagam por canais de eventos (como RabbitMQ ou Kafka).
Problema: Acoplamento Forte em Sistemas Tradicionais
Em um sistema monolítico de compras, um serviço de checkout pode chamar diretamente endpoints RPC para pagamento, logística e notificações. Isso cria acoplamento forte:
- Ponto Único de Falha: Se o sistema de pagamento (ou qualquer outro) cair, todo o pode fluxo para.
- Escalabilidade Rígida: Adicionar novos serviços (ex: detecção de fraude) exige modificar o serviço de checkout.
EDA resolve esses problemas ao:
- Publicar Eventos: O serviço de checkout publica um evento PedidoPago(ex: Kafka, RabbitMQ).
- Consumidores Independentes: Sistemas de logística, notificação e detecção de fraude consomem o evento de forma assíncrona.
Isso transfere as dependências para o message broker, melhorando a resiliência. Mesmo que um consumidor esteja offline, o evento persiste na fila.
Conceitos-chave da EDA
Tipos de Eventos:
- Eventos de Domínio: Eventos críticos para o negócio dentro de um contexto limitado (ex: PedidoPago).
- Eventos de Integração: Eventos transversais para propagar mudanças entre contextos (ex: EstoqueAtualizado).
Topologias:
- Topologia Broker: Broadcast descentralizado de eventos (alta performance, sem controle central).
- Topologia Mediator: Orchestrator central para fluxos complexos (melhor tratamento de erros, menor escalabilidade).
- Complexidade na Depuração: Fluxos assíncronos e distribuídos dificultam rastrear erros.
- Fragmentação de Ferramentas: diferentes tecnológicas, exigem formatos padronizados, como , para interoperabilidade.
Event Sourcing se concentra em persistir o estado da aplicação armazenando cada mudança como um evento imutável. Diferente da EDA, ele opera no nível da aplicação, não entre serviços.
Princípios Fundamentais
- Registro de Eventos Imutável: Cada mudança de estado é capturada como uma sequência de eventos (ex: ItemAdicionadoAoCarrinho, PagamentoProcessado).
- Histórico Reproduzível: Aplicações podem reconstruir o estado ao reproduzir eventos, habilitando:
- Consultas Temporais: Auditar estados anteriores (ex: "Qual era o status do pedido em 01/01/2023?").
- Ajustes Retroativos: Corrigir erros revertendo eventos incorretos e reproduzindo os corrigidos.
Um sistema de navegação usando Event Sourcing armazena eventos como EventoDeChegada e EventoDePartida. Se a localização de um navio estiver incorreta, desenvolvedores podem reverter o evento errado e reproduzir os subsequentes para corrigir o estado.
Vantagens
- Trilha de Auditoria: Cada mudança é registrada para conformidade ou depuração.
- Consistência de Dados: Evita condições de corrida ao anexar eventos de forma imutável.
- Flexibilidade: Recursos novos podem ser implementados reproduzindo eventos históricos.
- Complexidade: Requer versionamento de eventos e estratégias para ajustes retroativos.
- Sobrecarga de Armazenamento: Registros crescem indefinidamente, exigindo snapshots para reconstrução rápida.
| Aspecto | EDA | Event Sourcing |
|---|---|---|
| Escopo | Comunicação entre serviços | Gestão de estado no nível da aplicação |
| Propósito | Desacoplar sistemas, habilitar escalabilidade | Preservar histórico, suportar auditoria e reprodução |
| Vida Útil do Evento | Transitório (consumido e descartado) | Permanente (armazenado indefinidamente) |
| Casos de Uso | Microsserviços, análise em tempo real e etc | Sistemas financeiros, versionamento de código e etc |
EDA e Event Sourcing são complementares:
- EDA lida com comunicação entre serviços (ex: notificar logística após o pagamento).
- Event Sourcing rastreia mudanças dentro de um serviço (ex: detalhes de confirmação de pagamento).
Exemplo: Um sistema de compras pode usar EDA para publicar eventos PedidoPago e Event Sourcing para armazenar ajustes granulares (ex: reembolsos, descontos).
Conclusão
EDA e Event Sourcing abordam necessidades distintas:
- EDA desacopla serviços, aumentando escalabilidade e resiliência.
- Event Sourcing garante auditoria e consistência de estado via registros imutáveis.
Juntos, formam uma base poderosa para sistemas modernos, habilitando comunicação distribuída e gestão robusta de estado. Sempre combine EDA com padrões como para garantir consistência entre serviços.
Referências