Dans microservice, s'agit-il d'une base de données unique ou d'une instance de base de données unique pour chaque service?

Je comprends qu'un service dans une architecture de microservice devrait avoir sa propre base de données. Cependant, avoir sa propre base de données signifie-t-il simplement avoir simplement une autre base de données dans la même instance de base de données ou avoir littéralement une autre instance de base de données?

Par cela, je ne parle pas de partage de bases de données, ce qui est un non-non, mais plutôt de l'instance de base de données.

Par exemple, si j'utilisais AWS et disposais de 3 services, est-ce que je crée 3 bases de données pour chaque service sur une seule instance RDS ou est-ce que je crée 3 instances RDS contenant chacune une base de données utilisée indépendamment par chacun des 3 services?

Si l’utilisation de plusieurs bases de données sur une même instance RDS est une meilleure idée, est-ce que cela va à l’encontre du but de disposer de services indépendants, pour les raisons suivantes:

1. La ressource de l'instance RDS sera partagée entre les services. Le service A, qui peut avoir une utilisation intensive de la base de données à une heure donnée, aura-t-il un impact sur le service B qui utilise une base de données différente mais sur la même instance RDS?

2. Tous les services dépendront de la version de la base de données sur cette instance RDS.

Cela dépend vraiment de vos exigences en matière d'évolutivité et de la manière dont vos instances de microservice doivent coopérer pour fournir un résultat unique. Cela aide de savoir quels sont les compromis:

Tout garder dans une base de données

• Configuration plus facile
• Aucune coordination ou communication avec d'autres instances de votre service n'est nécessaire
• Plus facile de découvrir votre ensemble de données complet
• Performances système limitées par les performances de la base de données

Garder les bases de données séparées

• La réponse complète à une demande peut être répartie sur plusieurs instances de microservice.
• Dans ce cas, vous avez augmenté la communication et la négociation pour résoudre la demande.
• Gestion des données lorsque vous perdez ce nœud de microservice (même lorsque la base de données est encore active, vous ne pouvez pas y accéder tant qu'un nouveau fichier contenant la bonne configuration n'a pas été reconstitué)
• Complexité de configuration accrue

Quel est le problème que vous résolvez?

Dans certains cas, vous ne vous inquiétez que des données éphémères. Si la base de données tombe en panne, ce n'est pas un gros problème. Dans ces cas, vous n’avez peut-être même pas besoin d’une base de données pour commencer. Il suffit de tout garder en mémoire et d’accélérer les choses. C'est la solution la plus simple à utiliser.

Dans d'autres cas, vous avez besoin de l'intégrité des données, mais votre base de données est capable d'augmenter sa capacité en fonction du nombre de nœuds dont elle dispose. Dans ce cas, une seule base de données est probablement plus que suffisante, et gérer sa réactivité de manière indépendante est la bonne réponse.

Il y a un certain nombre de cas entre les deux. Par exemple, vous pouvez avoir des bases de données spécifiques à une région. Ainsi, pour chaque instance de votre service dans une région différente, vous disposez d'une base de données distincte. Le partage de bases de données ne fonctionne généralement pas bien d'une région à l'autre. Il s'agit donc d'un moyen de localiser un peu les données et de contrôler vous-même la coordination.

Doctrine et réalité

J'ai lu un certain nombre d'articles sur les microservices et sur leur caractère modulaire. Les recommandations vont de conserver le niveau frontal, le microservice et le niveau de données dans son ensemble au partage de la base de données et / ou du code frontal pour toutes les instances. Généralement, plus l'isolement est important, plus elle est évolutive, mais au prix d'une complexité accrue.

Si votre microservice est lourd en calculs, il est logique d'autoriser le nombre de ces microservices à adapter - le partage de la base de données ou même du code frontal ne nuit ni ne nuit à cette approche.

La réalité est que les besoins spécifiques de votre projet nécessiteront un ensemble de compromis différent pour que le travail soit effectué à temps et pour gérer la charge système que vous mesurez (plus un peu plus). Considérez l'objectif ambitieux comme le trio de serveurs, de microsrervice et de données. Plus votre système est sollicité, plus vous devrez probablement vous rapprocher de cet objectif. Nous ne sommes pas tous [insert name of highly successful web entity here]et ils n'ont pas commencé là où ils sont maintenant. Parfois, il vous suffit de commencer avec une situation moins que parfaite et d'en être heureux.

Supposons que certains services puissent utiliser le même type de système et de version de base de données. Si vous utilisez des bases de données ou instances de base de données différentes, vous ne devriez pas avoir à prendre cette décision au moment de la conception. Au lieu de cela, vous devriez être capable de prendre la décision au moment du déploiement, quelque chose que vous pouvez simplement configurer. Concevez vos services de manière à rester agnostiques à l'endroit où les bases de données d'autres services sont hébergées.

Pendant le fonctionnement, vous pouvez commencer avec une instance et si le système fonctionne correctement, laissez-le ainsi. Toutefois, si vous remarquez que cela ne s'adapte pas correctement à votre système, car différentes bases de données d'une instance partagent trop de ressources, vous avez toujours la possibilité d'utiliser différentes instances, si cela vous aide.

Ainsi, un service ne viole pas l'architecture de microservice simplement parce que vous laissez deux d'entre eux partager une ressource. Il la viole lorsque le partage de la ressource devient obligatoire.

Ça n'a pas d'importance.

Le seul scénario où cela pourrait théoriquement compter est si un service doit migrer vers une version différente de la base de données. Mais même dans ce cas, il n'y a pas de réelle différence entre avoir des instances séparées dès le départ et migrer ce service d'une instance partagée vers une autre. En fait, je dirais qu'avoir des instances séparées uniquement à cause de ce scénario est un exemple de YAGNI.

Une instance RDS est une boîte unique. Si vous avez plusieurs bases de données sur une seule instance, elles partagent le processeur / la mémoire, etc.

Si vos performances de microservice sont liées aux performances de sa base de données : déployez alors plusieurs copies du microservice, chacune utilisant une base de données différente, mais avec chaque base de données sur la même instance RDS. Est inutile * (sauf pour le basculement). Votre cluster de microservices fonctionnera à la même vitesse qu'un seul microservice.

Cependant , je dirais qu’un microservice lié aux performances de la base de données est inhabituel.

Habituellement, votre microservice récupère les données d’une base de données, exécute une logique et écrit des informations dans la base de données. Le goulot d'étranglement des performances est la logique , pas la sélection et / ou l'insertion.

Dans ce cas, vous pouvez simplement partager la même base de données sur toutes vos instances de microservice.

L’objectif de garder une base de données privée pour un service est l’encapsulation. Votre microservice est une boîte noire que d'autres services du système utiliseront via une interface publique.

Cette encapsulation fonctionne sur deux plans:

• Le premier est logique, au niveau de l'application. Votre service possède des objets métier sur votre système et doit conserver un état persistant à propos de ces objets. Le fait que certains particuliers le dos de la base de données de ces objets métier est tout simplement détail de mise en œuvre. En conservant une base de données séparée, vous empêchez d'autres services d'accéder à votre implémentation par la porte dérobée, ce qui les oblige à utiliser votre interface publique. Le but ici est une architecture propre et une programmation disciplinée. L'emplacement exact de la base de données n'a pas d'importance à ce niveau, tant que votre service dispose des détails de connexion appropriés pour pouvoir le trouver.

• Le deuxième niveau est opérationnel. Même si votre conception est une boîte noire parfaite, comme vous l'avez souligné, différents travaux co-localisés sur une seule machine peuvent se disputer les ressources. C'est une bonne raison de placer des bases de données logiques distinctes sur des ordinateurs distincts. Comme d'autres réponses l'ont noté, si vos besoins ne sont pas très exigeants et votre budget serré, il s'agit d'un argument pragmatique en faveur de la colocation sur une seule machine. Cependant, comme toujours, compromis: cette configuration peut nécessiter davantage de gardiennage à mesure que votre système grandit. Si le budget le permet, je préfère presque toujours deux petites machines distinctes pour exécuter deux tâches plutôt que de partager une machine plus grande.

Je pense que cela pourrait aider d'être un peu plus théorique ici. L'une des idées qui motivent les microservices est le partage, rien du tout, des processus de transmission de messages. Un microservice est comme un acteur dans le modèle Acteur. Cela signifie que chaque processus conserve son propre état local et la seule façon pour un processus d'accéder à l'état d'un autre consiste à envoyer des messages (et même dans ce cas, l'autre processus peut répondre comme il l'entend à ces messages). Ce que l’on entend par "chaque microservice a sa propre base de données" est en réalité que l’état d’un processus (c’est-à-dire un microservice) est local et privé . Dans une large mesure, cela suggère que la "base de données" devrait être co-localiséeavec le microservice, c’est-à-dire que la "base de données" doit être stockée et exécutée sur le même noeud logique que le microservice. Les différentes "instances" du microservice sont des processus distincts et doivent donc avoir chacune leur propre "base de données".

Une base de données globale ou partagée entre plusieurs microservices ou même des instances d'un microservice constitueraient, de ce point de vue, un état partagé. La manière "appropriée" de gérer cela du point de vue des microservices consiste à faire en sorte que la base de données partagée soit transmise par un microservice "de base de données". Les autres microservices souhaitant connaître le contenu de la base de données enverraient des messages à ce "microservice de base de données". Cela n'élimine généralement pas la nécessité d'un état local (c'est-à-dire par "bases de données" par instance de microservice) pour les microservices d'origine! Ce qui change, c'est ce que représente cet état local. Au lieu de stocker "L'utilisateur Sally est un administrateur", il devrait stocker "Il y a cinq minutes, le microservice de base de données a déclaré:" L'utilisateur Sally est un administrateur ". En d'autres termes, sur l'état des autres microservices.

L'avantage de ceci est que chaque microservice est autonome. Cela fait d'un microservice une unité atomique d'échec. La plupart du temps, vous n'avez pas à vous soucier d'un microservice dans un état partiellement fonctionnel. Bien entendu, le problème a été déplacé vers le réseau de microservices. Un microservice peut ne pas être en mesure d’exécuter la fonction souhaitée en raison de son incapacité à contacter d’autres microservices. L'avantage, cependant, est que le microservice sera dans un état bien défini et pourra peut-être offrir un service dégradé ou limité, par exemple en utilisant des convictions obsolètes. L'inconvénient est qu'il est très difficile d'obtenir un instantané cohérent du système dans son ensemble, et il peut y avoir beaucoup de redondance et de duplication (non désirée).

Bien entendu, il n'est pas suggéré de coller une instance d'Oracle dans chaque conteneur Docker. Premièrement, tous les microservices n’ont pas besoin d’une "base de données". Certains processus n'ont besoin d'aucun état persistant pour fonctionner correctement. Par exemple, un microservice qui effectue la traduction entre deux protocoles n'a pas nécessairement besoin d'un état persistant. Pour quand l'état persistant est nécessaire, le mot "base de données" est juste un mot pour "état persistant". Il peut s’agir d’un fichier contenant JSON, d’une base de données SQLite ou d’une copie exécutée localement d’Oracle si vous le souhaitez, ou de tout autre moyen de stockage local.stocker de manière persistante des données. Si la "base de données" n'est pas locale, alors du point de vue des microservices purs, elle devrait être traitée comme un service (micro) séparé. À cette fin, il n’a aucun sens de faire d’une instance RDS la "base de données" d’un microservice. Encore une fois, la perspective n'est pas "un groupe de microservices avec leurs propres bases de données RDS" mais "un groupe de microservices qui communiquent avec des bases de données RDS". À ce stade, il est indifférent que les données soient stockées dans la même instance de base de données ou non.

De manière pragmatique, une architecture de microservices ajoute une énorme complexité. Cette complexité n’est que le prix à payer pour faire face sérieusement à un échec partiel. Pour beaucoup, c’est exagéré et cela ne vaut peut-être pas les avantages. Vous devriez vous sentir libre d'architecter votre système de la manière qui vous semble la plus bénéfique. Il est fort probable que des problèmes de simplicité et d'efficacité entraînent des écarts par rapport à une architecture de microservices pure. Le coût sera un couplage supplémentaire qui introduira ses propres complexités telles que des interactions invisibles entre services et des restrictions sur votre liberté de déploiement et d’échelle à votre guise.