Si une architecture de microservice a besoin d'une base de données distincte par microservice, elle est trop coûteuse et ingérable. Pourquoi en avons-nous même besoin?
J'ai lu sur les microservices et il me semble illogique de créer une base de données distincte par service juste pour réaliser l'isolement. Je peux obtenir le même résultat en utilisant uniquement des services Web et une seule base de données. Pourquoi en avons-nous même besoin? La chose qui sépare la base de données est au-delà de toute discussion. Ou je me trompe carrément? Pouvez-vous me guider là-dessus?
Pourquoi en avons-nous même besoin?
Non.
La création d'une base de données distincte pour chaque service permet d'imposer les limites du domaine, mais ce n'est qu'une approche. Rien ne vous empêche de partager tous vos services avec la même base de données.
Tant que vos services se comportent et ne font rien d'inattendu aux données appartenant à d'autres services, tout ira bien.
Je ne sais pas ce que vous lisez, mais vous devez être conscient qu'il existe de nombreuses opinions divergentes sur l'architecture des microservices. Voici un bon article de blog sur le sujet.
J'ai vu des gens se référer à cette idée en partie, de manière triviale, car "chaque microservice devrait posséder et contrôler sa propre base de données et aucun service ne devrait partager une base de données". L'idée est bonne: ne partagez pas une seule base de données entre les services car vous rencontrez alors des conflits comme des modèles de lecture/écriture concurrents, des conflits de modèles de données, des problèmes de coordination, etc.
Mais une base de données unique nous offre beaucoup de sécurités et de commodités: transactions ACID, endroit unique à regarder, bien compris (un peu?), Un endroit à gérer, etc.
Le voyage vers les microservices n'est que cela: un voyage. Ce sera différent pour chaque entreprise. Il n'y a pas de règles strictes et rapides, seulement des compromis.
Comme Dan Wilson répond, vous n'en avez pas vraiment besoin. Les microservices sont la nouvelle chose chaude, et comme toutes les nouvelles choses chaudes, les gens les utilisent dans beaucoup d'endroits même quand ils n'apportent pas beaucoup de valeur.
Les microservices vous permettent de déployer et de faire évoluer indépendamment les choses à un niveau "micro". Cette granularité offre un tas d'avantages techniques et encore plus d'avantages non techniques car elle vous permet de mieux séparer les équipes de développement, de publier au besoin plutôt qu'une seule grande version, d'essayer de nouvelles technologies ou de nouveaux processus isolément, etc. Avoir une base de données partagée tue beaucoup à cause de la dépendance à la base de données. Si vous ne pouvez pas déployer votre service sans vous soucier des données des autres services, vous avez perdu.
La chose qui sépare la base de données est au-delà de toute discussion. Ou je me trompe carrément?
Cela dit, vous avez également tout à fait tort.
Lorsque vous travaillez dans le cloud, les bases de données sont bon marché. Libre généralement! Bien sûr, le serveur coûte de l'argent, mais nous ne parlons pas d'un serveur individuel par microservice (du moins, pas au début). Un serveur unique avec un tas de bases de données (logiques) est très bien tant que vous êtes diligent pour éviter les requêtes inter-bases de données (qui introduisent des dépendances qui nuisent "déployables et évolutives indépendamment"). Enfer, les requêtes croisées entre bases de données sont impossibles dans certains services de base de données cloud comme Azure SQL. Vous n'avez même pas besoin d'être diligent là-bas ...
Et j'ai même vu des microservices où ils partageaient une base de données, mais chaque service avait son propre schéma. Encore une fois, vous devez faire preuve de diligence pour éviter les requêtes qui dépassent les limites des données.
Beaucoup d'endroits ne sont pas si diligents. Ils ont des développeurs d'entrée de gamme, ou des gens qui n'apprécient pas l'approche du microservice, ou qui ont de mauvais chefs d'équipe, ou qui ont une pression temporelle qui pousse les gens à prendre des raccourcis.
Avoir une base de données distincte est le moyen le plus propre d'imposer ce découplage qui permet l'indépendance du service, mais ce n'est pas le seul moyen. Et ce n'est pas que cher - surtout lorsque vous le comparez au temps/salaire passé à essayer d'imposer des limites de données dans une base de données partagée.
Pourquoi en avons-nous même besoin?
L'énorme avantage des microservices - et plus largement, SOA - est le niveau élevé d'abstraction des composants internes - non seulement la mise en œuvre, mais aussi les technologies utilisées. Par exemple, si un système est développé sous la forme de cinq microservices par cinq équipes, une équipe peut décider de passer à une pile technologique complètement différente (par exemple de la pile Microsoft à LAMP) sans même demander l'avis des autres équipes.
Regardez Amazon AWS ou Twilio. Savez-vous si leurs services sont implémentés en Java ou Ruby? Utilisent-ils Oracle ou PostgreSQL ou Cassandra ou MongoDB? Combien de machines utilisent-ils? Do vous vous souciez même de cela; en d'autres termes, ces choix technologiques affectent-ils la façon dont vous utilisez ces services? ... Et plus important encore, s'ils migrent vers une autre base de données, devrez-vous modifier votre application client en conséquence?
Maintenant, que se passe-t-il si deux services utilisent la même base de données? Voici une infime partie des problèmes qui peuvent survenir:
L'équipe de développement du service 1 souhaite passer de SQL Server 2012 à SQL Server 2016. Cependant, l'équipe 2 s'appuie sur une fonctionnalité obsolète qui a été supprimée dans SQL Server 2016.
Le service 1 est un énorme succès. L'hébergement de la base de données sur deux machines (maître et basculement) n'est plus une option. Mais la mise à l'échelle du cluster sur plusieurs machines nécessite des stratégies telles que le partage. Pendant ce temps, l'équipe 2 est satisfaite de l'échelle actuelle et ne voit aucune raison de passer à autre chose.
Le service 1 doit passer à UTF-8 comme codage par défaut. Le service 2, cependant, est content d'utiliser la page de code 1252 Windows Latin 1.
Le service 1 décide d'ajouter un utilisateur avec un nom spécifique. Cependant, cet utilisateur existe déjà, créé il y a quelques mois par la deuxième équipe.
Le service 1 a besoin de nombreuses fonctionnalités différentes. Le service 2 est un composant hautement critique et doit maintenir les fonctionnalités de la base de données à leur minimum pour réduire le risque d'attaques.
Le service 1 nécessite 15 TB d'espace disque; la vitesse n'est pas importante, donc les disques durs ordinaires sont parfaitement corrects. Le service 2 nécessite au maximum 50 Go, mais doit y accéder le plus rapidement possible, ce qui signifie que les données doivent être stockées sur un SSD.
...
Chaque petit choix affecte tout le monde. Chaque décision doit être prise en collaboration, par des personnes de chaque équipe. Des compromis doivent être faits. Comparez cela à une totale liberté de faire tout ce que vous voulez dans un contexte SOA.
c'est trop [...] ingérable.
Ensuite, vous vous trompez. Je suppose que vous déployez manuellement.
Ce n'est pas ainsi qu'il faut faire les choses. Vous devez automatiser le déploiement des machines virtuelles (ou conteneurs Docker) qui exécutent la base de données. Une fois que vous les avez automatisés, déployer deux serveurs ou vingt serveurs ou deux mille serveurs n'est pas très différent.
La chose magique à propos des bases de données isolées est que c'est extrêmement gérable. Avez-vous essayé de gérer une énorme base de données utilisée par des dizaines d'équipes? C'est un cauchemar. Chaque équipe a des demandes spécifiques, et dès que vous touchez quelque chose, cela affecte quelqu'un. Avec une base de données associée à une application, la portée devient très étroite, ce qui signifie qu'il y a beaucoup moins de choses à penser.
Si une énorme base de données nécessite des administrateurs système spécialisés, les bases de données qui sont utilisées par une seule équipe peuvent essentiellement être gérées par cette équipe (DevOps est aussi à ce sujet), libérant les administrateurs système '' temps.
c'est trop cher
Définissez le coût.
Les coûts de licence dépendent de la base de données. À l'ère du cloud computing, je suis presque sûr que tous les principaux acteurs ont repensé leurs licences pour s'adapter au contexte où, au lieu d'une énorme base de données, il y en a beaucoup de petites. Sinon, vous pouvez envisager de passer à une autre base de données. Soit dit en passant, il y en a beaucoup.
Si vous parlez de puissance de traitement, les machines virtuelles et les conteneurs sont compatibles avec le processeur, et je ne serais pas très affirmatif qu'une énorme base de données consommera moins de CPU que de nombreuses petites faisant le même travail.
Si votre problème est la mémoire, les machines virtuelles ne sont pas un bon choix pour vous. Les conteneurs sont. Vous serez en mesure d'en couvrir autant que vous le souhaitez, sachant qu'ils ne consommeront pas plus RAM que nécessaire. Alors que la consommation totale de mémoire sera plus élevée pour de nombreuses petites bases de données par rapport à un grande seule, je suppose que la différence ne sera pas trop importante.
Dépend de ce que vous considérez comme "cher".
Une base de données ne doit pas nécessairement être un serveur de base de données commercial coûteux (pensez Oracle), elle ne doit pas nécessairement être une affaire de ressources. Selon vos besoins, vous pouvez utiliser la base de données SQLite ou même le système de fichiers comme stockage de données persistant.
Tous ces services peuvent également partager une seule instance/serveur de base de données et ne disposer que de schémas isolés par service.
L'argument clé ici est que le service doit posséder et contrôler ses données. Comment y parvenir, est une question de choix et de détails techniques.
La meilleure façon pour un service de posséder et de contrôler ses données est d'avoir sa propre base de données "personnelle". Cela permet une liberté totale de choix de l'évolution de la technologie et du schéma de données. La seule façon pour tout autre service d'accéder aux données appartenant à un service est de demander les données d'un service. De cette façon, si la représentation des données internes doit être modifiée, elle peut être facilement modifiée et aucun autre service ne se cassera.
Donc, pour récapituler. Il n'est pas nécessairement coûteux d'avoir une base de données par service et ce n'est pas nécessaire. C'est simplement une décision que vous devez prendre à un moment donné lors du développement de microservices. Chacun des choix a ses implications et ses limites. Étudiez-les et faites votre propre choix.