Lors de la conception de l'interaction entre microservices, la question de la mise en œuvre des transactions distribuées se pose souvent. Dans les monolithes, les outils de contrôle sont suffisants grâce aux mécanismes intégrés, mais dans les microservices, la situation se complique en raison des différentes bases de données, technologies, formats d'échange de données. La règle principale est d'éviter les longues transactions distribuées, car elles sont mal évolutives et portent le risque de dégrader les performances.
Au lieu des protocoles ACID classiques, il est recommandé d'utiliser le modèle SAGA. Il s'agit d'une chaîne de transactions locales, où chaque microservice enregistre ses modifications et, en cas de besoin de rollback, envoie une opération compensatoire dans le cadre de sa responsabilité.
Exemple d'implémentation simplifiée de la gestion de saga en Node.js avec REST :
// Saga orchestrator avec Express app.post('/saga', async (req, res) => { try { await serviceA.transaction(); await serviceB.transaction(); res.send('ok'); } catch (err) { await serviceA.rollback(); res.status(500).send('rollback performed'); } });
Caractéristiques clés :
Peut-on utiliser des commits en deux phases classiques (2PC) entre microservices pour soutenir les transactions ?
Oui, mais ce n'est pas recommandé pour les architectures de microservices. 2PC freine l'évolutivité et lie les services technologiquement et organisationnellement.
Tous les scénarios SAGA conviennent-ils pour les opérations financières ?
Non. SAGA est plus difficile à implémenter correctement pour des scénarios où la rigueur ACID est critique, par exemple, le recalcul des soldes sur un même compte. Il est donc important d'évaluer les risques et de choisir un compromis.
Comment se passe le traitement d'un échec d'étape intermédiaire, si un microservice ne peut pas faire de rollback ?
Dans de tels cas, il est nécessaire de mettre en œuvre un protocole de compensation manuel ou automatisé, éventuellement à l'aide d'un journal d'événements distinct.