Construire des systèmes évolutifs, maintenables et résilients nécessite une prise de conscience des modèles de conception importants, qui sont de plus en plus répandus avec l'architecture des microservices. Les microservices, par opposition aux architectures monolithiques, divisent les grands systèmes en services indépendants plus gérables qui se connectent les uns aux autres via un réseau. Cependant, cette nature distribuée introduit de la complexité dans des domaines tels que la communication, la gestion des données et la coordination des services.

L'adoption de modèles de conception de microservices bien connus peut aider à atténuer ces problèmes et à améliorer considérablement la fiabilité et l'efficacité de votre système. Les 7 principaux modèles de conception de microservices que tout développeur de logiciels devrait connaître sont abordés dans cet article.

1. Modèle de passerelle API

API Gateway agit comme un point d'entrée unique pour toutes les requêtes des clients vers les microservices. Au lieu de permettre aux clients d'interagir directement avec plusieurs services, API Gateway consolide ces demandes, les achemine vers les microservices appropriés et regroupe les réponses. Il simplifie la communication client-serveur et fournit un moyen de gérer les problèmes transversaux tels que l'authentification, la journalisation et la limitation de débit.

Avantages:

✓ Contrôle centralisé de la gestion des demandes/réponses.

✓ Simplifie les interactions côté client en éliminant la complexité interne des microservices.

✓ Permet une mise en œuvre plus facile de la sécurité, de la mise en cache et de la limitation.

Exemple:

Utilisation d'Express.js dans Node.js pour créer une passerelle API de base :

import express from 'express';
import proxy from 'express-http-proxy';

const app = express();

// Forward requests to microservice A
app.use('/serviceA', proxy('http://serviceA-url'));

// Forward requests to microservice B
app.use('/serviceB', proxy('http://serviceB-url'));

app.listen(3000, () => {
  console.log('API Gateway running on port 3000');
});

2. Modèle de disjoncteur

Dans une architecture de microservices, les pannes de service sont inévitables. Le modèle de disjoncteur permet d'éviter les pannes en cascade en surveillant les appels de service et en arrêtant les appels ultérieurs vers un service défaillant lorsqu'un certain seuil de panne est atteint. Une fois le service rétabli, le disjoncteur autorise à nouveau les appels. Cela améliore la résilience du système et évite une charge inutile sur des services déjà en difficulté.

Avantages:

✓ Protège contre les pannes à l'échelle du système.

✓ Fournit des réponses de secours ou alternatives en cas de panne.

✓ Améliore la robustesse de l'architecture des microservices.

Exemple:

Utilisation de la bibliothèque opossum dans Node.js pour un disjoncteur :

import CircuitBreaker from 'opossum';
import axios from 'axios';

const options = {
  timeout: 5000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
};

const circuitBreaker = new CircuitBreaker(() => axios.get('http://serviceB-url'), options);

circuitBreaker.fire()
  .then(response => console.log(response.data))
  .catch(err => console.log('Service B is down. Circuit is open.'));

3. Base de données par modèle de service

Chaque microservice doit disposer de sa propre base de données dédiée, permettant aux équipes de travailler de manière indépendante et réduisant le couplage étroit entre les services. Ce modèle de conception garantit que les microservices peuvent évoluer de manière indépendante sans être affectés par les modifications apportées à un schéma de base de données partagé.

Avantages:

✓ Réduit la dépendance et les conflits entre services.

✓ Facilite la mise à l'échelle indépendante et l'évolution des schémas.

✓ Isole la propriété et la responsabilité des données.

4. Modèle de saga

Dans une architecture distribuée, la gestion des transactions qui s'étendent sur plusieurs services peut s'avérer difficile. Le modèle Saga gère les transactions distribuées à l'aide d'une série de transactions locales coordonnées sur plusieurs services. Chaque service exécute sa transaction et déclenche la suivante, avec des mécanismes de compensation pour annuler les opérations en cas de problème.

Avantages:

✓ Permet des transactions distribuées cohérentes sans gestionnaire de transactions centralisé.

✓ Prend en charge la cohérence éventuelle entre les microservices.

✓ Permet l'annulation des opérations incomplètes si nécessaire.

Exemple:

Dans un système de commerce électronique, le service de commande peut créer une commande, le service de paiement traite le paiement et le service d'inventaire met à jour les niveaux de stock. Si le paiement échoue, les mises à jour de la commande et des stocks doivent être annulées, ce qui est géré via des transactions compensatoires.

5. Modèle de sourcing d'événements

Le modèle de sourcing d'événements stocke l'état d'un système sous la forme d'une séquence d'événements. Au lieu d'enregistrer l'état actuel dans une base de données, les microservices stockent les événements qui représentent les changements d'état. En rejouant ces événements, l'état actuel peut toujours être reconstruit, ce qui fournit une piste d'audit complète et permet des mécanismes de récupération sophistiqués.

Avantages:

✓ Fournit une piste d'audit claire de toutes les modifications.

✓ Permet une analyse historique en rejouant les événements passés.

✓ Facilite la reconstruction de l'état si nécessaire.

Exemple:

Dans un système comptable, les événements tels que « transaction créée », « transaction approuvée » et « transaction terminée » sont stockés en tant qu'événements. Le solde actuel peut être recalculé en rejouant tous les événements de transaction.

6. Modèle CQRS (ségrégation des responsabilités des requêtes de commande)

Le modèle CQRS sépare les opérations de lecture et d'écriture en différents modèles. Les opérations d'écriture sont gérées par le modèle de commande et les opérations de lecture sont gérées par le modèle de requête. Ce modèle est particulièrement utile pour les applications hautes performances où les lectures sont beaucoup plus fréquentes que les écritures.

Avantages:

✓ Optimise les performances en séparant les problèmes de lecture/écriture.

✓ Prend en charge différentes stratégies d'évolutivité pour les lectures et les écritures.

✓ Permet des modèles flexibles adaptés à des tâches spécifiques.

7. Modèle de figue étrangleur

Le modèle Strangler Fig est une stratégie de migration progressive qui vous permet de refactoriser ou de remplacer des parties d'un monolithe par des microservices. Au fur et à mesure que de nouvelles fonctionnalités sont ajoutées, elles sont construites comme un microservice. Au fil du temps, le monolithe est remplacé, service par service, sans perturber l'ensemble du système d'un seul coup.

Avantages:

✓ Fournit un chemin sans interruption pour migrer des monolithes vers les microservices.

✓ Réduit le risque de réécriture complète du système.

✓ Permet une amélioration et une refactorisation incrémentielles.

Exemple:

Vous pouvez commencer par extraire le composant d'authentification utilisateur d'une application monolithique dans un microservice autonome tout en gardant intactes les autres parties du système. Au fil du temps, davantage de composants sont déplacés vers les microservices jusqu'à ce que l'ensemble du système soit modularisé.

Conclusion

Il existe de nombreuses façons différentes de résoudre les problèmes qui surviennent dans les systèmes distribués lors de l'utilisation des principes de conception de microservices. Construire une architecture de microservices fiable et évolutive nécessite de comprendre ces modèles, quels que soient vos objectifs : gérer les données entre les services, améliorer la communication entre les services ou gérer les erreurs avec élégance. En répondant à des exigences et des compromis particuliers, chacun de ces modèles contribue à la résilience et aux performances de vos microservices.