Discussion :

[Squadzz]

Hello,

J'ai commencé à m'interesser pas mal aux microservices, j'ai lu pas mal d'article, regarder des exemples, cependant je bloque sur certains points...

J'étais tombé sur un article parlant de "leboncoin" passant d'une archi monolithique vers micro services.



J'avais regardé un peu leurs offres d'emplois pour en savoir plus sur leur techno, et je vois que c'est découpé en plusieurs team "la team dépôt d'annonce", une autre "la team search" etc.

Par rapport à leur diagramme ci-dessus :

- Ont ils plusieurs micro-services comme par exemple : "team dépot annonces", "team recherche annonces", "team update/suppression annonces" à l'intérieur même d'un microservice "Ads" ?

- Pour l'authentification, peut on le considérer aussi comme un micro-services ? (qui va appeler un autre microservice "utilisateurs" ?)

- Sur "stackoverflow", j'avais lu qu'un "micro service" ne doit se connecter qu'à une seule BDD ?


Je avoir bien compris l'utiliter des micros (scalable, éviter la redondance du code etc.), cependant j'ai encore du mal à les structurer ou trouver des exemples "concret" :-/

Merci pour votre aide

[Luckyluke34]

Hello,

Ont ils plusieurs micro-services comme par exemple : "team dépot annonces", "team recherche annonces", "team update/suppression annonces" à l'intérieur même d'un microservice "Ads" ?

Oui, et il y a même de grandes chances que ce soit beaucoup plus. A titre de comparaison, les microservices chez de grands acteurs du net :

https://cdn-images-1.medium.com/max/...koV9ZCRafQ.png

Pour l'authentification, peut on le considérer aussi comme un micro-services ? (qui va appeler un autre microservice "utilisateurs" ?)

Ca dépend, si tu as un serveur d'authentification du marché, ce n'est en général pas considéré comme un micro-service. Si tu as ta propre authentification maison, ça peut l'être.

Sur "stackoverflow", j'avais lu qu'un "micro service" ne doit se connecter qu'à une seule BDD ?

C'est mieux, car les microservices doivent être déployables indépendamment les uns des autres. Le partage de données entre deux services va occasionner davantage d'accès concurrents et de potentielles race conditions sur ces données. Il y a aussi le risque que les deux services veuillent faire évoluer leur modèle de données dans des directions différentes et s'ils partagent la même base on est coincé.

cependant j'ai encore du mal à les structurer ou trouver des exemples "concret"

En concret niveau code il y a des samples comme ça : https://github.com/microservices-demo. Sinon tu devrais en trouver d'autres assez facilement pour ta techno.

[Squadzz]

Hey Luckyluke34,

Merci pour tes réponses ! :-)

J'ai trouvé un belle exemple d'une structure de microservice, ça m'a pas mal aider à comprendre.

Cinema - Example of Microservices in Go with Docker and MongoDB : https://github.com/mmorejon/microser...ker-go-mongodb

Est ce que tu pourrais juste m'eclaircir sur le schema ci-dessous :



J'ai du mal à comprendre le "best practice", ou avoir la bonne logique par rapport à ce schéma :

- 1 micro services "Ads" connecter à 1 BDD qui comprendra 3 services. Le tout dans 1 container. Cependant si le service "ads" lache, on pert toutes les fonctionnalités.

- 3 Microservices connecter vers 1 BDD, si par exemple le services "ads depot" tombe, on aura toujours la recherche, et delete ?

Par rapport au github ci-dessus, avec l'exemple, "ads" ne serait pas découper, et toutes les fonctionnalités serait situées dans un seul microservice.

Je vais commencer par lire ce tuto qui me semble assez complet, avec les techno du moment (kubernet, docker, grpc, golang, protobuf) https://ewanvalentine.io/microservic...golang-part-1/

Pour info, j'ai trouvé une story d'un Googler (dev cloud) qui comparait le temps entre REST vs gRPC et avec un Serveur GO et NodeJS : https://public.tableau.com/profile/s...016/gRPCvsRest

[Luckyluke34]

Là on commence à parler de containers, je me déclare incompétent (au jour d'aujourd'hui)

Je peux juste supposer que oui, plusieurs microservices dans un seul container casse la notion de déployabilité indépendante. Cela semble être une pratique découragée ici (#5) et ici.

Avoir le lien exact de l'article en question permettrait de mieux comprendre le contexte et de quoi on parle.

[Squadzz]

Oui, je pense qu'on perd un peu la notion de "microservices" et scalabilité avec le 1er schéma.

J'ai entre temps trouvé cette article : https://www.sumologic.com/devops/des...er-containers/

Task isolation : Create a Docker container for each individual microservice

Database separation : Use containers to host one or more data volumes, then reference them from other microservices and containers

“The benefit of this method of access is that it abstracts the location of the original data, making the data container a logical mount point.
It also allows ‘application’ containers accessing the data container volumes to be created and destroyed while keeping the data persistent in a dedicated container.”