Gerenciando transações em uma arquitetura com microserviços

Transcript

1. Gerenciando transações em uma arquitetura de microserviços +
2. 2 + LEONEL MORAIS • ~ 10 anos de experiência em engenharia de software • Java, PHP, Ruby, Python, NodeJS, GoLang, Angular • Incentivador da cultura DevOps
3. 3 ANTES DOS MICROSERVIÇOS... +
4. 4 MONOLITO • Todos os módulos que compõem a aplicação compartilham um mesmo banco de dados • Várias tabelas podem ser envolvidas em uma transação • Banco de dados se torna um único ponto de falha +
5. 5 COM O TEMPO O MONOLITO... • Fica difícil de manter • Difícil de lançar novas features • Torna processos de deployment e releases lentos e dolorosos +
6. 6 ENTÃO DECIDIMOS MUDAR PARA MICROSERVIÇOS... +
7. 7 MICROSERVIÇOS • Arquitetura autosuficiente e isolada • Evolução e processo de deployment mais rápido • Facilita a adoção de novas tecnologias • Possível escalar de forma independente +
8. 8 MICROSERVIÇOS • Interface bem definida e persistência independente • Não deve compartilhar dados com bancos de dados de outros serviços • Integrações devem ser feitas via API, não via banco +
9. 9 E AGORA, COMO FICAM AS TRANSAÇÕES ? +
10. 10 BEGIN; INSERT INTO ORDER … ; UPDATE STOCK WHERE …; COMMIT; +
11. 11 BEGIN; INSERT INTO ORDER … ; UPDATE STOCK WHERE …; COMMIT; +
12. 12 COMO MANTER A CONSISTÊNCIA DE DADOS? • Quando movemos para uma arquitetura de microserviços as coisas ficam um pouco mais complicadas • Necessitamos compartilhar dados entre diferentes serviços • Consumir dados de tabelas dos bancos de dados de serviços • E também fazer transações, várias operações entre múltiplos serviços que no final geram uma única unidade atômica. +
13. 13 TRANSAÇÕES DISTRIBUÍDAS? NÃO! • Coordenador de transações se torna ponto único de falha • Performance ruim, locks! • Processamento síncrono • Nenhum serviço de Cloud implementa transações distribuídas pois é difícil alcançar escalabilidade e confiabilidade +
14. 14 SAGA PATTERN +
15. 15 SAGA • Primeiro paper publicado em 1987 • https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf • Implementa um workflow de transações, cada transação acontece no escopo de cada serviço localmente • Para cada transação existe uma operação de compensação para caso de falha • Ao final de cada transação é publicado um evento que é consumido pela transação seguinte. +
16. 16 SAGA +
17. 17 SAGA +
18. 18 COMO PODEMOS IMPLEMENTAR ? +
19. 19 EVENTOS ! +
20. 20 SAGA - Eventos • O serviço executa uma transação local e publica um evento referente. • O evento pode ser escutado por um ou mais serviços que podem executar transações e publicar novos eventos. • O workflow é finalizado quando o último serviço executa uma transação e não publica nenhum evento +
21. 21 SAGA - Eventos • +
22. 22 SAGA - Eventos (Compensação) • +
23. 23 CONCLUSÃO • SAGA para manter a consistência entre os serviços • 2PC não é recomendado • Modelo de implementação se torna simples com eventos • Nenhum acoplamento entre os participantes (serviços) +
24. Obrigado! Leonel Morais leonel.morais@rivendel.com.br +