Modèle d'architecture: Distributed Saga

26/01/2018 | Tags: architecture

Les sagas distribuées sont un moyen de faire des “longues” transactions entre plusieurs services. Par exemple, la logique métier peux demander qu’une action soit le résultat de plusieurs services, et que si l’un d’entre eux échoue, il faut annuler les autres. Exactement comme dans une base de données, sauf qu’il s’agit de services sur le réseau.

Pour se faire il faut que chaque service soit idempotent et fournisse son opposé. Ensuite un coordinateur s’occupera de séquencer les services, et éventuellement si l’un d’eux échoue, de rejouer les opposés des services déjà passés. L’idempotence permet de gérer le fait que les requêtes peuvent être désordonnées dû au réseau.

Distributed Saga Guarantee

Les garanties d’une saga distribuée. Source: Caitie McCaffrey

Le fait de passer par un coordinateur permet d’éviter de gerer les erreurs directement dans chacun des services. Chaque service ne s’occupe que de son travail et le coordinateur est le seul à les connaître.

Isolation of Complex Code

Isolation du code complex. Source: Caitie McCaffrey

Le coordinateur se sert d’une séquence d’événements persistée dans lequel il note chaque étape du processus. S’il crashe, il peut être relancé à partir de la séquence existante et comme les services sont idempotent il a juste à résumer son processus. Dès qu’un service échoue, il inverse sa séquence et appelle les opposés de chacuns.

Saga coordinator

Le coordinateur de Saga. Source: Caitie McCaffrey

Sources

Je me suis basé uniquement et entièrement basé sur les excellents slides de Caitie McCaffrey. Il est indispensable de les consulter pour bien comprendre; c’est tellement visuel et bien fait, good job !

Caitie McCaffrey - Distributed Sagas: A Protocol for Coordinating Microservices