Différences entre communications synchrones et asynchrones

Qu’est-ce qu’une communication synchrone ?

Dans les communications synchrones, plusieurs parties écoutent en permanence les réponses des autres parties et agissent en conséquence.

Une façon de visualiser le concept de communication synchrone est d’imaginer un système de chat en ligne en temps réel pour le service clientèle d’une enseigne de distribution. L’agent du SAV échange rapidement des messages avec le client pour l’aider à suivre une commande, signaler une livraison manquante ou se renseigner sur un certain produit.

Dans ce scénario, l’expéditeur et le destinataire établissent à eux deux une session de communication. Une fois la session établie, la conversation est bidirectionnelle, elle a lieu sans aucune restriction sur qui saisit les informations et quand. Pendant qu’une partie tape un message sur le chat, la partie à l’autre bout du canal de communication est présente et attend activement de recevoir le message pour y répondre.

C’est ce qui définit les communications synchrones.

Qu’est-ce qu’une communication asynchrone ?

Dans une communication asynchrone, les parties n’attendent pas de manière proactive les messages. Reprenons l’exemple ci-dessus. Imaginez que le client utilise un autre canal que le chat, le mail par exemple. La communication devient asynchrone parce que lorsqu’il envoie son mail au SAV de l’enseigne, le client ne s’attend pas à recevoir une réponse instantanée. Il sait que l’équipe support lira son message au moment où un membre de l’équipe sera disponible et qu’il aura un créneau pour y répondre.

Les communications asynchrones impliquent un délai entre le moment où l’expéditeur envoie le message et celui où le destinataire y répond. La longueur de ce délai dépend du moyen de communication. Toujours avec le même exemple du SAV, un courrier papier envoyé par la poste prendra probablement encore plus de temps de transit que le mail.

En résumé, les deux parties d’un échange asynchrone ne travaillent pas ensemble en temps réel. En fait, l’un ou l’autre des destinataires peut même ignorer complètement avec qui il interagit.

Ces deux formes de transmission de données sont relativement simples à comprendre quand on les illustre avec des communications humaines. Mais il est nettement plus difficile pour les architectes et les développeurs de les appliquer à la conception de logiciels, où les temps d’échange peuvent se mesurer en millisecondes.

Comment fonctionnent les communications synchrones et asynchrones ?

Les applications génèrent des messages sous la forme d’appels à des fonctions, à des services et à des API. La manière dont un architecte conçoit ces communications affecte les performances de l’application, sa consommation de ressources et même sa capacité à exécuter des tâches.

Lorsqu’un composant logiciel communique de manière synchrone, il reste inactif jusqu’à ce qu’il reçoive un appel, une réponse, une valeur ou un autre transfert de données. Par exemple, l’exécution synchrone se produit pendant un achat en ligne. Un utilisateur décide d’acheter un produit, et le système génère une requête pour déterminer si le stock est disponible. L’application attend une réponse avant de lancer le processus de paiement. Cette conception synchrone permet d’éviter les incohérences entre les stocks et les ventes.

À l’inverse, la communication asynchrone permet au code de continuer à s’exécuter après avoir généré un appel ou une réponse. La communication asynchrone est particulièrement utile pour les rapports et les alertes, comme dans le cas d’une application de fabrication qui surveille la température d’un four industriel, transmet continuellement des mises à jour d’état et envoie automatiquement des alertes.

Ce type d’application ne doit jamais s’arrêter. Elle ne peut pas se permettre d’attendre des réponses avant de passer à l’action suivante. Au contraire, c’est la communication qui doit déclencher une action de la part du personnel ou d’une autre application. Par exemple, l’application peut envoyer des mises à jour asynchrones de la température tout au long de la journée, mais aussi déclencher une séquence de dépannage lorsque les températures dépassent ou descendent en dessous des niveaux exigés.

Comparaison des avantages et des inconvénients des communications synchrones et asynchrones

Les communications synchrones et asynchrones présentent chacune des avantages et des inconvénients. Le choix de la bonne méthode dépend de l’objectif de l’application.

La communication synchrone est plus simple dans sa conception. Mais elle fait courir un risque : celui de propager des défaillances d’un service applicatif à un autre. Pour atténuer ce risque, l’architecte logiciel devra prévoir une méthode évoluée de découverte des services et un équilibrage de charge (load balancing) entre microservices.

De son côté, la communication asynchrone troque la simplicité de l’architecture et la cohérence des données pour une plus grande résilience et une évolutivité plus facile. Les conceptions asynchrones offrent souvent un meilleur contrôle des défaillances que les configurations synchrones. Vous pouvez donc envisager de commencer par un système synchrone (pour optimiser la vitesse et le potentiel d’évolution) puis de passer aux communications asynchrones lorsque votre architecture de microservices grossit.

Bonnes pratiques pour les communications synchrones et asynchrones

La cohérence de la communication entre les services est l’un des défis majeurs à relever dans une architecture distribuée comme l’est celle à base de microservices. Il existe plusieurs approches pour le relever.

Les communications entre services dans une architecture de ce type peuvent être :

• Décentralisées et synchrones
• Chorégraphiées et asynchrones
• Orchestrées et synchrones/asynchrones

Dans un modèle de communication décentralisé et synchrone, chaque service reçoit un contrôle, effectue des appels synchrones ultérieurs à d’autres services et transmet le contrôle au service suivant.

En revanche, dans un schéma de communication dit « chorégraphié » et asynchrone, le service publie des événements dans une file d’attente centralisée de messages qui distribue ces événements.

Mais dans les deux approches, il n’y a pas d’information centralisée sur le comportement global du système. La logique de déroulement des opérations est soit intégrée dans les services, soit dans les liaisons d’événements entre les producteurs et les consommateurs.

Une autre approche, l’orchestration centralisée, permet une communication à la fois synchrone et asynchrone. L’orchestrateur séquence les différents appels de service sur la base d’un workflow défini en amont. Cette séquence n’est pas intégrée dans les services eux-mêmes. La connaissance du workflow est centralisée, et les services se concentrent uniquement sur les tâches qui leur sont allouées.

Pour permettre une communication synchrone et asynchrone entre microservices, il faut éviter que le séquençage des flux ne se fasse au niveau des services individuels. Ces flux « dans » les services sont difficiles à découpler. Concevez plutôt une architecture qui prend en charge la communication asynchrone et synchrone. Ensuite, permettez à votre orchestrateur de changer le modèle de communication pour des services spécifiques (voir la figure ci-dessous).

Schéma de la manière dont fonctionne un orchestrateur - Crédit LeMagIT/TechTarget

Cette approche permet une architecture plus simple, découplée et plus facile à lire. Elle prend également mieux en charge l’interopérabilité entre les protocoles et les services.

Problèmes types liés aux communications synchrones et asynchrones

Les processus de communication, qu’ils soient synchrones ou asynchrones, peuvent poser un certain nombre de problèmes, qui ont tous un impact significatif sur les performances d’un système applicatif. Ces problèmes sont presque toujours accentués dans les systèmes distribués, en particulier lorsque l’on parle de simultanéité, de workflow et de suivi des composants.

Décalage d’horloge

Le décalage d’horloge est une situation dans laquelle des composants liés entre eux reçoivent des indications de temps à des intervalles différents, ce qui a un impact significatif sur les performances d’un système synchrone. Cela peut notamment poser des problèmes dans les systèmes « à forte densité » qui hébergent un grand nombre de composants.

Le décalage d’horloge est aussi dommageable dans le cas d’une communication asynchrone, et c’est un défi de s’assurer que l’horloge de chaque module et de chaque composant reste synchronisée avec les autres. Dans le stockage, les opérations de lecture et d’écriture sont susceptibles de se produire à quelques millisecondes d’intervalle. Sans une synchronisation d’horloge, les opérations d’E/S peuvent intervenir dans le mauvais ordre.

Stockage des données et intégrité des données

Le stockage de données dans le cloud, en particulier la sauvegarde pour les systèmes sur site, localise les données sources et les sauvegardes à des endroits différents. La réplication synchrone à distance exige que les opérations de lecture et d’écriture aient lieu en même temps dans le stockage primaire et dans la sauvegarde.

Un autre défi est la nécessité de corréler plusieurs flux de données qui englobent à la fois des méthodes de collecte synchrones et asynchrones. Ce problème est particulièrement présent dans le data mining et dans l’analyse en continu.

Suivi des communications

Dans la plupart des architectures d’applications monolithiques, les déclarations sur le comportement du système sont relativement évidentes. Mais lorsque l’architecture est constituée de services distribués, il est beaucoup plus difficile de suivre le flux de communication. Une seule tâche construite sur des services dispersés implique probablement plusieurs couches de communication.