Padrão de transações distribuídas Saga

O padrão de design Saga é uma maneira de gerenciar a consistência de dados entre microsserviços em cenários de transações distribuídas. Uma saga é uma sequência de transações que atualiza cada serviço e publica uma mensagem ou evento para acionar a próxima etapa da transação. Se uma etapa falhar, a saga executa transações de compensação que neutralizam as transações anteriores.

Contexto e problema

Uma transação é uma única unidade de lógica ou trabalho, às vezes composta de várias operações. Dentro de uma transação, um evento é uma alteração de estado que ocorre em uma entidade, e um comando encapsula todas as informações necessárias para executar uma ação ou disparar um evento posterior.

As transações devem ser atômicas, consistentes, isoladas e duráveis (ACID). As transações dentro de um único serviço são ACID, mas a consistência de dados entre serviços requer uma estratégia de gerenciamento de transações entre serviços.

Em arquiteturas multisserviços:

• A atomicidade é um conjunto indivisível e irredutível de operações que devem ocorrer todas ou nenhuma.
• Consistência significa que a transação traz os dados apenas de um estado válido para outro estado válido.
• O isolamento garante que as transações simultâneas produzem o mesmo estado de dados que as transações executadas sequencialmente teriam produzido.
• A durabilidade garante que as transações comprometidas permaneçam comprometidas mesmo em caso de falha do sistema ou falta de energia.

Um modelo de banco de dados por microsserviço oferece muitos benefícios para arquiteturas de microsserviços. O encapsulamento de dados de domínio permite que cada serviço use seu melhor tipo de armazenamento de dados e esquema, dimensione seu próprio armazenamento de dados conforme necessário e fique isolado de falhas de outros serviços. No entanto, garantir a consistência dos dados entre bancos de dados específicos do serviço representa desafios.

Transações distribuídas, como o protocolo de confirmação em duas fases (2PC), exigem que todos os participantes de uma transação confirmem ou revertam antes que a transação possa prosseguir. No entanto, algumas implementações de participantes, como bancos de dados NoSQL e intermediação de mensagens, não suportam esse modelo.

Outra limitação da transação distribuída é a sincronicidade e disponibilidade da comunicação entre processos (IPC). O IPC fornecido pelo sistema operacional permite que processos separados compartilhem dados. Para que as transações distribuídas sejam confirmadas, todos os serviços participantes devem estar disponíveis, reduzindo potencialmente a disponibilidade geral do sistema. Implementações arquitetônicas com limitações de IPC ou transação são candidatas ao padrão Saga.

Solução

O padrão Saga fornece gerenciamento de transações usando uma sequência de transações locais. Uma transação local é o esforço de trabalho atômico realizado por um participante da saga. Cada transação local atualiza o banco de dados e publica uma mensagem ou evento para disparar a próxima transação local da saga. Se uma transação local falhar, a saga executará uma série de transações de compensação que desfazem as alterações feitas pelas transações locais anteriores.

Nos padrões de Saga:

• As operações compensáveis são operações que podem potencialmente ser revertidas através do processamento de outra transação com o efeito contrário.
• Uma transação pivot é o ponto de ir/não ir em uma saga. Se a transação de pivô for confirmada, a saga será executada até a conclusão. Uma transação pivot pode ser uma transação que não é compensável nem retentável, ou pode ser a última transação compensável ou a primeira transação retryable na saga.
• Transações retryable são transações que seguem a transação pivot e têm a garantia de sucesso.

Há duas abordagens comuns de implementação da saga, coreografia e orquestração. Cada abordagem tem seu próprio conjunto de desafios e tecnologias para coordenar o fluxo de trabalho.

Coreografia

A coreografia é uma forma de coordenar sagas onde os participantes trocam eventos sem um ponto de controlo centralizado. Com a coreografia, cada transação local publica eventos de domínio que acionam transações locais em outros serviços.

Benefícios

• Bom para fluxos de trabalho simples que exigem poucos participantes e não precisam de uma lógica de coordenação.
• Não requer implementação e manutenção de serviços adicionais.
• Não introduz um único ponto de falha, uma vez que as responsabilidades estão distribuídas pelos participantes da saga.

Desvantagens

• O fluxo de trabalho pode se tornar confuso ao adicionar novas etapas, pois é difícil rastrear quais participantes da saga ouvem quais comandos.
• Há um risco de dependência cíclica entre os participantes da saga porque eles têm que consumir os comandos uns dos outros.
• O teste de integração é difícil porque todos os serviços devem estar em execução para simular uma transação.

Orquestração

A orquestração é uma maneira de coordenar sagas onde um controlador centralizado diz aos participantes da saga quais transações locais executar. O orquestrador da saga lida com todas as transações e diz aos participantes qual operação realizar com base nos eventos. O orquestrador executa solicitações de saga, armazena e interpreta os estados de cada tarefa e lida com a recuperação de falhas com transações de compensação.

Benefícios

• Bom para fluxos de trabalho complexos envolvendo muitos participantes ou novos participantes adicionados ao longo do tempo.
• Adequado quando há controle sobre cada participante do processo, e controle sobre o fluxo de atividades.
• Não introduz dependências cíclicas, porque o orquestrador depende unilateralmente dos participantes da saga.
• Os participantes da Saga não precisam saber sobre comandos para outros participantes. A separação clara de preocupações simplifica a lógica de negócios.

Desvantagens

• A complexidade adicional do projeto requer a implementação de uma lógica de coordenação.
• Há um ponto adicional de falha, porque o orquestrador gerencia o fluxo de trabalho completo.

Problemas e considerações

Considere os seguintes pontos ao implementar o padrão Saga:

• O padrão Saga pode ser inicialmente desafiador, pois requer uma nova maneira de pensar sobre como coordenar uma transação e manter a consistência de dados para um processo de negócios que abrange vários microsserviços.
• O padrão Saga é particularmente difícil de depurar, e a complexidade cresce à medida que os participantes aumentam.
• Os dados não podem ser revertidos, porque os participantes da saga confirmam alterações em seus bancos de dados locais.
• A implementação deve ser capaz de lidar com um conjunto de potenciais falhas transitórias e fornecer idempotência para reduzir os efeitos colaterais e garantir a consistência dos dados. Idempotência significa que a mesma operação pode ser repetida várias vezes sem alterar o resultado inicial. Para obter mais informações, consulte as orientações sobre como garantir a idempotência ao processar mensagens e atualizar o estado juntos.
• É melhor implementar a observabilidade para monitorar e acompanhar o fluxo de trabalho da saga.
• A falta de isolamento dos dados dos participantes impõe desafios de durabilidade. A implementação da saga deve incluir contramedidas para reduzir as anomalias.
• As transações compensatórias nem sempre funcionam.

As seguintes anomalias podem acontecer sem medidas adequadas:

• Atualizações perdidas, quando uma saga escreve sem ler as alterações feitas por outra saga.
• Dirty lê, quando uma transação ou uma saga lê atualizações feitas por uma saga que ainda não completou essas atualizações.
• Leituras difusas/não repetíveis, quando diferentes etapas da saga leem dados diferentes porque ocorre uma atualização de dados entre as leituras.

As contramedidas sugeridas para reduzir ou prevenir anomalias incluem:

• Bloqueio semântico, um bloqueio no nível do aplicativo em que a transação compensável de uma saga usa um semáforo para indicar que uma atualização está em andamento.
• Atualizações comutativas que podem ser executadas em qualquer ordem e produzem o mesmo resultado.
• Visão pessimista: é possível que uma saga leia dados sujos, enquanto outra saga está executando uma transação compensável para reverter a operação. A visão pessimista reordena a saga para que os dados subjacentes sejam atualizados em uma transação retentável, o que elimina a possibilidade de uma leitura suja.
• O valor de releitura verifica se os dados estão inalterados e, em seguida, atualiza o registro. Se o registro tiver sido alterado, as etapas serão abortadas e a saga poderá ser reiniciada.
• Um arquivo de versão registra as operações em um registro à medida que elas chegam e, em seguida, as executa na ordem correta.
• Por valor usa o risco de negócios de cada solicitação para selecionar dinamicamente o mecanismo de simultaneidade. As solicitações de baixo risco favorecem as sagas, enquanto as solicitações de alto risco favorecem as transações distribuídas.

Quando utilizar este padrão

Use o padrão Saga quando precisar:

• Garanta a consistência dos dados em um sistema distribuído sem acoplamento rígido.
• Reverter ou compensar se uma das operações na sequência falhar.

O padrão Saga é menos adequado para:

• Transações fortemente acopladas.
• Operações de compensação que ocorrem em participantes anteriores.
• Dependências cíclicas.

Exemplo

O Saga on Serverless baseado em orquestração é uma referência de implementação de saga usando a abordagem de orquestração que simula um cenário de transferência de dinheiro com fluxos de trabalho bem-sucedidos e com falha.

Próximos passos

• Dados distribuídos
• Richardson, Chris. 2018: Padrões de Microsserviços. Manning Publicações.

Recursos relacionados

Os padrões seguintes podem também ser úteis ao implementar este padrão:

• A coreografia faz com que cada componente do sistema participe do processo de tomada de decisão sobre o fluxo de trabalho de uma transação comercial, em vez de depender de um ponto central de controle.
• As transações de compensação desfazem o trabalho realizado por uma série de etapas e, eventualmente, definem uma operação consistente se uma ou mais etapas falharem. Os aplicativos hospedados na nuvem que implementam processos de negócios e fluxos de trabalho complexos geralmente seguem esse modelo de consistência eventual.
• A repetição permite que um aplicativo lide com falhas transitórias quando tenta se conectar a um serviço ou recurso de rede, repetindo de forma transparente a operação com falha. Repetir pode melhorar a estabilidade do aplicativo.
• O disjuntor lida com falhas que levam um tempo variável para serem recuperadas, ao se conectar a um serviço ou recurso remoto. O disjuntor pode melhorar a estabilidade e a resiliência de uma aplicação.
• O monitoramento de pontos finais de integridade implementa verificações funcionais em um aplicativo que ferramentas externas podem acessar por meio de pontos de extremidade expostos em intervalos regulares. O monitoramento de pontos finais de integridade pode ajudar a verificar se os aplicativos e serviços estão funcionando corretamente.