Comment annuler des microservices
J'ai des doutes liées à des microservices. Supposons que 5 micro-services permettent de dire M1, M2, M3, M3, M4 et M5. Il existe 4 bases de données connectées/consultées par 4 micro-services. Exemple, M2 connecté à MySQL, M3 connecté à Cassandra, M4 connecté à MANGODB et M5 connecté à Oracle.
Maintenant
Étape 1: M1 Passer un appel à M2 pour mettre à jour certaines données de l'utilisateur dans MySQL et mise à jour avec succès, alors il a finalement eu la réponse du succès de M2
Étape-2: M1 Passer un appel à M3 pour mettre à jour certaines données dans Cassandra et il a mis à jour avec succès, enfin, il a finalement eu la réponse du succès de M3
Étape 3: M1 Établir un appel à M4 pour mettre à jour certaines données dans MANGODB et échoué en raison d'un problème de serveur DB ou d'un autre problème.
Ici, mes besoins sont, je souhaite Rollback DB modifications qui arrivaient à des micro-services précédents (M2 et M3)
Que devons-nous faire pour atteindre ce type de scénario de restauration?
pour répondre à votre question, ajoutons des exigences commerciales
Cas 1. M1 fait toutes les interactions avec d'autres microservices basé sur un événement reçu comme la commande passée
Maintenant, dans ce cas, M2 ... M5 Mise à jour,
Exigence 1: Si tous sont indépendants les uns des autres.
d'abord créer 5 événement d'un événement puis
dans un tel cas, vous pouvez ajouter cet événement dans une table de table Cet événement comme non traité et une minuterie lit un événement non transformé et tente de faire toutes les tâches de manière idempotente, vous pourriez également avoir des rapports si ces tâches échouent et que votre équipe puisse vérifier les résoudre manuellement.
(Vous pouvez implémenter une logique similaire en utilisant une file d'attente de basculement - qui envoie le même événement à la file d'attente d'origine après un certain temps)
Exigence 2: Si tous ne sont pas indépendants
utilisez un seul événement et toujours la même solution.
dans la solution ci-dessus, le principal avantage est même si votre système redémarre entre les transactions que vous allez toujours avoir le système cohérent
Cas 2 Si l'API M1 est invoquée et M1 doit faire toutes les tâches de plusieurs microservices, puis donner une réponse à l'utilisateur.
nous pourrions créer un événement démarré dans M1 Microservice dB (sync_event_table) Essayez de faire la mise à jour de tous les microservices après tout Terminer, mettez à jour la table des événements de synchronisation terminée.
pour les cas qui ne sont pas terminés - exécutez une minuterie qui vérifie le travail qui ne sont pas terminés pour> x min, puis effectuent les actions annulaires ou tout ce qui est requis,.
Essence :
Donc, si vous voyez toutes les solutions suggère votre système pour transformer tout le diff. Mise à jour de microservice
en créant un emploi
vérification du statut de travail
écrire une fonction d'emploi annuler/redo
De ce que je comprends, A Saga est ce que vous recherchez. L'idée est de prévoir à chaque opération d'altération de l'état une opération d'annulation, qui doit être appelée si les choses se sont déroulées.
Vous pouvez vous assurer que vous avez activé @TransActional activé dans toute la séquence d'invocation.
- Pensez à une invocation de tous les microservices de M1 comme transaction unique.
- Exposez-en une annuelle de la manière suivante:
- Lors de la mise à jour de DB dans M2, M3 et M4, placez les valeurs dans le cache de printemps ainsi que la DB.
- Lors de l'invocation/de la restauration dans M2, M3 ou M4, obtenez les valeurs du cache de printemps et les annulez de DB.
- Dans la commande de FallbackMethod de Hysterix, lorsque M1 répond avec une erreur ou une sortie par défaut, invoquez/Rollback d'autres services.
Cela peut ne pas être une solution parfaite, car elle introduit un autre point de défaut comme/Rollback Maniping, mais le plus rapide qui puisse être mis en œuvre.