Qu'est-ce que le gRPC? Explication des tampons de protocole, du streaming et de l'architecture

gRPC est un cadre puissant pour travailler avec les appels de procédure à distance. Les RPC vous permettent d'écrire du code comme s'il était exécuté sur un ordinateur local, même s'il peut être exécuté sur un autre ordinateur.

Ces derniers jours, j'ai plongé profondément dans le gRPC. Je vais partager certaines de mes grandes découvertes ici dans cet article.

Notez que je me concentrerai davantage sur les concepts que sur les détails de mise en œuvre. Vous apprendrez l'architecture de base de gRPC lui-même. Vous apprendrez également:

  • Pourquoi gRPC est si largement utilisé par les développeurs
  • Comment ça marche si bien
  • Et comment tout cela fonctionne sous le capot.

Revenons un peu en arrière

Avant de nous précipiter dans gRPC, nous devrions jeter un coup d'œil à ce que sont les appels de procédure à distance .

Un RPC est une forme de communication client-serveur qui utilise un appel de fonction plutôt qu'un appel HTTP habituel.

Il utilise IDL (Interface Definition Language) comme une forme de contrat sur les fonctions à appeler et sur le type de données.

Si vous ne l'avez pas encore réalisé, le RPC dans gRPC signifie Remote Procedure Call. Et oui, gRPC reproduit ce style architectural de communication client-serveur, via des appels de fonction.

Le gRPC n'est donc techniquement pas un nouveau concept. Il a plutôt été adopté à partir de cette ancienne technique et amélioré, ce qui le rend très populaire en l'espace de 5 ans seulement.

Vue d'ensemble du gRPC

En 2015, Google a ouvert son projet qui serait finalement celui appelé gRPC. Mais que signifie réellement le "g" dans gRPC?

Beaucoup de gens pourraient supposer que c'est pour Google parce que Google l'a créé, mais ce n'est pas le cas.

Google modifie la signification du "g" pour chaque version au point où ils ont même fait un README pour lister toutes les significations.

Depuis que le gRPC a été introduit, il a gagné en popularité et de nombreuses entreprises l'utilisent.

Qu'est-ce qui rend le gRPC si populaire?

Il y a de nombreuses raisons pour lesquelles gRPC est si populaire:

  • L'abstraction est facile (c'est un appel de fonction)
  • Il est pris en charge dans de nombreuses langues
  • C'est très performant
  • Les appels HTTP sont souvent déroutants, donc cela facilite les choses

Et mis à part toutes les raisons ci-dessus, gRPC est populaire car les microservices sont très populaires.

Les microservices exécutent souvent plusieurs services dans différents langages de programmation. Ils auront également souvent beaucoup d'interactions de service à service.

C'est là que gRPC aide le plus en fournissant le soutien et la capacité de résoudre les problèmes typiques qui découlent de ces situations.

gRPC est très populaire dans les services aux appels de service, car les appels HTTP sont souvent plus difficiles à comprendre à première vue.

Les fonctions gRPC sont beaucoup plus faciles à raisonner, donc les développeurs n'ont pas à se soucier d'écrire beaucoup de documentation car le code lui-même devrait tout expliquer.

Certains des services peuvent également être écrits dans différentes langues et gRPC est fourni avec plusieurs bibliothèques pour prendre en charge cela.

La performance est la cerise sur le gâteau - et c'est une grande cerise.

Architecture gRPC

J'ai mentionné à plusieurs reprises que les performances du gRPC sont très bonnes, mais vous vous demandez peut-être ce qui le rend si bon? Qu'est-ce qui rend gRPC tellement meilleur que RPC lorsque leurs conceptions sont assez similaires?

Voici quelques différences clés qui rendent gRPC si performant.

HTTP / 2

HTTP est avec nous depuis longtemps. Désormais, presque tous les services backend utilisent ce protocole.

Comme le montre l'image ci-dessus, HTTP / 1.1 est resté pertinent pendant longtemps.

Puis en 2015, HTTP / 2 est sorti et a essentiellement remplacé HTTP / 1.1 comme protocole de transport le plus populaire sur Internet.

Si vous vous souvenez que 2015 a également été l'année de la sortie du gRPC, ce n'était pas du tout une coïncidence. HTTP / 2 a également été créé par Google pour être utilisé par gRPC dans son architecture.

HTTP / 2 est l'une des principales raisons pour lesquelles gRPC peut fonctionner si bien. Et dans cette section suivante, vous verrez pourquoi.

Multiplexage demande / réponse

Dans un protocole HTTP traditionnel, il n'est pas possible d'envoyer plusieurs requêtes ou d'obtenir plusieurs réponses ensemble dans une seule connexion. Une nouvelle connexion devra être créée pour chacun d'eux.

Ce type de multiplexage requête / réponse est rendu possible dans HTTP / 2 avec l'introduction d'une nouvelle couche HTTP / 2 appelée trame binaire.

Cette couche binaire encapsule et code les données. Dans cette couche, la requête / réponse HTTP est décomposée en cadres.

La trame d'en-têtes contient des informations d'en-têtes HTTP typiques et la trame de données contient la charge utile. En utilisant ce mécanisme, il est possible d'avoir des données de plusieurs demandes dans une seule connexion.

Cela permet des charges utiles de plusieurs demandes avec le même en-tête, l'identifiant ainsi comme une seule demande.

Compression d'en-tête

Vous avez peut-être rencontré de nombreux cas où les en-têtes HTTP sont encore plus gros que la charge utile. Et HTTP / 2 a une stratégie très intéressante appelée HPack pour gérer cela.

D'une part, tout dans HTTP / 2 est encodé avant d'être envoyé, y compris les en-têtes. Cela améliore les performances, mais ce n'est pas la chose la plus importante à propos de la compression d'en-tête.

HTTP / 2 mappe l'en-tête à la fois côté client et côté serveur. À partir de là, HTTP / 2 est capable de savoir si l'en-tête contient la même valeur et n'envoie la valeur d'en-tête que si elle est différente de l'en-tête précédent.

Comme le montre l'image ci-dessus, la requête n ° 2 n'enverra que le chemin puisque les autres valeurs sont exactement les mêmes. Et oui, cela réduit beaucoup la taille de la charge utile et améliore encore plus les performances de HTTP / 2.

Tampon de protocole, alias Protobuf

Protobuf est l'IDL (Interface Definition Language) le plus couramment utilisé pour gRPC. C'est là que vous stockez essentiellement vos données et vos contrats de fonction sous la forme d'un fichier proto.

message Person { required string name = 1; required int32 id = 2; optional string email = 3; }

Comme cela prend la forme d'un contrat, le client et le serveur doivent avoir le même fichier proto. Le fichier proto sert de contrat intermédiaire pour que le client appelle toutes les fonctions disponibles à partir du serveur.

Protobuf possède également des mécanismes, contrairement à une API REST habituelle qui envoie simplement des chaînes de JSON sous forme d'octets. Ces mécanismes permettent à la charge utile d'être beaucoup plus petite et permettent des performances plus rapides.

La méthode d'encodage utilisée par Protobuf est assez compliquée. Si vous souhaitez approfondir son fonctionnement, consultez cette documentation complète.

Qu'est-ce que gRPC offre d'autre?

Les étoiles dans le ciel

Vous devriez maintenant avoir une compréhension de base de l'architecture de gRPC, de son fonctionnement et de ses capacités.

Mais voici quelques autres choses intéressantes que nous offre gRPC.

Métadonnées

Au lieu d'utiliser un en-tête de requête HTTP habituel, gRPC a quelque chose appelé métadonnées. Les métadonnées sont un type de données clé-valeur qui peuvent être définies du côté client ou du côté serveur.

Headerpeuvent être attribués du côté client, tandis que les serveurs peuvent attribuer Headeret Trailerstant qu'ils sont tous les deux sous la forme de métadonnées.

Diffusion

Le streaming est l'un des concepts de base de gRPC où plusieurs choses peuvent se produire en une seule demande. Ceci est rendu possible par la capacité de multiplexage de HTTP / 2 mentionnée précédemment.

Il existe plusieurs types de streaming:

  • Server Streaming RPC: où le client envoie une seule demande et le serveur peut renvoyer plusieurs réponses. Par exemple, lorsqu'un client envoie une demande pour une page d'accueil contenant une liste de plusieurs éléments, le serveur peut renvoyer des réponses séparément, ce qui permet au client d'utiliser le chargement différé.
  • Client Streaming RPC: où le client envoie plusieurs demandes et le serveur ne renvoie qu'une seule réponse. Par exemple, un zip / morceau téléchargé par le client.
  • Bidirectional Streaming RPC: où le client et le serveur s'envoient des messages en même temps sans attendre de réponse.

Intercepteurs

gRPC prend en charge l'utilisation d'intercepteurs pour sa demande / réponse. Les intercepteurs, eh bien, interceptent les messages et vous permettent de les modifier.

Cela vous semble-t-il familier? Si vous avez joué avec les processus HTTP sur une API REST, les intercepteurs sont très similaires au middleware.

Les bibliothèques gRPC prennent généralement en charge les intercepteurs et permettent une implémentation facile. Les intercepteurs sont généralement utilisés pour:

  • Modifiez la requête / réponse avant d'être transmise. Il peut être utilisé pour fournir des informations obligatoires avant d'être envoyé au client / serveur.
  • Vous permet de manipuler chaque appel de fonction, par exemple en ajoutant une journalisation supplémentaire pour suivre le temps de réponse.

L'équilibrage de charge

Si vous n'êtes pas déjà familiarisé avec l'équilibrage de charge, il s'agit d'un mécanisme qui permet aux demandes des clients d'être réparties sur plusieurs serveurs.

Mais l'équilibrage de charge est généralement effectué au niveau du proxy (par exemple, NGINX). Alors pourquoi en parle-je ici?

Il s'avère que gRPC prend en charge une méthode d'équilibrage de charge par le client. Il est déjà implémenté dans la bibliothèque Golang et peut être utilisé facilement.

Bien que cela puisse sembler une sorte de magie folle, ce n'est pas le cas. Il existe une sorte de résolveur DNS pour obtenir une liste d'adresses IP et un algorithme d'équilibrage de charge sous le capot.

Annulation d'appel

Les clients gRPC peuvent annuler un appel gRPC lorsqu'il n'a plus besoin de réponse. La restauration côté serveur n'est cependant pas possible.

Cette fonctionnalité est particulièrement utile pour le streaming côté serveur où plusieurs demandes de serveur peuvent arriver. La bibliothèque gRPC est équipée d'un modèle de méthode d'observateur pour savoir si une demande est annulée et lui permettre d'annuler plusieurs demandes correspondantes à la fois.

Emballer

Perdu dans l'espace et le temps

Tout ce que j'ai partagé aujourd'hui ne fait qu'effleurer la surface de ce qu'est le gRPC, ce dont il est capable et à peu près comment il fonctionne.

J'espère vraiment que cet article vous a aidé à mieux comprendre le gRPC. Mais il y a encore beaucoup à apprendre, alors ne vous arrêtez pas ici! Continue à creuser.

Merci d'avoir lu!