Modèles de communication cloud natifs

Conseil

Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.

Télécharger le PDF

Lors de la création d’une application native cloud, la communication devient une décision de conception importante. Comment une application cliente front-end communique-t-elle avec un microservice back-end ? Comment les microservices back-end communiqueront-ils entre eux ? Quels sont les principes, les modèles et les meilleures pratiques à prendre en compte lors de l’implémentation de la communication dans des applications natives cloud ?

Considérations relatives à la communication

Dans une application monolithique, la communication est simple. Les modules de code s’exécutent ensemble dans le même espace exécutable (processus) sur un serveur. Cette approche peut présenter des avantages en matière de performances, car tout s’exécute ensemble en mémoire partagée, mais elle génère un code étroitement couplé qui devient difficile à maintenir, à faire évoluer et à mettre à l’échelle.

Les systèmes natifs cloud implémentent une architecture basée sur des microservices avec de nombreux microservices indépendants de petite taille. Chaque microservice s’exécute dans un processus distinct et s’exécute généralement à l’intérieur d’un conteneur déployé sur un cluster.

Un cluster regroupe un pool de machines virtuelles pour former un environnement hautement disponible. Ils sont gérés avec un outil d’orchestration, qui est responsable du déploiement et de la gestion des microservices conteneurisés. La Figure 4-1 montre un cluster Kubernetes déployé dans le cloud Azure avec une instance Azure Kubernetes Services complètement managée.

Figure 4-1. Un cluster Kubernetes dans Azure

Au sein du cluster, les microservices communiquent entre eux par le biais des API et des technologies de messagerie.

Bien qu’ils offrent de nombreux avantages, les microservices ne sont pas gratuits. Les appels de méthode in-process locaux entre les composants sont maintenant remplacés par des appels réseau. Chaque microservice doit communiquer sur un protocole réseau, ce qui ajoute de la complexité à votre système :

• La congestion du réseau, la latence et les erreurs temporaires sont des problèmes constants.

• La résilience (autrement dit, la nouvelle tentative d’exécution de requêtes ayant échoué) est essentielle.

• Certains appels doivent être idempotents pour maintenir un état cohérent.

• Chaque microservice doit authentifier et autoriser les appels.

• Chaque message doit être sérialisé, puis désérialisé, ce qui peut être coûteux.

• Le chiffrement/déchiffrement des messages devient important.

L’ouvrage .NET Microservices : Architecture pour les applications .NET en conteneur, disponible gratuitement auprès de Microsoft, fournit une couverture approfondie des modèles de communication pour les applications de microservice. Dans ce chapitre, nous fournissons une vue d’ensemble générale de ces modèles, ainsi que des options d’implémentation disponibles dans le cloud Azure.

Dans ce chapitre, nous allons d’abord traiter la communication entre les applications front-end et les microservices back-end. Nous allons ensuite voir comment les microservices back-end communiquent entre eux. Nous allons explorer les technologies de communication up et gRPC. Enfin, nous allons passer en revue de nouveaux modèles de communication innovants qui utilisent la technologie de maillage de services. Nous verrons également comment le cloud Azure fournit différents types de services de stockage pour prendre en charge la communication native cloud.

PrécédentSuivant