Architecture de microservices pour les applications web

Microservices : construire des applications en tant que services indépendants

Les applications web traditionnelles sont construites comme une seule unité — un monolithe. Tout le code pour gérer les utilisateurs, les produits, les commandes et les paiements vit dans une seule base de code, déployée comme une seule application. Les microservices adoptent une approche différente : chaque capacité métier devient son propre service indépendant, avec sa propre base de code, sa propre base de données et son propre cycle de déploiement.

Les avantages de la séparation

Le principal avantage des microservices est l'indépendance. Les équipes peuvent travailler sur différents services simultanément sans se marcher sur les pieds. Chaque service peut être déployé indépendamment, donc une modification du service de paiement ne nécessite pas de redéployer l'ensemble de l'application. Les services peuvent être mis à l'échelle indépendamment — si le catalogue de produits reçoit plus de trafic que les comptes utilisateurs, vous ne mettez à l'échelle que le service de catalogue.

Les microservices vous permettent également d'utiliser différentes technologies pour différents travaux. Le catalogue de produits pourrait fonctionner au mieux avec Node.js et MongoDB, tandis que le service de paiement a besoin de Java pour ses garanties de transaction. Et si un service tombe en panne, les autres peuvent continuer à fonctionner, limitant ainsi le rayon d'impact des défaillances.

Les défis

Les microservices introduisent une complexité significative. Au lieu d'une seule requête de base de données, vous pourriez avoir besoin d'effectuer plusieurs appels réseau à différents services pour assembler une page. La latence réseau devient un facteur. Assurer la cohérence des données entre les services est plus difficile que dans une base de données monolithique. Le débogage de problèmes qui s'étendent sur plusieurs services nécessite un traçage distribué.

La communication entre services nécessite une conception minutieuse. Les appels synchrones (HTTP/gRPC) sont simples mais peuvent créer des défaillances en cascade. La messagerie asynchrone (via une file d'attente de messages ou un bus d'événements) découple les services mais ajoute de la complexité. Vous avez besoin de la découverte de services pour que les services puissent se trouver mutuellement. Vous avez besoin de passerelles API pour fournir un point d'entrée unique aux clients. Et vous avez besoin de disjoncteurs pour empêcher la propagation des défaillances.

Quand les microservices ont du sens

Les microservices ne sont pas le bon choix pour tous les projets. Pour une petite équipe construisant une application simple, un monolithe est plus rapide à développer et plus facile à gérer. Les microservices deviennent précieux lorsque vous avez plusieurs équipes, chacune possédant un domaine métier distinct, et lorsque différentes parties de votre système ont des exigences de mise à l'échelle différentes.

De nombreuses équipes performantes commencent par un monolithe bien structuré et séparent les services au fur et à mesure des besoins. Les microservices prématurés — diviser votre application avant de comprendre les limites du domaine — conduisent souvent à un désordre distribué plus difficile à gérer que le monolithe avec lequel vous avez commencé.

Modèles clés

Si vous adoptez les microservices, plusieurs modèles aident à gérer la complexité. Le modèle de passerelle API fournit un point d'entrée unique pour les clients, acheminant les requêtes vers le service approprié. Le modèle Saga gère les transactions distribuées en coordonnant une série de transactions locales. Le modèle CQRS sépare les opérations de lecture et d'écriture. Et le modèle Event Sourcing stocke les modifications sous forme de séquence d'événements, fournissant une piste d'audit complète.