Retour à l'accueil

Outils de Communication Microservices Kafka Feign

L'article analyse les outils d'interaction microservices : clients HTTP synchrones WebClient et Feign, WebSocket en temps réel, courtier Kafka asynchrone. Décrit la réactivité Reactor, garanties de livraison, exemples de code Flux. Recommandations de sélection selon charge et scénarios.

Comment les microservices communiquent : Kafka vs Feign vs WebClient
Advertisement 728x90

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 :

Google AdInline article slot
  • 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 :

Google AdInline article slot
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 :

Google AdInline article slot
  • 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

Advertisement 728x90

Lire ensuite