Modèles de résilience
Toute dépendance finira par tomber en panne. Les patrons de résilience décident si cela reste un incident mineur ou devient une interruption.
Un disjoncteur en action
Fermé
Les appels passent et les échecs sont comptés.
Ouvert
Les appels échouent immédiatement avec un repli ; le service a le temps de récupérer.
Semi-ouvert
Un appel d'essai décide : un succès referme le disjoncteur, un échec le rouvre.
Circuit breaker
Prévenir les défaillances en cascade en arrêtant les appels aux services défaillants. Après que les échecs dépassent le seuil, le circuit « s'ouvre » et les requêtes échouent immédiatement. Tester périodiquement si le service a récupéré (état semi-ouvert).
Modèle de réessai
Réessayer automatiquement les opérations échouées avec backoff exponentiel. Utile pour les échecs transitoires (problèmes réseau, indisponibilité temporaire). Mettre en œuvre des limites de réessai et l'idempotence.
Modèle bulkhead
Isoler les ressources (pools de connexions, threads) pour qu'une défaillance dans une zone ne consomme pas toutes les ressources. Comme les compartiments étanches d'un navire.
Modèles d'intégration
Modèle API Gateway
Point d'entrée unique pour toutes les requêtes clients. Le gateway route, transforme et agrège les requêtes vers les services backend.
- Bénéfices : Code client simplifié, sécurité centralisée, transformation requête/réponse
- Mise en œuvre : Azure API Management, Application Gateway, gateway personnalisé avec Ocelot
Backends for Frontends (BFF)
Services backend séparés optimisés pour chaque frontend (web, mobile, IoT).
- Bénéfices : Réponses adaptées, évolution indépendante, meilleures performances
- Cas d'usage : Applications multi-plateformes avec différentes exigences UX
Modèle strangler fig
Migrer progressivement les systèmes legacy en routant les requêtes vers de nouveaux services tout en remplaçant graduellement les anciennes fonctionnalités.
- Bénéfices : Modernisation à faible risque, fonctionnement en parallèle, validation progressive
- Mise en œuvre : Couche de routage (API Gateway) dirige le trafic basé sur des feature flags
Modèles de gestion des données
Base de données par service
Chaque microservice possède sa base de données. Pas de bases de données partagées entre services. Synchronisation des données via événements ou API.
CQRS (Command Query Responsibility Segregation)
Modèles séparés pour lectures et écritures. Modèle d'écriture optimisé pour la cohérence, modèles de lecture dénormalisés pour la performance des requêtes.
Mise en œuvre : SQL pour les écritures, Cosmos DB pour les lectures, Event Grid pour la synchronisation
Modèle saga
Gérer les transactions distribuées entre microservices avec des transactions compensatoires. Approches orchestration (coordinateur central) ou chorégraphie (événementielle).