O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

La Duck Conf : "Microservices et transactions distribuées"

287 visualizações

Publicada em

Présentation du talk de Julien Stainer & Bertrand Le Foulgoc - OCTO Technology
Le nombre de composants d’un système et de leurs interactions
est en forte augmentation, et les architectures microservices ne
font que renforcer cette tendance.
Nous parlerons "transactions" distribuées, par le biais d’une
approche théorique, mais aussi pratique basée sur des retours
d’expérience : quels sont les défis rencontrés et comment y
remédier ?

Publicada em: Tecnologia
  • Seja o primeiro a comentar

La Duck Conf : "Microservices et transactions distribuées"

  1. 1. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 1
  2. 2. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 29.01 2019 ESPACE ST MARTIN - PARIS #LaDuckConf
  3. 3. Transactions distribuées Avenue Mon-Repos 14 > 1005 LAUSANNE > SUISSE > WWW.OCTO.COM
  4. 4. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 4 Bertrand LE FOULGOC Consultant @OCTOSuisse +41 79 138 01 22 blefoulgoc@octo.com Julien STAINER Consultant @OCTOSuisse +41 75 418 79 34 jstainer@octo.com OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 4
  5. 5. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 5 Sommaire ◉ Définition ◉ Tolérance aux fautes < Idempotence < Files persistantes ◉ Patterns < Chorégraphie < Orchestration ◉ Tests < Chaos < Robustesse
  6. 6. THERE IS A BETTER WAY Définition 6
  7. 7. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 7 Transaction distribuée (dans une architecture microservice) < Un événement unique entraîne la mutation de deux ou plusieurs sources de données distinctes qui ne peuvent pas être validées atomiquement. < Les transactions distribuées dans les microservices sont à éviter autant que possible. < L'atomicité cède la place à la cohérence éventuelle Une définition http://www.grahamlea.com/2016/08/distributed-transactions-microservices-icebergs/
  8. 8. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 8 Théorème de CAP (Brewer) Chaque lecture reçoit la donnée la plus récente ou une erreur Chaque requête reçoit une réponse (non-erreur) Le système fonctionne malgré la chute ou le retard des messages
  9. 9. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 9 CALM Theorem ◉ Consistency and logical monotonicity ◉ Bloom language ◉ Disorderly distributed programming
  10. 10. THERE IS A BETTER WAY Tolérance aux fautes 10
  11. 11. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable < Prenons le cas d’un système de réservation de voyages en Suisse, composé de trois services : + Un service permet la réservation de billets d’avion + Un autre la location de voitures + Le dernier permet de choisir un chalet et des skis 11 Problèmes – un cas concret SCA
  12. 12. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 12 Problèmes – concentrons-nous sur un service S < Avec une approche naïve, sans file persistante
  13. 13. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 13 Problèmes – concentrons-nous sur un service S < Avec une approche naïve, sans file persistante < Si le service tombe en vol, on perd la transaction, l’utilisateur attend, et reçoit un message d’erreur S
  14. 14. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 14 Problèmes – concentrons-nous sur un service < Avec une file persistante S
  15. 15. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 15 Problèmes – concentrons-nous sur un service < Avec une file persistante < Si le service tombe entre deux messages, pas de problème S S
  16. 16. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 16 Problèmes – concentrons-nous sur un service < Avec une file persistante < Si le service tombe entre deux messages, pas de problème < Si le service tombe pendant le traitement d’un message, on perd la transaction S S
  17. 17. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 17 Problèmes – concentrons-nous sur un service < Avec une file persistante, en supprimant uniquement une fois le message traité < Si le service tombe pendant le traitement, pas de problème ? S S
  18. 18. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 18 Problèmes – concentrons-nous sur un service < Avec une file persistante, en supprimant uniquement une fois le message traité < Si le service tombe pendant le traitement, pas de problème ? < Uniquement si le fait de rejouer la transaction n’est pas risqué, on parle d’idempotence S S
  19. 19. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 19 Problèmes – avec deux services < Nous choisissons le fonctionnement en série S
  20. 20. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 20 Problèmes – avec deux services < Nous choisissons le fonctionnement en série S
  21. 21. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 21 Problèmes – avec deux services < Nous choisissons le fonctionnement en série C
  22. 22. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 22 Problèmes – avec deux services < Nous choisissons le fonctionnement en série < Que se passe-t-il si mon deuxième service ne peut pas effectuer la réservation ? C
  23. 23. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 23 Problèmes – avec deux services < Nous choisissons le fonctionnement en série < Que se passe-t-il si mon deuxième service ne peut pas effectuer la réservation ? < Il faut traiter le cas, soit manuellement, soit automatiquement. C
  24. 24. THERE IS A BETTER WAY Patterns 24
  25. 25. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable < Pour chaque sous-transaction, nous définissons une sous-compensation associée. < Les sous-transactions et sous-compensations sont idempotentes < Attention aux transactions sans compensations 25 Patterns - Chorégraphie SCA
  26. 26. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Patterns - Chorégraphie C AS
  27. 27. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Patterns - Chorégraphie C AS
  28. 28. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Patterns - Chorégraphie S C AS C
  29. 29. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Patterns - Chorégraphie C-1 C AS S
  30. 30. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Naturel, instinctif Simple, facile à comprendre Effort minimal Aucun couplage à d'autres composants Idempotent Robuste Complexité potentiellement exponentielle Les dépendances cycliques sont difficiles à diagnostiquer Les tests de bout en bout sont difficiles 30 Patterns - Chorégraphie
  31. 31. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable < Si le service en amont ne gère pas le séquencement et que l’on lance tout en parallèle: + Comment compenser une transaction qui n’a pas eu lieu ? + Combien de temps garde-t-on le message ? + … 31 Patterns – passage en parallèle, montée à l’échelle SCA
  32. 32. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable < Un journal des transactions est maintenu 32 Patterns - Orchestrateur C AS
  33. 33. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable < Un journal des transactions est maintenu < Les compensations sont jouées en cas d’erreur 33 Patterns - Orchestrateur C AS C C-1 S
  34. 34. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable < Un journal des transactions est maintenu < Les compensations sont jouées en cas d’erreur 34 Patterns - Orchestrateur C AS C C-1 S < L’introduction de parallélisme doit être justifiée, car ce choix augmente fortement la complexité
  35. 35. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable ◉ « Smart end-points, dumb pipes » C’est juste un service il est idéalement interne à l'équipe 35 ◉ « Smart pipes » ◉ Découpe un message en sous-messages Un service pour les gouverner tous... Géré par une équipe, implique les autres Patterns - Orchestrateur On dirait un ESB !?
  36. 36. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable ◉ « Smart end-points, dumb pipes » C’est juste un service Il est idéalement interne à l'équipe 36 ◉ « Smart pipes » ◉ Découpe un message en sous-messages Un service pour les gouverner tous... Géré par une équipe, implique les autres Patterns - Orchestrateur On dirait un ESB !?
  37. 37. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Pas de dépendances cycliques Simplifie les services Plus facile à tester Complexité linéaire Idempotence Résistance aux fautes Logique décentralisée (! ESB) Point de défaillance unique (redondance) Couplage plus fort 37 Patterns - Orchestrateur
  38. 38. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 38 Patterns – Chorégraphie vs Orchestrateur
  39. 39. THERE IS A BETTER WAY Des défis ?
  40. 40. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable ◉ La disponibilité du système est le produit des disponibilités des services < 99.99% disponible signifie 53 minutes d'arrêt < Devient 8 à 9 heures par an une fois combiné ◉ Les arrêts vont arriver, faites-en un non-événement (design for failure) < Hystrix < Resilient4j < … ◉ Le Monitoring devient plus critique que jamais < Configurez des alertes < Affichez les métriques système importantes Défis techniques – Monitoring https://www.youtube.com/watch?v=SmRcSezrsZM Josh Evans QCon San Fransisco 2016 40
  41. 41. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable ◉ Définition de SLAs pour chaque service < RPObjective < RTObjective < Temps de réponse < Charge maximale < Disponibilité garantie etc… ◉ Utilisez les indicateurs actuels pour commencer < Empêche la régression Informe les utilisateurs potentiels Défis techniques – La Mesure 41
  42. 42. THERE IS A BETTER WAY Tests 42
  43. 43. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 43 ◉ Définir un état stable, à l'aide d'un groupe de contrôle ◉ Introduire des variations dans le groupe expérimental ◉ Mesurer les différences et agir en conséquence https://principlesofchaos.org Groupe de contrôle Groupe expérimental Tests – Chaos engineering 1% 1% 1% 99%
  44. 44. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 44 ◉ Maturation rapide ◉ Beaucoup de bibliothèques et d'outils à choisir ◉ Ne commencez pas par les tests en prod Chaos Monkey for Spring Boot Tests – Chaos engineering https://github.com/dastergon/awesome-chaos-engineering Tests de sécurité dans AWS https://openchaos.io http://principlesofchaos.org
  45. 45. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 45 Tests – maîtrisez vos classiques VS. Manual User Interface Integration Unit Unit Integration End to end Component Exploratory
  46. 46. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Impact d'un changement d'API a augmenté < Déploiements indépendants Dépendances entre services multipliées Travailler avec des équipes séparées < Release management < Version management RESTful API design < Harmonisez < Utilisez des guides clairs Consumer driven contract 46 Tests – interactions des services
  47. 47. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable Tests – Cibler les tests de tolérance aux fautes ◉ Tests de résilience aveugles : < les erreurs sont à corriger < l’absence d’erreur ne garantit rien ◉ Tests unitaires et composants : < permettent de valider le composant < ne couvrent pas la configuration de l’environnement < ne permettent pas de tester une chaîne de défaillances impliquant plusieurs composants ◉ Tests ciblés de défaillance : < utilisation d’un debugger pour instrumenter les composants de façon peu intrusive < scripting pour déclencher les défaillances au moments critiques < possibilité de scénarios impliquant des chaînes de défaillances < capacité à vérifier les comportements en situation critique dans une situation réaliste 47
  48. 48. OCTO © 2019 - Reproduction interdite sans autorisation écrite préalable 48 Conclusion Les transactions distribuées, c’est dur Pourquoi < Attention à l’over-engineering Comment < Prenez le temps de valider vos choix quant au théorème de CAP Quoi < Implémentation et tests des limites
  49. 49. Nous réalisons des missions de conseil IT et nous développons vos applications stratégiques… Différement.

×