Décoder la communication synchrone et asynchrone dans les applications cloud natives

La conception d'applications cloud natives implique la gestion d'un système complexe de microservices et de composants sans serveur qui doivent communiquer efficacement entre eux. La communication synchrone utilise des appels HTTP ou gRPC, attend une réponse dans un intervalle de temps spécifié, fournit un retour en temps réel et convient aux scénarios nécessitant une réponse immédiate. La communication asynchrone utilise des courtiers de messages (tels que RabbitMQ ou Kafka) pour échanger des messages sans nécessiter de réponses immédiates, améliorant ainsi l'évolutivité du système. En comprenant les avantages et les inconvénients de chaque mode de communication, les architectes peuvent concevoir des systèmes qui coordonnent efficacement ces éléments indépendants pour fournir des applications cloud natives hautes performances, évolutives et fiables.

Imaginez construire une machine complexe avec de nombreuses pièces indépendantes, chacune remplissant sa fonction, mais devant toutes communiquer efficacement les unes avec les autres pour accomplir la tâche. C’est le défi auquel nous sommes confrontés lors de la conception d’applications cloud natives composées de microservices interconnectés et de composants sans serveur. Dans cet article, nous explorons les détails de la conception d'un système de communication robuste et résilient, capable de coordonner efficacement ces éléments indépendants à l'intérieur et à l'extérieur des limites de l'application.

Ces services à granularité fine utilisent diverses méthodes de communication synchrones ou asynchrones pour les interactions internes et externes. Dans une communication synchrone, un service appelle un autre service via HTTP ou gRPC, attend une réponse dans un délai spécifié, puis continue. En revanche, la communication asynchrone consiste à échanger des messages sans attendre de réponse immédiate. Un courtier de messages tel que RabbitMQ ou Kafka agit comme intermédiaire, mettant les messages en mémoire tampon pour garantir une livraison fiable. Dans les applications cloud natives, l’utilisation d’une combinaison de modèles de communication constitue souvent une approche pratique. Commençons par la communication synchrone.

Qu'est-ce que la communication synchrone ?

La communication synchrone est comme une conversation. Un service (appelons-le Service A) fait une requête puis attend une réponse d'un autre service (Service B) ou d'une API externe. C’est comme poser une question et attendre la réponse. Le service A envoie la demande via HTTP et attend. Soit il attend une réponse du service B, soit l'expiration du temps d'attente maximum. Durant cette période d'attente, le service A est temporairement bloqué, tout comme on met son activité en pause pour attendre une réponse. Ce mode est souvent appelé mode requête-réponse et est relativement simple à mettre en œuvre. Cependant, son utilisation généralisée peut présenter des défis qui nécessitent un examen attentif.

Défis de la communication synchrone

Bien que la communication synchrone soit un outil puissant dans notre boîte à outils cloud native, elle comporte également son propre ensemble de défis qui doivent être soigneusement examinés.

Couplage temporel

Une dépendance excessive à l'égard de la communication synchrone dans l'ensemble de la solution peut entraîner des problèmes de couplage temporel. Cela se produit lorsqu'un grand nombre d'appels synchrones sont enchaînés, ce qui oblige l'application client à attendre plus longtemps pour recevoir une réponse.

Dépendances de disponibilité

La communication synchrone nécessite que tous les services de communication soient disponibles en même temps. Si le service backend subit une charge inattendue, les applications clientes peuvent échouer avec des erreurs de délai d'attente, ce qui a un impact sur les performances globales.

Impact sur la qualité du réseau

La qualité du réseau peut avoir un impact direct sur les performances des communications synchrones, y compris la bande passante disponible et la durée requise pour que les réponses transitent entre les services backend de service.

Malgré ces défis, la communication synchrone peut s'avérer inestimable dans des scénarios spécifiques. Explorons quelques cas d'utilisation dans lesquels la communication synchrone pourrait être un meilleur choix dans la section suivante.

Quand utiliser la communication synchrone

Dans certains cas, l'utilisation de la communication synchrone peut être une meilleure option.

Accès aux données en temps réel ou résultats garantis

La communication synchrone augmente l'efficacité lorsqu'un retour d'information immédiat ou en temps réel est nécessaire. Par exemple, lorsqu'un client passe une commande sur un site Web de commerce électronique, le front-end du commerce électronique doit vérifier le système d'inventaire pour s'assurer que l'article est en stock. Il s'agit d'une opération synchrone car l'application doit attendre une réponse du système d'inventaire avant de pouvoir continuer à traiter la commande.

Orchestrer la séquence de tâches liées

Dans les situations où un service doit effectuer une séquence de tâches, chacune dépendante de la tâche précédente, la communication synchrone peut maintenir l'ordre. Il est particulièrement adapté aux flux de travail où l'ordre des tâches est critique.

Maintenir l'intégrité des transactions

Lorsqu'il est essentiel de maintenir la cohérence des données sur plusieurs composants, la communication synchrone peut aider à maintenir les transactions atomiques. Cela est pertinent pour des scénarios tels que les transactions financières où l’intégrité des données est critique.

La communication synchrone est un outil puissant, mais elle comporte également des défis. La bonne nouvelle est que nous avons également la possibilité de communiquer asynchrone – un style complémentaire qui peut fonctionner avec des méthodes synchrones. Explorons cela plus en détail dans la section suivante.

Qu'est-ce que la communication asynchrone ?

Le modèle de communication asynchrone fournit une méthode dynamique et efficace pour la communication interservices. Contrairement à la communication synchrone, la communication asynchrone permet à un service de lancer une requête sans attendre une réponse immédiate. Dans ce modèle, les réponses peuvent ne pas être immédiates ou arriver de manière asynchrone sur un canal distinct (comme une file d'attente de rappel). Ce modèle de communication s'appuie sur des protocoles tels que Advanced Message Queuing Protocol (AMQP) et des middlewares de messagerie, notamment des courtiers de messages ou des courtiers d'événements.

Ce middleware de messagerie agit comme un intermédiaire avec une logique métier minimale. Il reçoit des messages d'une source ou d'un service producteur et les transmet au service consommateur prévu. L'intégration d'un middleware de messagerie peut améliorer considérablement la résilience et la tolérance aux pannes de cette approche découplée. La communication asynchrone englobe diverses implémentations. Explorons-les plus en détail.

Communication individuelle

Dans la communication de messages individuels, le producteur utilise un courtier de messages pour envoyer le message spécifiquement au destinataire. En règle générale, les courtiers de messages s'appuient sur des files d'attente pour garantir une communication fiable et fournir des garanties de livraison, par exemple au moins une fois. L'implémentation est similaire au modèle de commande, dans lequel le message transmis agit comme une commande utilisée par le service d'abonné pour déclencher des actions.

Prenons un exemple de boutique de vente au détail en ligne pour illustrer son utilisation. Une entreprise en ligne dépend en grande partie de la fiabilité de son site Internet. Ce modèle offre une tolérance aux pannes et des garanties de message, garantissant qu'une fois qu'un client passe une commande sur le site Web, le système d'exécution backend reçoit la commande à traiter. Le courtier de messages conserve les messages même si le système back-end est arrêté et les remet lorsqu'ils peuvent être traités. Par exemple, dans une application de commerce électronique, lorsqu'un client passe une commande, un courtier de messages peut être utilisé pour envoyer les détails de la commande sous forme de message du service de commande (producteur) au service d'exécution (consommateur). Ceci est un exemple de communication individuelle.

Communication individuelle asynchrone dans le cloud

L'extension du mode message individuel est le mode requête-réponse asynchrone. Dans ce cas, le répartiteur envoie le message sans attendre de réponse. Mais dans certains scénarios spécifiques, les consommateurs doivent utiliser des files d'attente dans la même file d'attente de l'infrastructure du courtier de messages pour répondre aux services de production. Les réponses des consommateurs peuvent contenir des métadonnées supplémentaires, telles qu'un identifiant associé à la demande initiale ou à l'adresse de réponse. Étant donné que les producteurs n’attendent pas de réponses immédiates, un flux de travail distinct gère ces réponses. Une fois la commande passée, le service d'exécution (consommateur) répond au service de commande frontal (producteur) afin que les clients puissent effectuer la mise à jour sur le site Web.

Communication demande-réponse individuelle asynchrone dans le cloud

La communication avec un seul consommateur est pratique lorsque deux services communiquent point à point. Cependant, il existe des situations dans lesquelles un éditeur doit envoyer un événement spécifique à plusieurs abonnés, ce qui nous amène au modèle suivant.

Communication un-à-plusieurs

Cette méthode de communication est extrêmement précieuse lorsqu'un seul composant (éditeur) a besoin de diffuser des événements à plusieurs composants et services (abonnés). La communication un-à-plusieurs utilise le concept de sujets, similaire aux forums en ligne.

C'est comme un forum en ligne où plusieurs utilisateurs peuvent publier des articles que leurs abonnés peuvent lire à leur rythme et répondre si nécessaire. De même, une application peut comporter des sujets dans lesquels les services producteurs peuvent écrire et que les services consommateurs peuvent lire. C'est l'un des modèles les plus populaires dans les applications du monde réel.

Considérez encore une fois que la plateforme de commerce électronique dispose d'un service qui met à jour les prix des produits et que plusieurs services nécessitent ces informations (comme les services d'abonnement, les services de recommandation, etc.), les mises à jour de prix peuvent être envoyées sous forme de messages aux sujets du courtier de messages. . Tous les services intéressés (abonnés) peuvent écouter le sujet et recevoir des mises à jour de prix. Ceci est un exemple de communication un-à-plusieurs. Il existe plusieurs outils disponibles pour implémenter ce modèle, Apache Kafka, Redis Pub/Sub, Amazon SNS et Azure Event Grid étant parmi les choix les plus populaires.

Communication asynchrone un-à-plusieurs dans le cloud

Défis de la communication asynchrone

Bien que la communication asynchrone offre de nombreux avantages, elle comporte également son propre ensemble de défis.

Résilience et tolérance aux pannes

Avec un grand nombre de microservices et de composants sans serveur, chacun avec plusieurs instances, les pannes sont inévitables. Les instances peuvent planter, être submergées ou connaître des pannes temporaires. De plus, l’expéditeur n’attend pas que le message soit traité, donc si une erreur se produit, il peut ne pas en être immédiatement conscient. Nous devons adopter les stratégies suivantes :

Mécanisme de nouvelle tentative : réessayer les appels réseau ayant échoué pour des pannes temporaires

Modèle de disjoncteur : empêcher les appels répétés vers des services défaillants pour éviter les goulots d'étranglement des ressources

Traçage distribué

La communication asynchrone peut s'étendre sur plusieurs services, cela rend difficile la surveillance des performances globales du système. La mise en œuvre du traçage distribué permet de relier les journaux et les métriques pour comprendre le flux des transactions.

Débogage et surveillance complexes

Les communications asynchrones peuvent être plus difficiles à déboguer et à surveiller car les opérations ne suivent pas un flux linéaire. Des outils et techniques spécialisés sont souvent nécessaires pour déboguer et surveiller efficacement ces systèmes.

Gestion des ressources

Les systèmes asynchrones impliquent souvent des connexions de longue durée et un traitement en arrière-plan, ce qui peut entraîner des problèmes de gestion des ressources. Il faut veiller à gérer efficacement les ressources afin d'éviter les fuites de mémoire ou la surutilisation du processeur.

Comprendre ces défis peut aider à concevoir des systèmes de communication asynchrones plus robustes et résilients dans les applications cloud natives.

Derniers mots

Le choix entre les modes de communication synchrone et asynchrone n'est pas binaire mais une décision stratégique basée sur les exigences spécifiques de l'application.

La communication synchrone est facile à mettre en œuvre et fournit un retour instantané, ce qui la rend adaptée à l'accès aux données en temps réel, à l'orchestration des tâches associées et au maintien de l'intégrité des transactions. Cependant, elle est également confrontée à des défis tels que le couplage temporel, la dépendance à la disponibilité et l'impact sur la qualité du réseau.

D'autre part, la communication asynchrone permet aux services de lancer des requêtes sans attendre une réponse immédiate, améliorant ainsi la réactivité et l'évolutivité du système. Il offre de la flexibilité et est idéal pour les scénarios dans lesquels un retour immédiat n'est pas requis. Cependant, cela entraîne des complexités en matière de résilience, de tolérance aux pannes, de traçage distribué, de débogage, de surveillance et de gestion des ressources.

En résumé, concevoir un système de communication robuste et résilient pour les applications cloud natives nécessite une compréhension approfondie des modèles de communication synchrones et asynchrones. En examinant attentivement les avantages et les inconvénients de chaque modèle et en les alignant sur les exigences, les architectes peuvent concevoir des systèmes qui orchestrent efficacement des éléments indépendants à l'intérieur et à l'extérieur des limites de l'application pour fournir des applications cloud natives hautes performances, évolutives et fiables.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!