BT

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

Contribuir

Tópicos

Escolha a região

Início Notícias Consistência de dados em Micro serviços usando Sagas

Consistência de dados em Micro serviços usando Sagas

No QCon San Francisco 2017, Chris Richardson, arquiteto de software, apresentou técnicas de consistência de dados em micro serviços. O principal foco foi no padrão Saga, uma forma de dividir uma transação distribuída em um conjunto de transações menores em qualquer commit ou rollback.

Entre os principais itens destacados na palestra estão:

  • É possível obter a garantia ACID através de micro serviços individuais, pois cada um pode ter sua própria base de dados privada.
  • Para realizar transações distribuídas em arquiteturas de micro serviços, o padrão Saga pode ser adotado. Isso significa que uma transação será dividida em um conjunto de transações menores, conectadas por mensagens, que devem ser commitadas ou realizadas roll back individualmente.
  • O padrão Saga não pode dar garantia de isolamento, o que significa que contramedidas devem ser tomadas para comportamentos anormais.
  • Para garantir um commit ou roll back Saga, pode-se usar uma combinação de reencaminhamento e mensagens de log de transações.

Richardson explicou que, em uma arquitetura de micro serviços, cada serviço deve ter seu próprio banco de dados privado, que não é acessível diretamente por qualquer outro micro serviço. Richardson apontou que embora esta estratégia promova um acoplamento fraco, introduz problemas com a consistência dos dados: "Como implementar transações que abrangem múltiplos micro serviços?"

Para resolver esse problema, Richardson apresentou o padrão Saga, o qual seu princípio mais relevante é que, ao invés de realizar transações longas que mantêm os locks no BD (como two-phase commit), deve-se separar as transações em um conjunto de transações curtas que realizam commits em sequência. Isso leva às seguintes características de ACD:

  • Atomicidade: Ou todas as transações são executadas, ou todas são descartadas
  • Consistente: a integridade referencial é dada por todos os bancos de dados locais e pelo código da aplicação
  • Durabilidade: é garantida por mensage brokers e bancos de dados

Embora se esteja perto de termos a garantia ACID no padrão Saga, ainda falta o isolamento. Isso significa que é possível ler e escrever dados de uma transação incompleta, introduzindo assim várias anomalias. Para contornar este problema, Richardson apresentou várias medidas dentre as quais inclui a realização de transações dentro de uma Saga comutativa ou usar um arquivo de versão para permitir que as transações ocorram em qualquer ordem.

Richardson também demonstrou o quão desafiantes são os rollbacks, pois não são de graça (como em um banco de dados ACID) e, em vez disso, devem ser implementados dentro do código da aplicação. Além disso, quando sagas assíncronas são acionadas por pedidos de API síncronas, a decisão em torno de quando a resposta deve ser dada tem ser tomada - deve-se bloquear até a saga estar completa ou retornar imediatamente e notificar o usuário? Richardson recomendou esta última opção devido à melhor disponibilidade e, também, pelo fato de que a maioria das UIs pode ocultar assincronicidade do usuário.

As sagas podem ser coordenadas de duas maneiras: coreografia - quando os eventos da saga são disparados de forma assíncrona entre micro serviços; e orquestração - quando um serviço centralizado desencadeia e acompanha todas as etapas da saga. Richardson acredita que a abordagem de orquestração traz mais benefícios - reduz as dependências cíclicas e é mais fácil argumentar sobre uma saga centralizada. Para ajudar a obter este resultado ele apresentou o Tram, uma estrutura Saga de código aberto escrita em Java.

Para a comunicação cross-saga, Richardson explicou que, assim como uma transação normal, uma saga deve ter garantia para commitar ou realizar o rollback. Por isso, acredita-se que a mensagem é a única opção lógica, principalmente devido sua durabilidade em comparação com o HTTP. Ele também propôs que as mensagens sejam escritas no banco de dados local antes de serem enviadas, o que significa que o log de transações pode ser fechado para novas publicações, aplicando ainda mais a garantia ACD.

A conversa completa está disponível para assistir online e o código fonte do Tram está disponível no GitHub.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT