Discussion :

[<romain/>]

Bonjour,

Je travaille sur une application web depuis un an (développement MEAN). On est sur une architecture classique monolithique et on commence à avoir des problèmes de charges (à cause de certaines parties uniquement) de l'application ainsi que des mises en prod difficile du fait du nombre de fonctionnalités présente.

Du coup je me renseigne sur les architectures micro-services. Je pense avoir pas trop mal compris le concept et que ça correspondrait à mon besoin puisque je pourrais isoler les fonctionnalités sujettes aux problèmes de charge pour leur affecter plus de moyens.

Ce que je ne comprend pas par contre c'est comment c'est géré niveau bdd. Il est marqué partout qu'il faut essayer au maximum d'avoir une base de donnée par service. Ça à priori ça ne me pose pas de soucis, on a donc des services qui ont à la fois un serveur web et une base de donnée. Mais du coup quand il y a monté en charge et qu'on rajoute des services, on rajoute à la fois le serveur web et la bdd. Et dans ce cas comment se passe la réplication des données?

Si je prend l'exemple qu'on voit sur bcp de tuto du service pour gérer les commandes d'un site. On a une grosse monté en charge on double le service. Comment ce qui est enregistré sur la bdd1 se retrouve sur la bdd2 et inversement?

Merci.

[kevin254kl]

Salut,

J'ai travaillé sur du microsevrice docker aws entre autre pour casser un monolythe php. L'avantage c'est que tu utilises la techno que tu veux chaque microsevrice est indépendant golang/php ... Pour la base de données https://microservices.io/patterns/da...r-service.html tu as des containers je ne crois pas que le containers de la base de données soit avec le containers de l'application. Après la force des containers c'est que avec la plus part des solutions cloud si tu as une monté en charge pour un microservice il suffit alors juste d'allouée plus de ressources pour ce microservice.

Le problème c'est pour le refactoring, le management des solutions quand tu as beaucoup de microservices et bien d'autre

[yildiz-online]

C'est une DB par service(donc un modèle physique par bouded context), pas par instance de service, ça veut dire que si tu scale horizontalement ton service, ils sont tous connectés sur la même DB.

Tu peux aussi faire du scaling horizontal de ta persistence, mais ce sont d'autres techniques, indépendants de la notion de micro-service.

Il y a également d'autres solutions pour la DB: une archi CQRS pour séparer la lecture de l'écriture, un broker qui fait buffer pour les écritures...

[<romain/>]

Merci à tous les deux.

L'info que j'avais pas c'est que le container de la bdd est un container différent. Du coup effectivement en faisant ça quand on augmente le nb de serveur web ça n'augmente pas le nb de serveur bdd.

Et si on veut scaller la bdd on met en place un système classique.

Top!

Merci.

[Marco46]

La première étape c'est d'abord d'être capable de lancer plusieurs instance de ta stack monolithique.

Cette courte conf devrait t'aider :

[marc.collin]

lance plusieurs instance de ta stack avant de penser
a une stack microservice.....

tu peux commencer à refactoriser ton application en une architecture hexagonale... externaliser la partie qui cause problème dans un ms dans un premier temps....