Microservices et stockage de données

J'envisage de déplacer une API REST monolithique vers une architecture de microservices, et je suis un peu confus au sujet du stockage de données. Selon moi, 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:

1. 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.
2. 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.
3. 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, 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 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 ...).

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.

La première s'appelle une 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 une 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 contesterais toute la notion de microservices à ce stade - Martin Fowler écrit sur le Monolith First et le Microservice Premium , Simon Brown parle de monolithes modulaires et DHH parle du Majestic Monolith. 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 seul développeur 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 micro-services. Si les microservices sont destinés à être vraiment indépendants (et non à faire partie d'un monolithe distribué ), il est normal qu'ils disposent, chacun, d'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 pièges "Microservice First" .

Les 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 assurer 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, lorsque 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 la mise en œuvre 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 voulez partager des lignes et des colonnes de tables, 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 .

Eh bien, j'ai lu tous les messages de ce fil et je peux vous dire que je suis confus avec la question: il mélange le microservice (MS) avec les services avec le service d'accès aux données (service DB) avec les bases de données et les serveurs ...

Si MS est un composant indépendant (déployable) résolvant une tâche la plus simple sans état, quelle base de données dont il a besoin? Si une tâche plus complexe à résoudre, qui nécessite la résolution de plusieurs sous-tâches (MS?) Les plus simples, est-ce toujours une MS? Dans SOA, il est appelé un service d'orchestration. Il implémente le «processus» et coordonne l'invocation de MS, il doit donc conserver son état (toutes les orchestrations / organisateurs / compositeurs / etc. sont avec état) et a besoin d'un magasin de données personnel: personne d'autre ne peut tempérer l'état de l'orchestrateur.

Cependant, nous ne parlons pas de base de données mais de Database Access MS / Service, et c'est une question totalement différente. Un EM peut avoir besoin de certaines données collectées dans l'entreprise (pas dans l'application dans laquelle il opère) et il ne peut pas demander les données à un autre EM via son API / interface. Il s'agit du scénario le plus courant et le plus réaliste. Et un autre MS de la même application ou d'une application différente peut avoir besoin de ces données ou même les modifier. Oui, ils se disputent les données comme c'était toujours le cas avant l'émergence de la SEP.

Pourquoi nous faisons planter la «porte», qui est bien connue et ouverte? Quelle est la différence à cet égard entre une SEP et un objet auto-persistant régulier? Pourquoi avons-nous besoin d'une base de données individuelle pour MS si elle doit (à des fins de flexibilité et de composabilité) engager son service d'accès aux données (DAS) de toute façon? N'oubliez pas que DAS protège le MS avec une tâche commerciale de la prise de conscience de la connectivité physique à la base de données. Ce couplage lâche et cette flexibilité que l'EM devrait conserver pour participer librement à plusieurs applications sans ancrage de base de données.