1. Communication synchrone

La communication synchrone implique une interaction en temps réel dans laquelle un service envoie une demande à un autre et suspend son fonctionnement jusqu'à ce qu'une réponse soit reçue. Les API REST et gRPC sont des protocoles courants utilisés pour faciliter ce type de communication.

1.1 API RESTful

Une API RESTful (Representational State Transfer) est l'une des méthodes les plus courantes permettant aux services de communiquer entre eux dans un système de microservices. REST utilise les formats HTTP/HTTPS et JSON ou XML pour l'échange de données.

En règle générale, les services interagissent les uns avec les autres en appelant directement l'API d'un autre service.

Exemple de demande et de réponse :

GET /users/12345 HTTP/1.1
Host: api.userservice.com
Accept: application/json
Authorization: Bearer your-access-token

{
  "userId": "12345",
  "name": "Michel J",
  "email": "[email protected]",
  "address": "Mountain View, Santa Clara, California"
}

Exemple de code source

import org.springframework.web.client.RestTemplate;
import org.springframework.http.ResponseEntity;

public class OrderService {

    private final RestTemplate restTemplate = new RestTemplate();
    private final String userServiceUrl = "https://api.userservice.com/users/";

    public User getUserById(String userId) {
        String url = userServiceUrl   userId;
        ResponseEntity response = restTemplate.getForEntity(url, User.class);
        return response.getBody();
    }
}

Avantages :

Facile à déployer et à intégrer avec différents langages et outils.

Peut facilement utiliser des outils de test et de surveillance.

Inconvénients :

Peut ne pas être efficace pour les exigences de vitesse élevée en raison de sa nature synchrone.

Peut rencontrer des difficultés dans la gestion des erreurs ou des déconnexions du réseau.

1.2 gRPC

gRPC, pour Google Remote Procedure Call, est un framework RPC universel open source hautes performances. Il utilise HTTP/2 pour un transfert de données efficace et s'appuie généralement sur des tampons de protocole, un mécanisme extensible indépendant du langage et de la plate-forme pour sérialiser les données structurées, afin de définir la structure des données envoyées et reçues.

Exemple, définition des tampons de protocole

syntax = "proto3";

package userservice;

// Define message User
message User {
    string userId = 1;
    string name = 2;
    string email = 3;
    string address = 4;
}

// Define service UserService
service UserService {
    rpc GetUserById (UserIdRequest) returns (User);
}

// Define message UserIdRequest
message UserIdRequest {
    string userId = 1;
}

Pour le service de gestion des utilisateurs, vous devez implémenter un serveur gRPC qui adhère à la définition de service fournie dans le fichier .proto. Cela inclut la création de la logique côté serveur nécessaire pour gérer les requêtes gRPC entrantes et générer des réponses appropriées.

import io.grpc.stub.StreamObserver;
import userservice.User;
import userservice.UserIdRequest;
import userservice.UserServiceGrpc;

public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {

    @Override
    public void getUserById(UserIdRequest request, StreamObserver responseObserver) {
        // Assuming you have a database to retrieve user information.
        User user = User.newBuilder()
                .setUserId(request.getUserId())
                .setName("Michel J")
                .setEmail("[email protected]")
                .setAddress("Mountain View, Santa Clara, California")
                .build();

        responseObserver.onNext(user);
        responseObserver.onCompleted();
    }
}

import io.grpc.Server;
import io.grpc.ServerBuilder;

public class UserServer {
    public static void main(String[] args) throws Exception {
        Server server = ServerBuilder.forPort(9090)
                .addService(new UserServiceImpl())
                .build()
                .start();

        System.out.println("Server started on port 9090");
        server.awaitTermination();
    }
}

Avantages :

Hautes performances et efficacité de la bande passante grâce à l'utilisation de HTTP/2 et des tampons de protocole.

Prend en charge plusieurs langages de programmation et offre une bonne évolutivité.

Inconvénients :

Nécessite une couche de traduction si les services ne prennent pas en charge gRPC.

Peut être plus complexe à déployer et à gérer.

2. Communication asynchrone

La communication asynchrone fait référence au processus par lequel un service envoie une requête à un autre service sans bloquer son propre fonctionnement pour attendre une réponse. Ceci est généralement réalisé via des files d’attente de messages ou des systèmes de publication/abonnement.

1. Files d'attente de messages

Les systèmes de file d'attente de messages, comme RabbitMQ et Apache ActiveMQ, facilitent la communication asynchrone entre les services.

Avantages :

Évolutivité et tolérance aux pannes améliorées : le système peut mieux gérer des charges de travail accrues et est moins susceptible aux pannes.

Charge réduite sur les services : en dissociant l'envoi et la réception des requêtes, les principaux services peuvent se concentrer sur les tâches de traitement sans être submergés par des requêtes constantes.

Inconvénients :

Peut nécessiter des efforts supplémentaires de gestion et de maintenance : les systèmes basés sur des files d'attente peuvent être plus complexes et nécessiter davantage de ressources pour fonctionner.

Difficulté à gérer les commandes et à assurer la livraison des messages : S'assurer que les demandes sont traitées dans le bon ordre et qu'aucun message n'est perdu peut être un défi technique.

2.2. Système Pub/Sous

Un système Pub/Sub (Publish/Subscribe), tel qu'Apache Kafka ou Google Pub/Sub, permet aux services de publier des messages et de s'abonner à des sujets.

Avantages :

Prend en charge les flux de données à grande échelle et à haut débit.

Réduit les dépendances entre les services.

Inconvénients :

Nécessite une couche plus complexe pour gérer et surveiller les sujets et les messages.

Il peut être difficile de gérer les problèmes d'ordre et de fiabilité des messages."

Si vous êtes intéressé, vous pouvez lire mes précédents articles sur le sujet pub/sub.

File d'attente de lettres mortes dans un courtier de messages, partie 1

File d'attente de lettres mortes dans un courtier de messages, partie 2

Problèmes de cohérence et de fiabilité au sein du système Message Broker

3. Communication événementielle

La communication basée sur les événements se produit lorsqu'un service émet un événement et que d'autres services répondent ou prennent des mesures en fonction de ces événements.

3.1. Événements synchrones

Les événements synchrones se produisent lorsqu'un service émet un événement et attend une réponse d'autres services.

Avantages :

Facile à contrôler et à surveiller le processus de traitement des événements.

Inconvénients :

Peut provoquer des goulots d'étranglement si les services qui répondent sont lents ou rencontrent des erreurs

3.2. Événements asynchrones

Les événements asynchrones se produisent lorsqu'un service émet un événement et n'a pas besoin d'attendre une réponse immédiate.

Avantages :

Réduit le temps d'attente et améliore l'évolutivité.

Aide les services à fonctionner de manière plus indépendante et réduit les dépendances mutuelles.

Inconvénients :

Nécessite des mécanismes supplémentaires pour garantir que les événements sont traités correctement et en temps opportun.

Difficulté à assurer l’ordre et à gérer les événements en double.

4. Conclusion

Le choix de la méthode de communication entre les services dans un système de microservices dépend de facteurs tels que les exigences de performances, la fiabilité et la complexité du système. Chaque méthode a ses propres avantages et inconvénients, et comprendre ces méthodes vous aidera à créer un système de microservices plus efficace et plus flexible. Examinez attentivement les exigences de votre système pour choisir la méthode de communication la plus appropriée.