Microservices : Protocoles et outils de communication
Les microservices échangent des messages via deux modèles principaux : synchrone par des requêtes HTTP directes vers les endpoints d'un autre service, et asynchrone via des courtiers comme Kafka ou RabbitMQ. Dans le modèle synchrone, l'émetteur attend une réponse, en connaissant l'URL et les endpoints du récepteur. Le modèle asynchrone utilise des topics pour stocker les messages sans interaction directe.
Le synchrone convient parfaitement aux scénarios requête-réponse, tandis que l'asynchrone excelle pour les événements où la fiabilité prime sur la vitesse.
Clients HTTP synchrones
Pour les appels directs, plusieurs outils se distinguent :
- RestTemplate : Un client bloquant simple mais dépassé pour les nouveaux projets en raison du blocage des threads.
- WebClient : Réactif sur Project Reactor, non bloquant, idéal pour les systèmes à fort débit avec un traitement asynchrone.
- Feign Client : Déclaratif — définissez une interface avec des annotations, et Spring génère l'implémentation du client HTTP. Synchrone avec support du cache, il réduit le code boilerplate.
Feign simplifie la vie : annotez simplement une interface avec @GetMapping ou @PostMapping, et c'est prêt. WebClient le surpasse en débit grâce à son E/S non bloquante.
Programmation réactive avec WebClient
La réactivité sur Project Reactor utilise Mono (valeur unique) et Flux (flux de valeurs). Différences clés par rapport à l'asynchrone traditionnel :
- Gère les flux de données dans le temps avec backpressure : les consommateurs signalent aux producteurs quand ils sont prêts.
- Opérateurs déclaratifs comme map, filter, flatMap et buffer pour les transformations.
- Évaluation paresseuse : les opérations ne se déclenchent qu'à l'abonnement.
Exemple de traitement d'utilisateurs depuis un dépôt :
Flux<User> users = userRepository.findAll();
Flux<String> names = users
.filter(u -> u.getAge() > 18)
.map(User::getName)
.take(10);
names.subscribe(name -> {
System.out.println("Received name: " + name);
});
Ici, les requêtes en base de données ne démarrent qu'au .subscribe(). Reactor s'intègre parfaitement avec Spring WebFlux pour les apps web réactives. Utilisez-le pour les charges élevées ou les flux de données ; restez synchrone pour les CRUD basiques.
WebSocket pour échanges événementiels
WebSocket établit une connexion persistante pour un échange bidirectionnel d'événements sans requêtes répétées. Pas de cycle requête-réponse : les services poussent les messages sur le canal ouvert.
Idéal pour :
- Chats et notifications en temps réel.
- Jeux et tickers boursiers avec mises à jour instantanées.
- Flux temporels sans sondage.
Inconvénient : pas de garanties de livraison si la connexion tombe. Tout est question de vitesse, pas de fiabilité absolue.
Kafka : Courtier de messages asynchrone
Kafka est un système distribué pour stocker et diffuser des événements. Les producteurs envoient vers des topics (journaux partitionnés), les consommateurs lisent des partitions.
Garanties de livraison :
- Au moins une fois : Les messages arrivent au moins une fois (duplicatas possibles en cas d'échec de commit).
- Exactement une fois : Via producteurs idempotents et transactions.
L'idempotence assure que des requêtes répétées donnent le même résultat. La réplication du courtier évite la perte de données. L'ordre est préservé dans les partitions par clé (ex. : ID utilisateur).
Les groupes de consommateurs répartissent la charge : plusieurs consommateurs gèrent les partitions en parallèle.
Cas d'usage de Kafka :
- Événements asynchrones comme emails, analyses ou bonus.
- Relecture d'historique pour recalculs.
- Streaming (Kafka Streams, CDC depuis bases de données).
Inconvénients : Configuration de cluster complexe (KRaft simplifie par rapport à ZooKeeper), et latence supérieure à HTTP.
Points clés à retenir
- Choisissez Feign pour des appels synchrones simples avec un minimum de code.
- Optez pour WebClient dans les systèmes réactifs à forte charge avec Flux/Mono.
- WebSocket pour échanges bidirectionnels en temps réel sans garanties de livraison.
- Kafka pour communication événementielle asynchrone fiable avec historique complet.
- Mélangez-les : synchrone pour CRUD, asynchrone pour événements.
— Editorial Team
Aucun commentaire pour le moment.