gRPC

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

Jusqu’à présent dans ce livre, nous nous sommes concentrés sur la communication basée sur REST. Nous avons vu que REST est un style architectural flexible qui définit des opérations CRUD sur des ressources d’entité. Les clients interagissent avec des ressources sur HTTP avec un modèle de communication de requête/réponse. Bien que REST soit largement implémenté, une technologie de communication plus récente, gRPC, a gagné un énorme élan dans la communauté native Cloud.

Qu’est-ce que gRPC ?

gRPC est un framework moderne et hautes performances qui évolue avec le protocole RPC (Remote Procedure Call, appel de procédure distante). Au niveau de l’application, gRPC simplifie la messagerie entre les clients et les services principaux. Provenant de Google, gRPC est open source et fait partie de l’écosystème Cloud native computing Foundation (CNCF) des offres natives Cloud. Le CNCF considère gRPC comme un projet d’incubation. L’incubation signifie que les utilisateurs finaux utilisent la technologie dans les applications de production, et que le projet a un nombre sain de contributeurs.

Une application cliente gRPC classique expose une fonction locale in-process qui implémente une opération métier. En coulisse, cette fonction locale appelle une autre fonction sur un ordinateur distant. Ce qui semble être un appel local devient essentiellement un appel transparent hors processus à un service distant. La plomberie RPC extrait la communication réseau point à point, la sérialisation et l’exécution entre les ordinateurs.

Dans les applications natives Cloud, les développeurs travaillent souvent entre des langages de programmation, des infrastructures et des technologies. Cette interopérabilité complique les contrats de message et la plomberie requise pour la communication multiplateforme. gRPC fournit une « couche horizontale uniforme » qui récupère ces préoccupations. Les développeurs codent dans leur plateforme native axée sur les fonctionnalités métier, tandis que gRPC gère la plomberie des communications.

gRPC offre une prise en charge complète sur les piles de développement les plus populaires, notamment Java, JavaScript, C#, Go, Swift et NodeJS.

Avantages gRPC

gRPC utilise HTTP/2 pour son protocole de transport. Bien que compatible avec HTTP 1.1, HTTP/2 offre de nombreuses fonctionnalités avancées :

• Protocole d’encadrement binaire pour le transport de données, contrairement à HTTP 1.1, qui est basé sur du texte.
• Prise en charge du multiplexage pour l’envoi de plusieurs requêtes parallèles sur la même connexion : HTTP 1.1 limite le traitement à un message de requête/réponse à la fois.
• Communication bidirectionnelle en duplex intégral pour l’envoi simultané des requêtes clientes et des réponses du serveur.
• Diffusion en continu intégrée permettant aux requêtes et aux réponses de diffuser en continu de manière asynchrone des jeux de données volumineux.
• Compression d’en-tête qui réduit l’utilisation du réseau.

gRPC est léger et hautement performant. Il peut être jusqu’à 8 fois plus rapide que la sérialisation JSON avec des messages de 60 à 80 % plus petits. Dans la terminologie Windows Communication Foundation (WCF) Microsoft, les performances gRPC dépassent la vitesse et l’efficacité des liaisons NetTCP hautement optimisées. Contrairement à NetTCP, qui favorise la pile Microsoft, gRPC est multiplateforme.

Mémoires tampon de protocole

gRPC adopte une technologie open source appelée tampons de protocole. Ils fournissent un format de sérialisation hautement efficace et neutre sur la plateforme pour sérialiser des messages structurés que les services envoient les uns aux autres. À l’aide d’un langage IDL (Interface Definition Language) multiplateforme, les développeurs définissent un contrat de service pour chaque microservice. Le contrat, implémenté en tant que fichier textuel .proto , décrit les méthodes, les entrées et les sorties pour chaque service. Le même fichier de contrat peut être utilisé pour les clients et services gRPC basés sur différentes plateformes de développement.

À l’aide du fichier proto, le compilateur Protobuf, protoc, génère à la fois du code client et de service pour votre plateforme cible. Le code comprend les composants suivants :

• Objets fortement typés, partagés par le client et le service, qui représentent les opérations de service et les éléments de données d’un message.
• Classe de base fortement typée avec la plomberie réseau requise que le service gRPC distant peut hériter et étendre.
• Stub client qui contient la plomberie requise pour appeler le service gRPC distant.

Au moment de l’exécution, chaque message est sérialisé en tant que représentation Protobuf standard et échangé entre le client et le service distant. Contrairement à JSON ou XML, les messages Protobuf sont sérialisés en tant qu’octets binaires compilés.

Prise en charge de gRPC dans .NET

gRPC est intégré au SDK .NET Core 3.0 et versions ultérieures. Les outils suivants le prennent en charge :

• Visual Studio 2022 avec la charge de travail ASP.NET et développement web installée
• Visual Studio Code
• CLI dotnet

Le kit de développement logiciel (SDK) inclut des outils pour le routage des points de terminaison, l’IoC intégré et la journalisation. Le serveur web Kestrel open source prend en charge les connexions HTTP/2. La figure 4-20 montre un modèle Visual Studio 2022 qui structure un projet squelette pour un service gRPC. Notez comment .NET prend entièrement en charge Windows, Linux et macOS.

Figure 4-20. Prise en charge gRPC dans Visual Studio 2022

La figure 4-21 montre le service gRPC squelette généré à partir de la structure intégrée incluse dans Visual Studio 2022.

Figure 4-21. Nouveau projet gRPC dans Visual Studio 2022

Dans la figure précédente, notez le fichier de description proto et le code de service. Comme vous le verrez sous peu, Visual Studio génère une configuration supplémentaire dans la classe Startup et le fichier projet sous-jacent.

Utilisation de gRPC

Privilégiez gRPC pour les scénarios suivants :

• Communication de microservice à microservice back-end synchrone dans laquelle une réponse immédiate est nécessaire pour poursuivre le traitement.
• Environnements polyglottes qui doivent prendre en charge des plateformes de programmation mixtes.
• Faible latence et communication à débit élevé où les performances sont critiques.
• Communication en temps réel point à point : gRPC peut envoyer des messages en temps réel sans interrogation et offre une excellente prise en charge de la diffusion en continu bidirectionnelle.
• Environnements contraintes réseau : les messages gRPC binaires sont toujours plus petits qu’un message JSON textuel équivalent.

À l’heure de la rédaction de cette section, gRPC est principalement utilisé avec les services back-end. Les navigateurs modernes ne peuvent pas fournir le niveau de contrôle HTTP/2 requis pour prendre en charge un client gRPC front-end. Cela dit, il existe une prise en charge de gRPC-Web avec .NET qui permet la communication gRPC à partir d’applications basées sur un navigateur créées avec JavaScript ou des technologies Blazor WebAssembly. gRPC-Web permet à une application gRPC ASP.NET Core de prendre en charge les fonctionnalités gRPC dans les applications de navigateur :

• Clients fortement typés et générés par du code
• Messages Protobuf compacts
• Diffusion en continu du serveur

Implémentation gRPC

L’architecture de référence des microservices, eShop sur Conteneurs, de Microsoft, montre comment implémenter des services gRPC dans des applications .NET. La figure 4-22 présente l’architecture back-end.

Figure 4-22. Architecture back-end pour eShop sur conteneurs

Dans la figure précédente, notez comment eShop adopte le modèle back-end pour front-ends (BFF) en exposant plusieurs passerelles API. Nous avons discuté du modèle BFF plus haut dans ce chapitre. Portez une attention particulière au microservice Aggregator (en gris) qui se trouve entre la passerelle API Web-Shopping et les microservices Shopping back-end. L’agrégateur reçoit une requête unique d’un client, la distribue à différents microservices, agrège les résultats et les renvoie au client demandeur. Ces opérations nécessitent généralement une communication synchrone pour produire une réponse immédiate. Dans eShop, les appels principaux de l’agrégateur sont effectués à l’aide de gRPC, comme illustré dans la figure 4-23.

Figure 4-23. gRPC dans eShop sur Conteneurs

La communication gRPC nécessite à la fois les composants client et serveur. Dans la figure précédente, notez comment l’agrégateur Shopping implémente un client gRPC. Le client effectue des appels gRPC synchrones (en rouge) à des microservices back-end, chacun implémentant un serveur gRPC. Le client et le serveur tirent parti de la plomberie gRPC intégrée à partir du SDK .NET. Les stubs côté client fournissent la plomberie pour appeler des appels gRPC distants. Les composants côté serveur fournissent la plomberie gRPC que les classes de service personnalisées peuvent hériter et consommer.

Les microservices qui exposent une API RESTful et une communication gRPC nécessitent plusieurs points de terminaison pour gérer le trafic. Vous ouvrez un point de terminaison qui écoute le trafic HTTP pour les appels RESTful et un autre pour les appels gRPC. Le point de terminaison gRPC doit être configuré pour le protocole HTTP/2 requis pour la communication gRPC.

Bien que nous nous efforçons de dissocier les microservices avec des modèles de communication asynchrones, certaines opérations nécessitent des appels directs. gRPC doit être le choix principal pour la communication synchrone directe entre les microservices. Son protocole de communication hautes performances, basé sur HTTP/2 et les mémoires tampons de protocole, en fait le choix parfait.

Perspectives

À l’avenir, gRPC continuera à tirer parti des systèmes natifs cloud. Les avantages en matière de performances et la facilité de développement sont attrayants. Toutefois, REST sera probablement utilisé pendant longtemps. Il excelle pour les API exposées publiquement et pour des raisons de compatibilité descendante.

PrécédentSuivant