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?


10

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?


6
les bases de données sont gratuites
Ewan

L'un des objectifs des microservices, entre autres, est de fournir une mise à l'échelle au-delà d'une architecture monolithique. Bien sûr, si votre application n'a même pas l'échelle requise, vous pouvez vérifier vos autres exigences pour voir s'il vaut la peine d'investir dans des microservices. De plus, rien ne vous empêche de "docker" tout ou partie de votre micro service sur une même machine physique si vous n'avez pas l'argent pour les scinder.
Walfrat

Les services peuvent facilement partager une base de données tout en restant isolés: il suffit de donner à chaque service son propre utilisateur de base de données avec accès à ses tables mais pas aux tables d'autres services.
Rétablir Monica

Pourquoi avez-vous besoin de plusieurs modules de code? Vous pouvez simplement mettre tout le code dans une grande classe de spaghetti! C'est moins de travail !!! (L'inconvénient, bien sûr, est que la gestion du changement devient un énorme problème.)
John Wu

@ Solomonoff'sSecret qui ne suffit pas à lui seul pour isoler vos services. Un de ces «utilisateurs» pourrait toujours exécuter une requête de fuite qui ralentit ou supprime tout. C'est toujours un seul point d'échec. Vous ne les avez que logiquement isolés.
RubberDuck

Réponses:


15

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.

La partie la plus difficile des microservices: vos données


2
Dans certains environnements, votre stockage n'est de toute façon qu'un autre microservice ...
svidgen

2
Vous en avez vraiment besoin. Un avantage majeur des microservices est de pouvoir avoir une isolation complète de tout. Une équipe peut décider un jour de passer d'une pile Microsoft complète à LAMP, sans même demander conseil à d'autres équipes. Si la même base de données est partagée, vous n'êtes plus libre. L'équipe A souhaite passer de SQL Server 2012 à SQL Server 2016, mais l'équipe B ne peut pas, car elle utilise une fonctionnalité qui a été supprimée de la version la plus récente. Malheureusement, cela n'est pas limité aux versions; tout ce que deux équipes ont en commun peut entraîner un conflit.
Arseni Mourzenko du

@ArseniMourzenko Je comprends que les microservices doivent être indépendants de la plate-forme et couplés uniquement par des contrats de service, mais il n'est pas impossible de fractionner une base de données partagée par plusieurs services si vous avez un plan de migration solide. Dans mon rôle précédent, j'étais celui qui plaidait pour des bases de données distinctes pour notre application de soins de santé à locataires multiples, mais la direction a choisi un modèle partagé en raison de problèmes de coûts. Je suis toujours frustré par cela plus d'un an plus tard.
Dan Wilson

Je n'ai pas vu non plus d'organisation qui permette aux équipes d'utiliser des plateformes très différentes (par exemple .NET vs LAMP). Une telle décision voyou serait abattue assez rapidement par crainte que certains services ne se retrouvent dans des silos et ne puissent être maintenus que par une seule équipe.
Dan Wilson

@DanWilson: il est bien sûr possible de diviser une base de données ultérieurement. Le problème est que lorsque vous commencez avec une base de données partagée, le fractionnement devient un choix difficile. Exemple de base: vous souhaitez une fonctionnalité de la prochaine version de la base de données; l'autre équipe ne peut pas encore migrer. Dans la plupart des cas, vous ne diviserez pas (trop difficile), mais préférez ne pas utiliser la nouvelle fonctionnalité, ce qui est regrettable.
Arseni Mourzenko du

4

Comme Dan Wilson répond, vous n'en avez pas vraiment besoin. Les microservices sont la nouvelle nouveauté, et comme toutes les nouvelles nouveautés, les gens les utilisent dans de nombreux endroits, même lorsqu'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 hors de 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 DB 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 être diligent 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 amène 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 si cher - surtout lorsque vous le comparez au temps / salaire consacré à essayer d'imposer des limites de données dans une base de données partagée.


génial. Je suppose que si nous ne sommes pas de la taille d'Amazon ou d'Uber, nous devons simplement l'éviter.
Affichage des questions

1
@PostingQuestions - pourquoi pensez-vous cela?
Telastyn

Nous faisons des projets mais ne pensons pas que nous en avons besoin.
Affichage des questions

1

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? Vous souciez-vous même de cela; en d'autres termes, ces choix technologiques affectent-ils la façon dont vous utilisez ces services? ... Et surtout, 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 au minimum pour réduire le risque d'attaques.

  • Le service 1 nécessite 15 To d'espace disque; la vitesse n'est pas importante, les disques durs ordinaires conviennent donc parfaitement. 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.

Alors 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, le déploiement de 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 qu'elles sont extrêmement gérables . 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 également à ce sujet), ce qui libère du temps pour les administrateurs système.

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 CPU, 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 pourrez en étendre autant que vous le souhaitez, sachant qu'ils ne consommeront pas plus de RAM que nécessaire. Bien que la consommation totale de mémoire soit plus élevée pour de nombreuses petites bases de données par rapport à une seule grande, je suppose que la différence ne sera pas trop importante. YMMV.


0

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 commerciale coûteux (pensez à Oracle) 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 qu'un service puisse posséder et contrôler ses données est d'avoir sa propre base de données «personnelle». Cela permet une totale liberté de choix de l'évolution de la technologie et du schéma de données. La seule façon dont un autre service peut 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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.