L’approche microservice permet de séparer les domaines de responsabilité afin de faciliter l’évolution et la mise à l’échelle de chaque brique. L’inconvénient majeur de cette approche est la perte de la cohérence globale des données qu’apporte les transactions ACID dans un contexte monolithique.
Le pattern « Orchestrator » tente de répondre à ce problème à l’aide de transactions ACID locales à chaque microservice, de notifications entre microservice par message ou évènement et de transactions de compensations en cas de défaillance d’un service dans la saga.
Selon l’implémentation, d’autres transactions peuvent accompagner ces transactions de compensations :
Un pivot peut par exemple être la validation d’une commande suite à la réservation d’un stock et du débit du moyen de paiement. L’envoi du mail de confirmation est alors une transaction renouvelable qui pourra être répéter sans influence sur l’état de validation de la commande.
Le pattern « Orchestrator » repose sur un contrôleur responsable de coordonner et de garantir la réalisation cohérente de la saga. Il invoque les microservices participants à la saga au fur et à mesure de l’avancement, interprète les résultats, et déclenche des opérations de compensation en cas de défaillance.
Figure 5 – Exemple de mise en place d’un orchestrateur
Dans le cadre d’un projet de refonte d’un SI par palier fonctionnel avec une cible microservice, l’analyse de l’existant, avec un nombre de domaines métiers important et interconnecté, nous avons mis en place ce pattern. L’objectif est de centraliser les transactions des chaînes de traitement afin d’avoir un élément ayant la vision sur l’ensemble de la chaîne afin de garantir le traitement ou l’annulation correcte, et d’avoir une remontée simplifiée du microservice provoquant l’erreur ou bloquant un processus. Le fonctionnement est robuste et a permis dès la mise en place de garantir le bon déroulement des processus. Cependant, le coût de mise en place est fixe, et peut représenter un investissement trop grand si le projet n’atteint pas un nombre minimum de microservice. Dans notre cas, la mise en place de ce pattern a induit un coût non négligeable par rapport à l’état courant du projet. En revanche, il va permettre une augmentation significative du nombre de microservices à l’avenir. Il faut donc décider au cas par cas si cette mise en place est rentable.