Gestion des transactions sous l'architecture de microservice Spring Cloud

Avec l'expansion continue des activités des entreprises, une seule application est souvent incapable de gérer un traitement commercial à grande échelle. L'architecture des microservices est une solution apparue au fil du temps. Elle divise un grand système d'application en plusieurs petites unités de service, et chaque unité de service peut être développée, déployée, exploitée, entretenue et mise à niveau indépendamment. Cette architecture peut grandement améliorer la flexibilité et l'évolutivité des applications, tout en réduisant le couplage entre les développeurs et en accélérant le développement et l'itération des applications.

Dans l'architecture des microservices, une requête métier doit appeler plusieurs unités de service pour être complétée, ce qui soulève un problème très important : la gestion des transactions. Car si une demande métier implique plusieurs unités de service, il faut s'assurer que ces unités de service peuvent être sous la même gestion des transactions, soit soumises ensemble, soit restaurées ensemble, afin de garantir la cohérence des données. Sinon, divers problèmes surviendront, tels que des soumissions répétées, des données incohérentes, etc.

Sous l'architecture de microservices Spring Cloud, il existe généralement trois manières d'effectuer la gestion des transactions distribuées :

1. Écrire du code de gestion des transactions local
2. Utiliser le mécanisme de transaction du middleware de messages
3. Solutions basées sur le cadre de gestion des transactions distribuées

Ci-dessous, je présenterai et comparerai respectivement ces trois solutions afin de choisir la solution la plus appropriée pour traiter les problèmes de gestion de transactions distribuées.

1. Écrire le code de gestion des transactions locales

L'idée de cette solution est la suivante : chaque unité de service maintient un gestionnaire de transactions local en interne Lorsqu'une unité de service doit effectuer des opérations de données, elle ouvre d'abord la transaction, effectue des opérations de données, puis validez ou annulez la transaction.

Par exemple : si le système de commande doit appeler le système de compte pour effectuer une opération de transfert, alors le système de commande insérera soit les données de commande directement dans sa propre base de données, soit les données de commande dans le contexte du gestionnaire de transactions local. de la commande. Ensuite, le système de commande appelle le service de transfert du système de compte pour effectuer l'opération de transfert. Le gestionnaire de transactions local doit également être activé au sein du service de transfert pour garantir l'atomicité et la cohérence de l'opération. Enfin, si tout se passe bien, le système de commande peut valider la transaction, sinon il annule la transaction.

L'avantage de cette solution est qu'elle est simple et facile à comprendre. Elle n'a pas besoin de s'appuyer sur des composants supplémentaires et peut être implémentée directement à l'aide de l'annotation @Transactional fournie par Spring. L’inconvénient est qu’il nécessite l’écriture manuelle du code de gestion des transactions et n’est pas assez flexible. De plus, si les opérations commerciales nécessitent de faire appel à plusieurs systèmes de services tiers, la mise en œuvre de cette solution sera très compliquée.

2. Utiliser le mécanisme de transaction du middleware de messages

L'idée de​​cette solution est d'utiliser les caractéristiques de la file d'attente de messages pour réaliser la gestion des transactions. Lorsqu'une demande métier doit appeler plusieurs unités de service, elle place d'abord la demande dans la file d'attente des messages, puis chaque unité de service obtient la demande de la file d'attente des messages et la traite. Si la file d'attente de messages prend en charge les fonctionnalités transactionnelles, ces opérations de traitement seront alors dans la même transaction, soit soumises ensemble, soit annulées ensemble.

Par exemple : Si le système de commande doit appeler le système logistique pour les opérations d'expédition, alors le système de commande publiera un message « demande d'expédition » dans la file d'attente des messages. Le système logistique doit également s'abonner à ce message. Après réception du message, il effectuera l'opération d'expédition une fois l'opération réussie, la transaction sera soumise, sinon la transaction sera annulée. Si le système de commande doit également exploiter sa propre base de données locale, il doit également participer à la transaction de file d'attente de messages.

L'avantage de cette solution est qu'elle permet d'éviter l'écriture manuelle du code de gestion des transactions et peut garantir la cohérence et l'atomicité des transactions. L'inconvénient est qu'il doit s'appuyer sur la file d'attente des messages. La configuration et la maintenance de la file d'attente des messages seront plus compliquées, et si l'échelle du système est grande, le débit et le retard de la file d'attente des messages deviendront un goulot d'étranglement.

3. Solution basée sur un cadre de gestion de transactions distribuées

L'idée de cette solution est d'utiliser un cadre de gestion de transactions distribuées tiers pour mettre en œuvre la gestion des transactions. Par exemple, les transactions distribuées entre services peuvent être facilement mises en œuvre à l'aide du framework Seata d'Alibaba.

Par exemple : si le système de commande doit appeler le système de compte pour les opérations de transfert, le système de commande peut alors appeler le service de transaction distribuée fourni par le framework Seata pour créer une transaction distribuée. Ensuite, le système de commande et le système de compte peuvent participer à la gestion de cette transaction distribuée, effectuer des opérations de données, puis soumettre ou annuler la transaction ensemble. Lorsque vous utilisez le framework Seata, vous devez définir la configuration correspondante dans chaque unité de service. Cette configuration comprend des paramètres liés aux sources de données et aux transactions distribuées.

L'avantage de cette solution est qu'elle utilise un cadre de gestion des transactions distribuées mature, qui peut éviter au maximum les problèmes de gestion des transactions et a une forte évolutivité. L'inconvénient est que des ajustements supplémentaires de configuration et de code sont nécessaires, et la complexité de gestion augmentera lorsqu'il existe de nombreuses unités de service et processus métier.

Les trois solutions ci-dessus ont chacune leurs propres avantages et inconvénients. Vous devez choisir la solution la plus adaptée en fonction des besoins de l'entreprise et de la conception du système. Bien entendu, dans les projets réels, vous pouvez rencontrer des situations plus particulières qui doivent être gérées avec flexibilité.

Pour l'architecture de microservices Spring Cloud, la gestion des transactions est un problème qui doit être pris en compte. Si les transactions ne sont pas gérées correctement, cela entraînera de grands dangers cachés pour l'entreprise. Par conséquent, lors de la conception et du développement de l'architecture, il est nécessaire de suivre strictement les principes et les meilleures pratiques de gestion des transactions distribuées et de réduire autant que possible la complexité de la gestion des transactions distribuées pour garantir la fiabilité et la stabilité de l'application.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!