Nos últimos anos, o hype de se trabalhar com uma arquitetura de microsserviços cresceu muito. Na verdade as vantagens e desvantagens em relação a uma arquitetura monolítica daria um livro.
Alguns desafios são presentes em ambas arquiteturas, mas a solução quase sempre é diferente, como o de lidar com a atomicidade e integridade dos dados.
Atomicidade
Quando falamos de atomicidade estamos nos referimos ao princípio que garante que os dados sejam consistentes em todo o ecossistema que envolve a aplicação.
O conceito de integridade é a garantia de precisão dos dados em todo o seu ciclo de vida. Em arquiteturas do tipo monolítico a solução que quase sempre é utilizada é o recurso transacional de banco, que isola o processo de persistência de dados. Caso ocorra algum erro, ele o mesmo reverte as alterações realizadas.
Podemos definir transação como uma sequência síncrona de atividades que querem garantir a execução de um processamento. Havendo COMMIT, ou seja, a confirmação do fim dessa sequência ou ROLLBACK para falhas, ocasionando na reversão da execução dessas atividades.
Quando existe um contexto de múltiplas integrações com serviços independentes se torna impossível implementar o contexto transacional único, pois possivelmente cada sistema externo possui um repositório e caso ocorra um erro no fluxo em cadeia a aplicação não teria o acesso a eles.
Esse cenário apresentado é típico de uma arquitetura de microsserviços, onde cada aplicação possui sua própria base de dados e está isolada em ambientes diferentes das outras.
Quando existe essa estrutura, o leque de problemas que podem vir a dificultar o funcionamento da aplicação se abre. Falhas de infraestrutura, como comunicação entre ambientes, bugs ou erros de regra de negócio podem gerar quebra em qualquer momento do fluxo de processamento.
Para que continue existindo atomicidade no ecossistema, deve ser feita uma ação compensatória para correção, ou seja, todo serviço já chamado deve ser contactado novamente para reverter a alteração feita. Assim, todas as bases estarão síncronas de acordo com seu escopo não onerando a veracidade de seus dados. Ou seja, temos contextos transacional para cada um, onde cada serviço tem responsabilidade sobre seus próprios dados.
Padrão SAGA
Existem um padrão de projeto chamado SAGA que conta com duas estratégias de utilização: Coreografia e Orquestração. Os dois possuem suas particularidades, mas trabalham para resolver esse problema apresentado de transações distribuídas.
A coreografia consiste em cada microsserviço realizando uma chamada de forma assíncrona com outro ao finalizar seu processamento com sucesso. Um dos pontos fortes dessa estratégia é não haver um ponto único de falha, mas em contrapartida entramos em outros desafios da arquitetura de micro serviços, logs distribuídos e rastreio.
Um ponto de atenção é observar que cada serviço deve conhecer o próximo até não haver um próximo, resultando no fim do fluxo.
Como explicado anteriormente, por se tratar de transações independentes respondendo de forma assíncrona, qualquer falha resulta em um evento de cancelamento para todos os serviços integrados que participaram do fluxo até então.
A orquestração trabalha de forma síncrona, delegando a um “responsável” o poder de organizar esse fluxo de entrega, centralizando as chamadas dos microsserviços e separando por steps ou pequenos flows.
Cada chamada é feita de forma sequencial, aguardando sempre a finalização de uma para começar outra. Ao falhar qualquer chamada, seja por erros sistêmicos ou regras de negócio o próprio orquestrador faz o rollback, chamando novamente cada serviço que completou sua ação para reverter sua parte.
A vantagem de ter essa centralização do fluxo de transações distribuídas pode resultar no ponto único de falha, dependência que pode ser custosa. Um ponto de atenção é evitar lógica de negócio para esse “orquestrador”, para que o mesmo seja somente um proxy entre as chamadas de execução.
Quando falamos de solução em TI sempre chegamos a mesma resposta: “Tudo depende”. Cada abordagem tem seus pontos fortes e fracos, um bom resultado é gerado de acordo com cada situação e seu ambiente. Nem sempre o SAGA vai resolver esse problema de transações distribuídas, mas pode ser considerado por ser um padrão bem utilizado para tal.
Veja uma poc de um modelo de orquestrador.
Ainda ficou com alguma dúvida no assunto? Não deixe de me contar sua opinião nos comentários!
