Quando você acha que microsserviços são um pouco “volumosos”, experimente este velho amigo Saga

Construir microsserviços é como blocos de construção. É lindo que cada módulo opere de forma independente. Mas uma vez envolvido o processamento de transações entre serviços, a bela imagem pode facilmente ser quebrada em pedaços - o pedido é criado, mas o estoque não é deduzido, o pagamento é bem-sucedido, mas a logística não é acionada, você pode ter encontrado coisas tão ruins.

Por que as transações distribuídas sempre causam dores de cabeça?

Imagine o seguinte: você compra um livro online e, depois de clicar para pagar, o sistema indica sucesso. Poucos dias depois, recebi um e-mail dizendo “Pedido cancelado por falta de estoque”, mas o dinheiro já havia sido descontado. Este não é um cenário fictício, mas um problema típico de inconsistência de dados em sistemas distribuídos. As transações de banco de dados tradicionais funcionam bem em um único aplicativo, mas após a divisão em microsserviços, cada serviço usa seu próprio banco de dados e as transações ACID não podem cruzar os limites da rede.

Portanto, algumas pessoas tentaram o commit em duas fases (2PC), mas gargalos de desempenho e problemas de bloqueio de sincronização desencorajaram muitas equipes. Especialmente em cenários de alta simultaneidade, o coordenador se torna um ponto único de falha e a disponibilidade geral do sistema diminui. É como pedir a um maestro que coordene a execução de dez orquestras ao mesmo tempo. Se o ritmo estiver ligeiramente desalinhado, toda a peça ficará confusa.

Padrão de design Saga: mude seu pensamento e coordene ações

A ideia central da Saga é bastante simples: dividir uma transação longa em uma série de transações locais e acionar a próxima após a conclusão de cada transação. Se uma etapa intermediária falhar, uma série de operações de compensação são realizadas para reverter o impacto anterior. Não busca a atomicidade, mas garante consistência eventual.

Parece um pouco abstrato? Vejamos um exemplo da vida real: você organiza um tour de palestras por várias cidades. A abordagem tradicional é esperar até que todos os locais sejam confirmados antes de anunciar o itinerário, mas isso pode perder o melhor período de publicidade. A ideia de Saga é finalizar primeiro o primeiro local, depois reservar o segundo local e depois o terceiro local... Se houver um problema temporário com um determinado local da cidade, o local programado subsequente será cancelado e um plano alternativo será coordenado. Todo o processo pode não estar completamente sincronizado, mas acabará por fazer o passeio acontecer.

Várias maneiras de implementar Saga em microsserviços Java

Uma saga orquestrada é como um diretor contando a história – há um coordenador central (geralmente chamado de orquestrador) que diz a cada serviço o que fazer e quando fazê-lo. Os serviços não se comunicam diretamente entre si, apenas conversam com o coordenador. Essa abordagem é logicamente centralizada e fácil de entender e depurar, mas o coordenador pode facilmente se tornar um gargalo. É adequado para cenários com poucas etapas de transação e processos estáveis.

Uma saga de concerto é mais parecida com uma improvisação de jazz - depois que cada serviço completa sua tarefa, publica um evento para notificar o próximo serviço. Não existe um comando central e os serviços são orientados por eventos. Esta solução tem boa escalabilidade e baixo acoplamento de serviços, mas é trabalhoso rastrear todo o fluxo de transações, e depurar quando ocorre um erro é como resolver um quebra-cabeça.

Qual escolher? Se sua equipe é boa em arquitetura orientada a eventos e as etapas das transações mudam com frequência, o Concerto é mais flexível. Se você busca controlabilidade e observabilidade de processos, a orquestração pode ser mais conveniente. Não há vantagem ou desvantagem absoluta, apenas correspondência de cena.

Por que o sistema fica mais “resistente” depois de usar o Saga?

A mudança mais intuitiva após a adoção do modo Saga é que o rendimento do sistema aumenta – como os serviços não esperam mais pela sincronização, a utilização de recursos aumenta naturalmente. Mais importante ainda, torna o sistema “resiliente”: a indisponibilidade temporária de um determinado serviço não fará com que toda a transação fique bloqueada e o mecanismo de compensação dá espaço para reparação e nova tentativa.

Há um caso prático: durante um período de promoção, uma plataforma de comércio eletrónico sofreu uma pressão excessiva no serviço de encomendas e atrasou a sua resposta. No modo de transação tradicional, os serviços de pagamento e estoque aguardarão a resposta do serviço de pedidos simultaneamente, fazendo com que o pagamento do usuário expire e falhe. Após a mudança para a implementação do Saga, o atraso no atendimento do pedido afeta apenas o seu próprio processo de compensação. Os serviços de pagamento e inventário ainda podem ser processados ​​de forma assíncrona e a taxa de sucesso do pagamento do usuário é muito maior.

Como é uma implementação útil do Saga?

Uma implementação Saga bem projetada geralmente tem várias características: as operações de compensação são idempotentes (a execução repetida tem o mesmo efeito), o status da transação é rastreável e os tempos limite e os mecanismos de nova tentativa são razoáveis. Parecem detalhes técnicos, mas afetam diretamente a experiência de desenvolvimento.

potênciaAo lidar com tais requisitos, descobrimos que muitas equipes ficaram presas no desenho da lógica de remuneração. Por exemplo, a compensação para “reduzir estoque” é “restaurar estoque”, mas o tempo limite da rede pode fazer com que a operação de compensação seja repetida. Se você simplesmente executar "Inventário +1", múltiplas compensações causarão confusão nos dados. Portanto, em sua solução, a operação de compensação verificará se o ID da transação original foi processado para evitar acúmulos repetidos.

Quando você deve considerar a introdução de uma saga?

Se você descobrir que sua equipe gasta muito tempo lidando com limpeza de dados “parcialmente bem-sucedida” ou que todo o link está bloqueado porque um serviço está inativo, é hora de dar uma olhada no Saga. Especialmente quando o negócio envolve processamento assíncrono em várias etapas - por exemplo, a compra de um curso on-line envolve seleção de curso, pagamento, ativação de permissão e envio de notificação, essas etapas são naturalmente adequadas para a coordenação do Saga.

Ao iniciar a implementação, recomenda-se testar uma pequena escala e selecionar um processo não essencial, mas típico, para transformar primeiro. Registre a taxa de erro, o tempo de conclusão da transação e as alterações nos custos de desenvolvimento e depuração antes e depois da transformação. Os dados dirão se vale a pena promover.

Possíveis armadilhas e desvios

Saga não é uma solução mágica. Operações de compensação mal concebidas podem causar “danos secundários” – tais como reembolsos e deduções repetidas. Eventos fora de ordem podem levar a status inconsistentes, por exemplo, o evento “cancelamento de pedido” chega antes do evento “criação de pedido”. Essas questões precisam ser cuidadosamente projetadas em conjunto com o negócio.

Uma estratégia prática é adicionar um número de versão ou carimbo de data/hora a cada etapa da transação e verificar a ordem quando o serviço downstream a processa. Recomenda-se configurar um painel de monitoramento Saga para exibir transações em andamento e status anormais em tempo real para facilitar uma intervenção rápida. Afinal, por melhor que seja a automação, ela ainda exige trabalho manual.

escrito em

Os sistemas distribuídos são como várias pessoas colaborando para concluir trabalhos manuais - a sincronização completa é ineficiente e a assincronia completa é propensa ao caos. Saga encontra o meio-termo: permitir que todos os envolvidos trabalhem em seu próprio ritmo e, ao mesmo tempo, garantir que o produto final esteja completo. Não é perfeito, mas leva muitos projetos de microsserviços de “mal executados” a “colaboração tranquila”.

Da próxima vez que você tiver dor de cabeça com a consistência dos dados entre serviços, é melhor dar uma olhada nas transações. Talvez esses fluxos de negócios aparentemente complexos precisem apenas ser conectados de outra maneira.

Fundada em 2005,potênciatem se dedicado a um fabricante profissional de unidades de movimento compacto, com sede em Dongguan, província de Guangdong, China. Aproveitando inovações em tecnologia de acionamento modular,potênciaintegra motores de alto desempenho, redutores de precisão e sistemas de controle multiprotocolo para fornecer soluções de sistemas de acionamento inteligentes eficientes e personalizadas. A Kpower forneceu soluções profissionais de sistemas de acionamento para mais de 500 clientes empresariais em todo o mundo, com produtos que abrangem vários campos, como sistemas domésticos inteligentes, eletrônica automática, robótica, agricultura de precisão, drones e automação industrial.