Microservices et stockage de données
J'envisage de déplacer une API monolithique REST vers une architecture de microservice, et je suis un peu confus au sujet du stockage de données. À mon avis, certains des avantages des microservices seraient:
- Évolutivité horizontale - Je peux exécuter plusieurs copies redondantes d'un microservice pour faire face à la charge et/ou à la panne d'un serveur.
- Lâchement couplé - je peux changer les implémentations internes des microservices sans avoir à changer les autres, et je peux les déployer et les changer indépendamment, etc.
Mon problème est avec le stockage des données. Selon moi, il existe plusieurs options:
- Un service de base de données unique partagé par tous les microservices - cela semblerait éliminer complètement tout avantage d'un couplage lâche.
- Une instance de base de données installée localement sur chaque microservice - Je ne vois pas de moyen de faire évoluer horizontalement cela, donc je ne pense pas que ce serait une option.
- Chaque microservice possède son propre service de base de données - cela semble le plus prometteur, car il préserve les avantages du couplage lâche et de la mise à l'échelle horizontale (en utilisant des copies de base de données redondantes et/ou un partitionnement sur plusieurs)
Pour moi, la troisième option semble être la seule option, mais elle me semble incroyablement lourde, et une solution très ingénieuse. Si je comprends bien, alors pour une application simple avec 4-5 microservices, je devrais exécuter 16-20 serveurs - deux instances de microservice réelles par microservice (en cas de défaillance du serveur et pour un déploiement sans temps d'arrêt), et deux instances de service de base de données par microservice (en cas de panne du serveur etc ...).
Franchement, cela semble un peu ridicule. 16-20 serveurs pour exécuter une API simple, sachant qu'un projet réaliste aura probablement plus de 4-5 services? Y a-t-il un concept fondamental qui me manque qui expliquera cela?
Certaines choses qui peuvent aider à répondre:
- Je suis le seul développeur de ce projet et le serai dans un avenir prévisible.
- J'utilise Node.js et MongoDB, mais je serais intéressé par les réponses indépendantes de la langue - une réponse pourrait même être que j'utilise simplement les mauvaises technologies!
De vos trois options, la première (une seule base de données partagée) et la troisième (un "service de base de données") sont les plus courantes.
Le premier est appelé base de données d'intégration . Cela n'est généralement pas considéré comme une bonne solution dans une architecture de microservices. Il ajoute un couplage à vos services. Il est également très facile pour un service de contourner simplement les autres services et d'interroger directement dans une base de données. Vous pourriez perdre tout type d'intégrité ou de validation des données fourni par le niveau d'application non appliqué au niveau de la base de données.
Votre troisième idée s'appelle un base de données d'application . Et vous avez raison - cela vous permet d'appliquer le couplage lâche au niveau de l'API entre les services et vous permet de faire évoluer plus facilement les services au niveau de la base de données. Cela facilite également le remplacement de la technologie de base de données sous-jacente par quelque chose de approprié avec chaque service, tout comme vous pouvez modifier la technologie ou d'autres détails d'implémentation de chaque service. Très souple.
Cependant, je proposerais une solution intermédiaire.
Au lieu de créer un service de base de données pour chaque microservice, placez un schéma pour chaque service. Si vous utilisez plusieurs technologies de base de données, vous devrez peut-être diviser légèrement différemment, mais l'idée serait de minimiser le nombre de serveurs de base de données que vous utilisez, mais de faciliter la répartition d'un service en son propre serveur de base de données si et quand cela devient nécessaire. Tant que vous autorisez uniquement une base de données à accéder à son propre schéma, vous bénéficiez des avantages d'une base de données d'application mais sans la surcharge des serveurs de base de données existant pour chaque application ou service.
Cependant, en tant que développeur solo, je remettrais en question toute la notion de microservices à ce stade - Martin Fowler écrit sur le Monolith First et le Microservice Premium , Simon Brown parle à propos de monolithes modulaires , et DHH parle de Monolith majestueux . Je ne sais pas dans quelle mesure votre monolithe est bien organisé, mais refactorisez-le et organisez-le. Identifiez les composants et effectuez des séparations nettes entre eux pour extraire facilement les pièces dans un service. Il en va de même pour la structure de votre base de données. Concentrez-vous sur une architecture bonne, propre et basée sur les composants qui peut prendre en charge la refactorisation en services. Les microservices ajoutent beaucoup de frais généraux à un développeur unique pour créer et prendre en charge les opérations. Cependant, une fois que vous avez réellement besoin de faire évoluer une partie du système, utilisez vos systèmes de surveillance et de reporting pour identifier les goulots d'étranglement, extraire vers un service et faire évoluer si nécessaire.
Chaque microservice possède son propre service de base de données - cela semble le plus prometteur, car il préserve les avantages du couplage lâche et de la mise à l'échelle horizontale (en utilisant des copies de base de données redondantes et/ou un partitionnement sur plusieurs)
Se mettre d'accord. La troisième option est le choix naturel pour les microservices. Si les micro services sont destinés à être vraiment indépendants (et ne font pas partie d'un monolithique distribué ), il est normal qu'ils aient, chacun, une base de données.
[...] deux instances de microservice réelles par microservice (en cas de panne du serveur et pour un déploiement sans temps d'arrêt), et deux instances de service de base de données par microservice (en cas de panne du serveur etc ...).
Vous avez raison sur la quantité de micro services en cours d'exécution si vous souhaitez avoir un équilibre de charge. Si vous prévoyez d'avoir 4 micro-services, vous devez préparer au moins 2 instances de chaque micro-service (8 au total), comme vous l'avez déjà expliqué.
Mais deux bases de données par micro service? C'est vraiment discutable. Je ne connais pas les détails du problème commercial auquel vos micro-services seront confrontés, mais avec une redondance de base de données, c'est beaucoup pour la plupart des produits/projets. Je recommanderai de commencer avec une seule base de données avec une bonne sauvegarde et de minimiser (au moins initialement) la complexité de votre infrastructure.
Franchement, cela semble un peu ridicule. 16-20 serveurs pour exécuter une API simple, sachant qu'un projet réaliste aura probablement plus de 4-5 services? Y a-t-il un concept fondamental qui me manque qui expliquera cela?
Pour une API simple , ces chiffres ne correspondent pas. Faites attention si vous ne tombez pas dans l'un des "microservices d'abord" pièges .
Microservices sont une forme d'architecture orientée services, peut-être à l'extrême. Leur objectif général est de réduire le couplage et de permettre un développement et un déploiement indépendants.
En gros, en termes architecturaux, les microservices sont un terme qui s'applique, disons, à un niveau logique. Les microservices sont logiquement séparés les uns des autres. De ce point de vue, les microservices devraient chacun posséder et prévoir leur propre stockage, qui devrait être dissocié du stockage des autres microservices. Pour les microservices, cette indépendance de stockage est la clé de leur objectif de modularité et de couplage lâche.
D'un point de vue architectural, la mise à l'échelle horizontale s'applique à un niveau inférieur, plus proche de la mise en œuvre, disons, à un niveau physique. À ce niveau, nous implémentons un microservice et nous pouvons décomposer ce microservice unique, en interne, en un composant sans état qui est évolutif horizontalement, et un composant avec état qui est partagé par tous les composants sans état. Mais ne confondons pas seulement la partie sans état avec le microservice lui-même.
Donc, quand nous parlons des microservices individuels, nous sommes au niveau logique en parlant d'API et de responsabilités séparées et de cycles de développement/déploiement séparés. Et lorsque nous parlons de mise à l'échelle horizontale, nous parlons au niveau physique de l'implémentation d'un (unique) microservice et de sa décomposition en composants sans état et avec état.
Lors de la mise en œuvre de plusieurs microservices, nous avons le choix de réutiliser la technologie de base de données pour les composants avec état:
- base de données distincte par microservice
- base de données partagée avec:
- schéma séparé/privé par microservice
- tables séparées/privées par microservice
Voir plus ici .
Un service de base de données unique partagé par tous les microservices - cela semblerait éliminer complètement tout avantage d'un couplage lâche.
D'accord, si vous parlez de partager des lignes et des colonnes de tableaux, ce ne serait pas vraiment des microservices.
Si nous pouvons découpler - dans nos processus de pensée - la notion logique de microservices de la notion plus physique de composants avec et sans état d'un microservice, nous pouvons trouver plus facile de réaliser le couplage lâche offert par les microservices, tout en conservant l'efficacité d'un partage bases de données.
Généralement, il y a une bonne quantité écrite sur les microservices et la persistance avec état, voir aussi ici .