BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Arquitetura de eventos e streaming de eventos

Arquitetura de eventos e streaming de eventos

Favoritos

Ao mudar de um sistema monolítico para um sistema distribuído ou microservices, normalmente também mudamos de uma única fonte da verdade em um único banco de dados para muitos bancos de dados e muitas fontes da verdade. Usando uma arquitetura de eventos e persistindo todos os eventos como um fluxo pode trazer novamente uma única fonte da verdade, Ben Stopford afirma em uma série de blog posts sobre eventos, fluxo de eventos e Kafka.

Stopford, engenheiro na Confluent, ressalta que em sistemas de mensagens tradicionais, eventos são efêmeros, não há histórico de eventos já consumidos. Persistir todos os eventos irá, além de criar uma única fonte de verdade, também dar a possibilidade de rebobinar e reproduzir eventos, como um sistema de controle de versão, mas para dados. Isto também tornaria possível recuperar sistemas corrompidos e reproduzir eventos depois que um erro for corrigido.

Um típico sistema baseado em escuta de eventos, atualiza e mantém o seu estado em um banco de dados e emite novos eventos. Para Stopford, isto significa dois desafios: primeiro, manter a consistência enquanto escreve no banco de dados e em um log de eventos; segundo, o dados no banco de dados e os eventos podem começar a divergir códigos diferentes, por exemplo, e isso pode causar problemas de inconsistências no sistema. O melhor jeito de resolver esse problema é fazer dos eventos entidades de primeira classe e somente utilizar os eventos, como um sistema de fonte de eventos.

Uma maneira de começar a usar um fluxo de eventos é usar o padrão Captura de Dados de Alterações, essa técnica está disponível em um grande número de banco de dados. Usando este padrão, você escreve no banco de dados e depois é convertido em um fluxo de eventos em segundo plano. Uma das vantagens que Stopford menciona é que isso oferece um ponto de consistência: você lê e escreve no banco de dados, mas continua tendo um fluxo de eventos sem a necessidade de transações distribuídas para manter o banco de dados e o fluxo em sincronia.

Um dos mais importantes casos de uso para Captura de Dados de Alterações para Stopford é migrar para uma arquitetura mais moderna. Conectando os sistemas legados de banco de dados usando Captura de Dados de Alterações, conseguimos extrair um fluxo de eventos e gradualmente nos afastar de usar o sistema legado para utilizar um sistema de fluxo de eventos.

Um padrão muito útil quando usamos uma fonte de eventos e um fluxo de eventos é manter os eventos de duas maneiras: primeiro um ponto baseado nas mudanças que aconteceram em ordem cronológica, usado para uma visão da origem do evento, e segundo em um tópico compactado que provê somente a última visão de uma entidade, e portanto, será menor e mais rápida.

Stopford conclui observando que a principal funcionalidade de uma arquitetura baseada em fluxo de eventos é a habilidade de evoluir. A medida que novos requerimentos surgem, novos serviços podem ser construídos e facilmente implantados, e atualizando reproduzindo todos os eventos desde o começo. Ele acredita que o Kafka provê funcionalidades que se encaixam bem neste tipo de arquitetura.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT