Comment se rapprocher de la cohérence dans l’architecture de microservices

Lorsqu’il s’agit de transactions, la première chose qui vient à l’esprit est ACID. En fait, ACID est un concept important en 4 points :

• Atomicité : Chaque instruction d’une transaction (pour lire, écrire, mettre à jour ou supprimer des données) est traitée comme une seule unité. Soit l’intégralité de l’instruction est exécutée, soit aucune d’entre elles n’est exécutée. Cette propriété empêche la perte et la corruption de données si, par exemple, si votre source de données de streaming échoue à mi-chemin.
• Cohérence: Garantit que les transactions ne modifient les tables que de manière prédéfinie et prévisible. La cohérence transactionnelle garantit que la corruption ou les erreurs dans vos données ne créent pas de conséquences inattendues pour l’intégrité de votre table.
• Isolation: Lorsque plusieurs utilisateurs lisent et écrivent à partir de la même table en même temps, l’isolement de leurs transactions garantit que les transactions simultanées n’interfèrent pas ou n’affectent pas les unes les autres. Chaque demande peut se produire comme si elles se produisaient une par une, même si elles se produisent en réalité simultanément.
• Durabilité: Garantit que les modifications apportées à vos données par des transactions exécutées avec succès seront enregistrées, même en cas de défaillance du système.

ACID est logique dans la mesure où chaque système a sa propre base de données et tout se trouve dans un seul module de codes. Cependant, dans les architectures basées sur des microservices, nous avons plusieurs modules faiblement couplés où chacun a sa propre base de données, transaction et, bien sûr, ACID, mais ils sont connectés. Il existe encore des scénarios impliquant plusieurs microservices, et l’achèvement du scénario dépend de l’achèvement des tâches de chacun de ces microservices. Idéalement, tous les microservices effectuent correctement leurs tâches ; mais si un microservice échoue, tout le scénario doit échouer. Conceptuellement, nous devons avoir une transaction générale entre plusieurs microservices indépendants.

Pour une meilleure compréhension, examinons un scénario du monde réel. Ce scénario est un système de commande standard basé sur des microservices qui contient les microservices suivants :

1- Service de commande, qui est chargé d’enregistrer la commande d’un client.

2- Service de paiement, qui est chargé de donner l’argent de la commande d’un client.

3- Service de restauration, lequel est responsable de la préparation des commandes clients.

4- Service de livraison, qui met les commandes dans la file d’attente de livraison.

Supposons que dans ce scénario simple, le client enregistre une commande de nourriture via le Service de commande afin que ce microservice reçoive les informations de commande du client et les stocke dans sa propre base de données. L’étape suivante est le processus de paiement, qui est effectué par Service de paiement. Ce microservice reçoit les informations de carte des clients et paie. Si tout était correct et que le paiement a été effectué, la commande du client peut être complète ; mais que se passe-t-il s’il n’y a pas assez d’argent sur la carte du client ou si la passerelle de paiement est coupée ? Nous avons un paiement infructueux, mais toujours une commande en attente dans Service de commande. Nous aurions besoin de trouver un moyen d’annuler ce paiement en attente dans Service de commande base de données. Pour faire simple, nous avons besoin d’une transaction entre les microservices.

Transactions distribuées

Il existe plusieurs façons de gérer les transactions dans une architecture basée sur des microservices, la plus importante étant les transactions distribuées. Une transaction distribuée est basée sur des opérations sur des données effectuées sur plusieurs bases de données. Les transactions distribuées peuvent être gérées de deux manières : premièrement, coordonnées entre plusieurs nœuds distincts connectés via un réseau général ; et deuxièmement, avec un seul serveur qui contient plusieurs bases de données.

Engagement en deux phases

Un commit en deux phases (2PC) est le protocole le plus connu des transactions distribuées. Lors de la mise en œuvre de ce protocole, nous supposons qu’un processus fonctionnera en tant que coordinateur et le reste en tant que cohortes (le coordinateur peut être celui qui a initié la transaction, mais ce n’est pas nécessaire). Nous supposons en outre qu’il existe un stockage stable et un journal d’écriture anticipée sur chaque site. De plus, nous supposons qu’aucune machine impliquée ne plante pour toujours. Le protocole fonctionne comme suit (le coordinateur est prêt à s’engager et doit s’assurer que tout le monde le fera également) :

La validation en deux phases et les protocoles similaires ne sont pas de bonnes options pour les transactions dans une architecture basée sur des microservices pour plusieurs raisons. La raison la plus importante est qu’un nœud est responsable de la coordination des transactions entre les autres nœuds. De toute évidence, il existe un point de défaillance unique, et si un problème survenait pour le nœud coordinateur, l’ensemble du système de gestion des transactions serait en difficulté. Le deuxième problème important est que le temps de réponse du système de transaction dépend du temps de réponse du nœud le plus lent. En outre, les éléments suivants peuvent être mentionnés comme d’autres problèmes de 2PC :

• Il y a au moins O(4n) en plus des tentatives est O(n^2)
• Réduit le débit en raison des verrous
• Non pris en charge par de nombreux NoSQL ou même des courtiers de messages (jusqu’à présent)
• Impacts ‘Disponibilité’ dans le théorème CAP

SAGA

Le modèle SAGA a été présenté pour la première fois au monde en 1987 par Hector Garcia-Molina et Kenneth Salem dans un article intitulé SAGAS. L’idée sous-jacente est assez simple et basée sur la séquence de transactions qui peuvent être entrelacées avec d’autres transactions. Généralement, les architectures basées sur des microservices se composent de services plus petits et chaque service a sa propre transaction. SAGA fournit les mécanismes pour entrelacer ces petites transactions les unes avec les autres. Le modèle d’architecture de SAGA gère les transactions générales à l’aide d’une séquence de transactions locales. Chaque transaction locale participe à SAGA en tant qu’unité de travail unique et indépendante. Le point clé est que SAGA garantit que toutes les opérations sont terminées avec succès ou que tous les participants doivent être ramenés à leur transaction locale. Dans les systèmes classiques et basés sur SGBDR, la validation et l’annulation des transactions sont effectuées automatiquement. Cependant, dans SAGA, la situation est différente et chaque unité de l’écosystème SAGA doit gérer, s’engager et annuler par elle-même. En fait, chaque microservice qui a été impliqué dans l’écosystème SAGA devrait exposer deux services principaux : d’abord, un service qui représente la fonctionnalité principale avec laquelle le microservice veut participer ; et deuxièmement, le service de restauration qui annule ce premier changement de service dans la base de données locale, qui est appelé service de compensation. Par exemple, dans OrderService, le service principal est CREATE ORDER et le service de compensation est CANCEL ORDER. Chaque transaction basée sur SAGA consiste en n transaction et n compensation. Ce système de commande a été considéré comme une étude de cas dans cet article. Comme vous pouvez le voir sur l’image ci-dessous, nous avons quatre microservices, nous avons donc un service de quatre compensations en plus de quatre transactions principales.

supposition 1 : pour n>0 si T(n+1) échoue alors tous les T(1)..T(n) doivent l’être => Tous les C(1)..C(n) doivent être appelés.

supposition 2: le service d’indemnisation doit être idempotent et ne peut pas avorter, il doit être retenté jusqu’à ce qu’il soit réussi.

Stratégie de mise en œuvre de SAGA

SAGA est régulièrement mis en œuvre de deux manières :

SAGA basée sur l’orchestration

Dans cette approche, nous avons un composant coordinateur qui peut même être un microservice participant ou un composant indépendant. En effet, un orchestrateur (objet) indique aux participants quelles transactions locales exécuter. Supposons ce scénario :

1. Le service de commande reçoit le poster/commander demande et crée une commande via l’orchestrateur SAGA.
2. L’orchestrateur SAGA crée un Ordre dans le EN ATTENDANT Etat.
3. Il envoie ensuite une commande au SERVICE DE PAIEMENT.
4. Les SERVICE DE PAIEMENT tente de payer le montant de la commande via la passerelle de paiement.
5. Si le paiement réussit ou échoue, un message de réponse est renvoyé indiquant le résultat.
6. L’orchestrateur SAGA approuve ou rejette la Commande avec la réponse de SERVICE DE COMMANDE.
7. Si le résultat de l’étape 6 est un succès, le coordinateur dit SERVICE DE RESTAURATION pour commencer sa transaction et dit SERVICE DE COMMANDE pour changer le Commander statut à PAYÉ.
8. Si le résultat de l’étape 6 est un échec, le coordinateur dit SERVICE DE COMMANDE pour changer le Commander statut à PAYÉ.

Cette approche, comme vous pouvez le deviner, a un problème célèbre dont nous avons tous peur : le point de défaillance unique. Si le coordinateur échoue, tous les écosystèmes échoueront.

SAGA basée sur la chorégraphie

Contrairement à l’approche précédente, dans ce protocole, il n’y a pas un seul point de défaillance. Dans SAGA basé sur la chorégraphie, chaque transaction locale publie des événements de domaine qui déclenchent des transactions locales dans d’autres services.

Saga pratique basée sur une chorégraphie avec une hypothèse simplificatrice

La mise en œuvre idéale de SAGA est un protocole basé sur la chorégraphie. Cette approche s’appuie sur des courtiers de messages et des gestionnaires d’événements pour obtenir le résultat souhaité. Le gestionnaire d’événements que nous avons utilisé est Apache Kafka. Apache Kafka est une plate-forme de diffusion et de gestion d’événements open source distribuée qui est utilisée par de nombreuses entreprises ainsi que par des architectures logicielles. Kafka a été initialement conçu comme une file d’attente de messagerie et est basé sur une abstraction d’un journal de validation distribué. Depuis sa création et son open source par LinkedIn en 2011, Kafka est rapidement passé d’une file d’attente de messagerie à une plate-forme de streaming d’événements à part entière. La structure de données la plus importante dans Kafka est sujet. Tout simplement, sujet peut être considéré comme une file d’événements que tout le monde dans le rôle de consommateur peut écouter afin de notifier de nouveaux événements, ou peut mettre un nouvel événement dans le sujet en tant que producteur.

Faisons une simulation ou une étude de cas avec la chorégraphie et le but de Kafka.

Simplifier assumption: Dans cette partie, nous supposons que nous n’avons que deux microservices : Service de commande et Service de paiement.

Hypothèse: Il existe un objet Commande client avec trois statuts possibles : EN ATTENTE, PAYÉ ou ÉCHEC.

1. Le client envoie sa commande à Service de commande.
2. Service de commande place la commande dans le sujet (PendingOrderTopic) après avoir traité la commande et défini son statut sur PENDING. Immédiatement après cela, le service de paiement qui écoute ce sujet a reçu cette commande et essaie de payer via les passerelles de paiement comme PayPal.
3. Si le paiement est réussi, l’état de la commande est mis à PAYÉ et envoyé au restaurant pour préparer la commande.
4. Cependant, si le paiement échoue pour une raison quelconque, l’état de la commande passe à ÉCHEC et est placé dans le sujet avec le nom (FailedPaymentTopic). Enfin, le OrderService qui écoute ce topic reçoit cet événement et en informe le client.

Invariant

Le principal invariant de cohérence dans notre étude de cas est à chaque fois que nous avons une commande réussie, si et seulement si =>somme(commande.montant)<= client.crédit, et vous ne pouvez trouver aucun chemin dans le système pour le violer.

Saga a tendance à être ACD dans certains cas

Basé sur SAGA…