Padrão de fornecimento de eventos - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Padrão de fornecimento de eventos

O padrão de fornecimento de eventos é normalmente usado com o Padrão CQRS para separar as cargas de trabalho de leitura das de gravação e otimizar o desempenho, a escalabilidade e a segurança. Os dados são armazenados como uma série de eventos, em vez de atualizações diretas nos armazenamentos de dados. Os microsserviços reproduzem eventos de um armazenamento de eventos para calcular o estado apropriado de seus próprios armazenamentos de dados. O padrão fornece visibilidade ao estado atual do aplicativo e contexto adicional de como o aplicativo chegou a esse estado. O padrão de fornecimento de eventos funciona de forma eficaz com o padrão CQRS porque os dados podem ser reproduzidos para um evento específico, mesmo que os armazenamentos de dados de comando e consulta tenham esquemas diferentes.

Ao escolher esse padrão, você pode identificar e reconstruir o estado do aplicativo em qualquer momento. Isso produz uma trilha de auditoria persistente e facilita a depuração. No entanto, os dados acabam se tornando consistentes e isso pode não ser apropriado para alguns casos de uso.

Esse padrão pode ser implementado usando o Amazon Kinesis Data Streams EventBridge ou o Amazon.

Implementação do Amazon Kinesis Data Streams

Na ilustração a seguir, o Kinesis Data Streams é o principal componente de um armazenamento de eventos centralizado. O armazenamento de eventos captura alterações da aplicação como eventos e as persiste no Amazon Simple Storage Service (Amazon S3).

Implementação do Amazon Kinesis Data Streams

O fluxo de trabalho consiste nas seguintes etapas:

  1. Quando os microsserviços “/withdraw” ou “/credit” sofrem uma mudança no estado do evento, eles publicam um evento gravando uma mensagem no Kinesis Data Streams.

  2. Outros microsserviços, como “/balance” ou “/creditLimit”, leem uma cópia da mensagem, filtram por relevância e a encaminham para processamento adicional.

EventBridge Implementação da Amazon

A arquitetura na ilustração a seguir usa EventBridge. EventBridge é um serviço sem servidor que usa eventos para conectar componentes do aplicativo, o que facilita a criação de aplicativos escaláveis e orientados por eventos. A arquitetura orientada a eventos é um estilo de criar sistemas de software fracamente acoplados que funcionam juntos emitindo e respondendo a eventos. EventBridge fornece um barramento de eventos padrão para eventos publicados por AWS serviços, e você também pode criar um barramento de eventos personalizado para barramentos específicos do domínio.

EventBridge Implementação da Amazon

O fluxo de trabalho consiste nas seguintes etapas:

  1. Os eventos “OrderPlaced" são publicados pelo microsserviço “Pedidos” no barramento de eventos personalizado.

  2. Os microsserviços que precisam agir após a realização de um pedido, como o microsserviço “/route”, são iniciados por regras e metas.

  3. Esses microsserviços geram uma rota para enviar o pedido ao cliente e emitir um evento RouteCreated "”.

  4. Os microsserviços que precisam tomar medidas adicionais também são iniciados pelo evento RouteCreated "”.

  5. Os eventos são enviados para um arquivo de eventos (por exemplo, EventBridge arquivo) para que possam ser reproduzidos para reprocessamento, se necessário.

  6. Eventos históricos de pedidos são enviados para uma nova fila do Amazon SQS (fila de repetição) para reprocessamento, se necessário.

  7. Se os alvos não forem iniciados, os eventos afetados serão colocados em uma fila de mensagens não entregues (DLQ) para análise e reprocessamento adicionais.

Você deve considerar o uso desse padrão se:

  • Os eventos forem usados para reconstruir completamente o estado do aplicativo.

  • Você exige que os eventos sejam reproduzidos no sistema e que o estado de um aplicativo possa ser determinado a qualquer momento.

  • Você desejar poder reverter eventos específicos sem precisar começar com um estado de aplicativo em branco.

  • Seu sistema requerer um fluxo de eventos que possa ser facilmente serializado para criar um log automatizado.

  • Seu sistema exigir operações de leitura pesadas, mas for leve em operações de gravação; operações de leitura pesadas podem ser direcionadas para um banco de dados na memória que é mantido atualizado com o fluxo de eventos.

Importante

Se você usar o padrão de fornecimento de eventos, deverá implantar o Padrão Saga para manter a consistência de dados nos microsserviços.