Padrão da coreografia saga

Intenção

O padrão de coreografia saga ajuda a preservar a integridade dos dados em transações distribuídas que abrangem vários serviços usando assinaturas de eventos. Em uma transação distribuída, vários serviços podem ser chamados antes que uma transação seja concluída. Quando os serviços armazenam dados em diferentes repositórios de dados, pode ser difícil manter a consistência de dados neles.

Motivação

Uma transação é uma única unidade de trabalho que pode envolver várias etapas, em que todas as etapas são completamente executadas ou nenhuma etapa é executada, resultando em um armazenamento de dados que mantém seu estado consistente. Os termos atomicidade, consistência, isolamento e durabilidade (ACID) definem as propriedades de uma transação. Os bancos de dados relacionais fornecem transações ACID para manter a consistência de dados.

Para manter a consistência em uma transação, os bancos de dados relacionais usam o método de confirmação em duas fases (2PC). Isso consiste em uma fase de preparação e uma fase de confirmação.

• Na fase de preparação, o processo de coordenação solicita que os processos participantes da transação (participantes) prometam confirmar ou reverter a transação.

• Na fase de confirmação, o processo de coordenação solicita que os participantes confirmem a transação. Se os participantes não concordarem em se comprometer na fase de preparação, a transação será revertida.

Em sistemas distribuídos que seguem um padrão database-per-service de design, a confirmação em duas fases não é uma opção. Isso ocorre porque cada transação é distribuída em vários bancos de dados e não há um único controlador que possa coordenar um processo semelhante à confirmação em duas fases em repositórios de dados relacionais. Nesse caso, uma solução é usar o padrão de coreografia saga.

Aplicabilidade

Use o padrão de coreografia saga quando:

• Seu sistema exige integridade e consistência de dados em transações distribuídas que abrangem vários repositórios de dados.

• O armazenamento de dados (por ex., um banco de dados NoSQL) não fornece 2PC para fornecer transações ACID; você precisa atualizar várias tabelas em uma única transação, e implementar 2PC dentro dos limites do aplicativo seria uma tarefa complexa.

• Um processo de controle central que gerencia as transações dos participantes pode se tornar um único ponto de falha.

• Os participantes da saga são serviços independentes e precisam ser vagamente acoplados.

• Há comunicação entre contextos limitados em um domínio comercial.

Problemas e considerações

• Complexidade: à medida que o número de microsserviços aumenta, a coreografia saga pode tornar-se difícil de gerenciar devido ao número de interações entre os microsserviços. Além disso, transações compensatórias e novas tentativas adicionam complexidades ao código do aplicativo, o que pode resultar em sobrecarga de manutenção. A coreografia estará adequada quando houver poucos participantes na saga e você precisar de uma implementação simples sem um único ponto de falha. Quando mais participantes são adicionados, mais difícil fica rastrear as dependências entre os participantes usando esse padrão.

• Implementação resiliente: na coreografia Saga, é mais difícil implementar tempos limite, novas tentativas e outros padrões de resiliência globalmente, em comparação com a orquestração Saga. A coreografia deve ser implementada em componentes individuais em vez de em nível de orquestrador.

• Dependências cíclicas: os participantes consomem mensagens publicadas uns pelos outros. Isso pode resultar em dependências cíclicas, levando a complexidades de código e sobrecargas de manutenção, além de possíveis impasses.

• Problema de gravação dupla: o microsserviço precisa atualizar atomicamente o banco de dados e publicar um evento. A falha de qualquer operação pode levar a um estado inconsistente. Uma maneira de resolver isso é usar o padrão de caixa de saída transacional.

• Preservando eventos: os participantes da saga agem com base nos eventos publicados. É importante salvar os eventos na ordem em que eles ocorrem para fins de auditoria, depuração e repetição. Você pode usar o padrão de fornecimento de eventos para persistir os eventos em um repositório de eventos, caso seja necessária uma repetição do estado do sistema para restaurar a consistência de dados. Os repositórios de eventos também podem ser usados para fins de auditoria e solução de problemas, pois refletem todas as alterações no sistema.

• Consistência eventual: o processamento sequencial de transações locais resulta em consistência eventual, o que pode ser um desafio em sistemas que exigem consistência forte. Você pode resolver esse problema definindo as expectativas de suas equipes comerciais em relação ao modelo de consistência ou reavaliando o caso de uso e migrando para um banco de dados que forneça consistência forte.

• Idempotência: os participantes da saga precisam ser idempotentes para permitir a execução repetida em caso de falhas transitórias causadas por falhas inesperadas e falhas do orquestrador.

• Isolamento de transação: o padrão saga não tem isolamento de transação, que é uma das quatro propriedades nas transações ACID. O grau de isolamento de uma transação determina quantas ou quão poucas outras transações simultâneas podem afetar os dados nos quais ela opera. A orquestração simultânea de transações pode levar a dados obsoletos. Recomendamos usar o bloqueio semântico para lidar com esses cenários.

• Observabilidade: observabilidade se refere ao registro e rastreamento detalhados para solucionar problemas no processo de implementação e orquestração. Isso torna-se importante quando o número de participantes da saga aumenta, resultando em complexidades na depuração. O nd-to-end monitoramento e a geração de relatórios eletrônicos são mais difíceis de conseguir na coreografia da saga, em comparação com a orquestração da saga.

• Problemas de latência: transações compensatórias podem adicionar latência ao tempo geral de resposta quando a saga consiste em várias etapas. Se as transações fizerem chamadas síncronas, isso pode aumentar ainda mais a latência.

Implementação

Arquitetura de alto nível

No diagrama de arquitetura a seguir, a coreografia da saga tem três participantes: o serviço de pedidos, o serviço de estoque e o serviço de pagamento. São necessárias três etapas para concluir a transação: T1, T2 e T3. Três transações compensatórias restauram os dados ao estado inicial: C1, C2 e C3.

• O serviço de pedidos executa uma transação local, T1, que atualiza atomicamente o banco de dados e publica uma mensagem Order placed no agente de mensagens.

• O serviço de estoque assina as mensagens do serviço de pedidos e recebe a mensagem de que um pedido foi criado.

• O serviço de estoque executa uma transação local, T2, que atualiza atomicamente o banco de dados e publica uma mensagem Inventory updated no agente de mensagens.

• O serviço de pagamento assina as mensagens do serviço de estoque e recebe a mensagem de que o estoque foi atualizado.

• O serviço de pagamento executa uma transação local, T3, que atualiza atomicamente o banco de dados com detalhes de pagamento e publica uma mensagem Payment processed para o agente de mensagens.

• Se o pagamento falhar, o serviço de pagamento executa uma transação compensatória, C1, que reverte atomicamente o pagamento no banco de dados e publica uma mensagem Payment failed para o agente de mensagens.

• As transações compensatórias C2 e C3 são executadas para restaurar a consistência dos dados.

Implementação usando serviços da AWS

Você pode implementar o padrão de coreografia da saga usando a Amazon. EventBridge EventBridgeusa eventos para conectar componentes do aplicativo. Ele processa eventos por meio de tubos ou barramentos de eventos. Um barramento de eventos é um roteador que recebe eventos e os entrega a zero ou mais destinos, ou alvos.. As regras associadas ao barramento de eventos avaliam os eventos à medida que eles chegam e os enviam aos alvos para processamento.

Na seguinte arquitetura:

• Os microsserviços — serviço de pedidos, serviço de estoque e serviço de pagamento — são implementados como funções do Lambda.

• Existem três EventBridge ônibus personalizados: ônibus para Orders eventos, ônibus para Inventory eventos e ônibus para Payment eventos.

• As regras Orders, regras Inventory e regras Payment correspondem aos eventos que são enviados para o barramento de eventos correspondente e invocam as funções do Lambda.

Em um cenário bem-sucedido, quando um pedido é feito:

1. O serviço de pedidos processa a solicitação e envia o evento para o barramento de eventos Orders.

2. As regras Orders correspondem aos eventos e iniciam o serviço de estoque.

3. O serviço de estoque atualiza o estoque e envia o evento para o barramento de eventos Inventory.

4. As regras Inventory correspondem aos eventos e iniciam o serviço de pagamento.

5. O serviço de pagamento processa o pagamento e envia o evento para o barramento de eventos Payment.

6. As regras Payment correspondem aos eventos e enviam a notificação do evento Payment processed ao receptor.

   Como alternativa, quando há um problema no processamento do pedido, EventBridge as regras iniciam as transações compensatórias para reverter as atualizações de dados para manter a consistência e a integridade dos dados.

7. Se o pagamento falhar, as regras Payment processam o evento e iniciam o serviço de estoque.O serviço de inventário executa transações compensatórias para reverter o estoque.

8. Quando o estoque é revertido, o serviço de estoque envia o evento Inventory reverted para o barramento de eventosInventory.Esse evento é processado por regras Inventory.Ele inicia o serviço de pedidos, que executa a transação compensatória para remover o pedido.

Conteúdo relacionado

• Padrão de orquestração da saga

• Padrão de caixa de saída transacional

• Tente novamente com o padrão de recuo