Discussion :

[Invité]

Je m'intéresse à l'architecture en micro service pour l'un de mes projets.
Etant novice en la matière, il y a plusieurs points sur lesquelles je m'interroge:

- Les "API Gateways". J'ai vu qu'il était courant de passer par un API Gateway pour que le front n'ait qu'une seule api à interroger (ainsi si la structure des microservices changent, cela restera transparent pour lui). Est-ce quelque chose de nécessaire ? Est-il possible de le développer soit même pour répondre à 100% de mes besoins ? ou bien vaut-il mieux passer par un API Gateway open source par exemple

- La communication entre microservice. J'ai vu qu'il y avait plusieurs écoles :
- l'orchestration : l'API Gateway gère l'appel aux différents microservices dont il a besoin (ex : pour la création d'un utilisateur, il appelerait d'abord le service des users, puis celui des notifications)
- la chorégraphie : des events sont envoyés dans un message broker auxquels souscrivent les microservices. J'ai l'impression que cela oblige les microservices à connaître tous les évènements lancés par les autres microservices, et que cela peut être limitant.
Quels sont les pour ou les contre de ces deux méthodes ?

- Les tests automatisés. Comment gérer les tests unitiaires et d'intégration dans une architecture où il y a des dépendances entre les services ?

- La sécurisation d'une telle architecture. Entre le browser et l'api gateway, j'ai pensé à utiliser les json web token. Dans quelle mesure, un microservice doit faire confiance au json web token qu'il reçoit de l'api gateway? Comment garantir sa fiabilité ?

[Luckyluke34]

Ca dépend vraiment des projets. Autant certains systèmes se prêtent bien à l'approche "API all the things" avec un API gateway multifonctions au milieu, où un microservice qui veut communiquer avec un autre est juste considéré comme n'importe quel client externe, autant d'autres systèmes ont une "vie intérieure" plus riche avec des processus asynchrones qui se déclenchent dans certaines conditions, auquel cas l'approche orientée événements avec une message queue est plus adaptée.

C'est pour faire quel genre d'applications ?

[Invité]

Il s'agira d'une plateforme qui contiendra plusieurs applications.
Cette plateforme fournira un lot de microservices utiles à toutes les applications (ex : la gestion des users, des notifications, de la facturation, d'adresses, etc.).

Peut-être qu'un mix des deux pourraient être intéressants:
- utiliser un api gateway qui centraliserait ces microservices de base et qui pourraient appeler plusieurs microservices lors d'une requête en mode asynchrone.
- utiliser un système d'event pour les applications de la plateforme pour leur permettre de réagir en fonction des actions faits par le coeur du système (ex : si le microservice crée un nouveau service, certaines applications devront mener certaines actions). Pour ça, les messages broker pourraient être utiles.