Gestion de la simultanéité du magasin de données en tant qu'échelle de microservices

Question

J'essaie toujours de trouver mon chemin dans les micro-services. J'ai une question fondamentale. Dans un scénario d'entreprise, les micro-services devraient probablement écrire dans un magasin de données permanent, qu'il s'agisse d'un SGBDR ou d'une sorte de NoSQL. Dans la plupart des cas, le magasin de données persistant est de niveau entreprise, mais une seule entité (bien entendu répliquée et sauvegardée). Considérons maintenant le cas d'un micro-service unique déployé dans un environnement de cloud public/privé disposant de son propre stockage de données persistant (par exemple un SGBDR de niveau entreprise). Au fur et à mesure que j'élèverai mon micro-service, il y aura plusieurs instances du micro-service essayant de lire/écrire à partir du même magasin de données. Un magasin de données traditionnel peut probablement être réglé pour gérer ~ 50-200 connexions simultanées. Comment puis-je gérer une situation où mes microservices doivent être mis à l'échelle bien au-delà?

Quelles sont les meilleures pratiques dans un tel scénario? Des motifs qui peuvent être utilisés?

Answer 1

Idéalement, chaque instance de microservice est autonome afin que chaque instance puisse évoluer indépendamment des autres tout en encapsulant son état de manière à ce que les autres utilisateurs n'y accèdent qu'à travers une API bien définie. Donc, non seulement vous avez besoin de comprendre comment mettre à l'échelle votre base de données que vos microservices utilisent pour stocker l'état, vous avez également ce problème d'encapsulation à résoudre si vous voulez vraiment clouer ce modèle architectural.

Avez-vous regardé Service Fabric pour résoudre ce problème? Service Fabric a un concept de stateful services où les données sont réellement stockées dans chaque instance de microservice. La plate-forme gère automatiquement la réplication et la persistance des disques pour la haute disponibilité et dispose également d'un partitionnement de données intégré pour la distribution entre machines. L'idée est essentiellement de laisser tomber la base de données centrale, au lieu de co-localiser votre calcul et vos données dans une instance de microservice. Désormais, vos services sont autonomes et la solution s'adapte parfaitement à ce modèle architectural, car chaque instance de microservice peut désormais être étendue et mise à niveau de manière indépendante et vous disposez d'une encapsulation complète de vos données dans le service. Le compromis est bien sûr que vous n'obtenez pas l'ensemble des fonctionnalités d'un SGBDR à part entière, mais si vous considérez les magasins NoSQL de toute façon, cela ne devrait pas être une grosse affaire. Ma pensée à ce sujet a toujours été qu'un magasin central comme une base de données est quelque peu un anti-modèle dans une architecture de microservices partagé-rien. La divulgation complète cependant: Je travaille sur Service Fabric, donc mon opinion peut être un peu biaisée!