Que sont les microservices ?

Que sont les microservices ?

Les microservices sont un style d'architecture qui construit une application comme un ensemble de petits services. Chacun s'exécute dans son propre processus, porte une capacité métier et dialogue avec les autres via des API bien définies. Chaque service peut être déployé, mis à l'échelle et mis à jour sans redéployer le reste. L'alternative est le monolithe, où toutes les fonctions sont livrées ensemble comme une seule unité. Le compromis : des services plus simples pris un à un, pour un système plus complexe dans son ensemble.

Comment fonctionne un système de microservices

• Des services autour de capacités métier. Une boutique peut avoir des services distincts pour le catalogue, le panier, le paiement et la livraison, chacun avec son code et une équipe responsable.
• Communication par le réseau. Les services s'appellent de façon synchrone via des points de terminaison d'API (souvent REST ou gRPC) ou de façon asynchrone via un broker de messages comme Kafka ou une file d'attente.
• Des données propres à chaque service. Chaque service possède son stockage, et les autres n'y accèdent que par son API. Les services restent indépendants, mais il n'existe pas de transaction de base de données unique entre eux.
• Une API gateway. Les clients appellent un point d'entrée unique, qui route les requêtes vers le bon service et gère les tâches communes comme l'authentification.
• De l'automatisation en dessous. Le déploiement indépendant demande de la CI/CD, souvent des conteneurs et un orchestrateur comme Kubernetes, ainsi que journaux centralisés, métriques et traçage distribué.

Martin Fowler et James Lewis énumèrent neuf traits courants, dont la gestion décentralisée des données, l'automatisation de l'infrastructure, la conception pour la panne et la conception évolutive. Ils notent que tous les systèmes ne les réunissent pas.

Avantages

• Déploiement indépendant. Le correctif d'un service n'attend pas la livraison de tout le reste.
• Mise à l'échelle ciblée. On fait monter en charge les services sous tension, pas toute l'application.
• Isolation des pannes. Si un service tombe, les autres peuvent continuer, à condition que les appelants gèrent l'échec, par exemple avec des timeouts et des circuit breakers.
• Autonomie des équipes. De petites équipes prennent un service en charge de bout en bout et peuvent choisir des technologies différentes.

Les coûts

L'Azure Architecture Center de Microsoft énonce clairement les inconvénients : plus de pièces mobiles, des tests plus difficiles entre services dépendants, une cohérence des données sans transactions ACID entre services (cohérence à terme à la place), le versionnement de chaque API, une latence réseau supplémentaire et le besoin d'une culture DevOps mature. Fowler et Lewis ajoutent qu'un découpage peut déplacer la complexité vers les connexions entre services, où elle est plus difficile à voir. Pour une petite équipe ou un produit jeune, un monolithe bien structuré est souvent le meilleur départ.

Erreurs courantes

• Des services découpés par couche technique plutôt que par domaine métier. Résultat : des changements qui touchent toujours plusieurs services.
• Une base de données partagée. Les schémas partagés couplent les services et suppriment l'essentiel du bénéfice.
• Des services bavards. Les longues chaînes d'appels (A appelle B qui appelle C) s'additionnent en latence et propagent les pannes.
• Ni timeouts, ni reprises, ni circuit breakers. Une dépendance lente ralentit alors tous ses appelants.
• Trop de services trop tôt. Exploiter des dizaines de services demande un outillage que la plupart des petites équipes n'ont pas.
• Une observabilité faible. Sans journaux et traces corrélés, trouver le service défaillant dans une chaîne d'appels relève du hasard.

Microservices, tests de charge et supervision

Chaque service a sa propre limite de capacité, et un service lent peut entraîner tout ce qui l'appelle : testez donc les services isolés et la chaîne complète. Un test de charge montre où le débit plafonne et quel service atteint sa limite en premier. LoadFocus exécute des tests JMeter et k6 depuis 25 régions cloud, et le forfait gratuit comprend jusqu'à 10 utilisateurs virtuels. En production, la surveillance d'API contrôle chaque point de terminaison de service à intervalle régulier (statut, corps et temps de réponse ; toutes les 5 minutes dans le forfait gratuit), et les outils d'observabilité relient les signaux. Voir la surveillance d'API LoadFocus. Pour une démarche pas à pas, lisez le guide sur le test de charge des microservices dans le cloud (en anglais). Si vous concevez d'abord les contrats entre services, l'approche API-first s'y prête bien.

Questions fréquentes sur les microservices

Quelle différence entre microservices et monolithe ?

Un monolithe livre toutes les fonctions comme une seule unité déployable. Les microservices les répartissent en services déployés séparément, avec leurs propres données. Ils permettent une mise à l'échelle et des livraisons indépendantes, mais ajoutent des appels réseau, des données distribuées et plus de travail d'exploitation.

Quand utiliser des microservices ?

Quand plusieurs équipes doivent livrer indépendamment, que des parties du système ont des besoins de montée en charge très différents et que vous disposez déjà d'une CI/CD et d'une supervision solides. Pour une petite équipe ou un produit à ses débuts, commencez par un monolithe modulaire.

Comment les microservices communiquent-ils ?

De façon synchrone via des API HTTP (REST ou gRPC) ou de façon asynchrone via des messages et événements sur un broker ou une file. La messagerie asynchrone réduit le couplage et convient aux traitements sans réponse immédiate.

Comment gérer les données dans les microservices ?

Chaque service possède ses données et les expose via une API. Les changements qui couvrent plusieurs services reposent sur la cohérence à terme, par exemple avec des événements, plutôt que sur une seule transaction ACID.

Comment tester des microservices ?

En combinant des tests unitaires par service, des tests de contrat qui vérifient l'accord entre appelant et fournisseur, des tests d'intégration des parcours clés et des tests de charge sur les services isolés comme sur la chaîne complète.

Un microservice est-il la même chose qu'une API ?

Non. Une API est une interface. Un microservice est un service déployable qui en expose une, et un système de microservices en compte beaucoup.