Grpc ne prend-il en charge que le langage Go ?

grpc ne prend pas seulement en charge le langage go. grpc est un protocole de communication basé sur HTTP/2 et prend en charge le framework RPC multilingue ; fournit actuellement les versions des langages C, Java et Go, à savoir grpc, grpc-java, grpc-go ; la version C prend en charge C, C++, Node.js ; , Python, Ruby, Objective-C, PHP et C# pris en charge.

L'environnement d'exploitation de ce tutoriel : système Windows 7, GO version 1.18, ordinateur Dell G3.

Qu'est-ce que grpc

gRPC est un protocole de communication basé sur HTTP/2, prend en charge le framework RPC multilingue et est conçu pour les mobiles et HTTP/2. gRPC est conçu sur la base de la norme HTTP/2 et apporte des fonctionnalités telles que le streaming bidirectionnel, le contrôle de flux, la compression d'en-tête et le multiplexage des requêtes sur une seule connexion TCP. Ces fonctionnalités améliorent ses performances sur les appareils mobiles et permettent d'économiser de l'énergie et de l'espace.

RPC : L'abréviation de Remote Procedure Call, traduit par appel de procédure distante (traduit également par appel de méthode distante ou appel distant), c'est un protocole de communication informatique. Ce protocole peut rendre l'appel de services distants aussi simple que l'appel de services locaux, sans avoir à se soucier des problèmes inter-réseaux, multi-plateformes, multi-langues et autres.

La méthode de sérialisation des messages gRPC utilise généralement Protobuf, qui est un format binaire, de petite taille, rapide en transmission réseau, consomme moins de bande passante et de trafic et offre des performances d'appel plus élevées.

Fonctionnalités de gRPC

• IDL

  gRPC utilise ProtoBuf pour définir des services ProtoBuf est un protocole de sérialisation de données développé par Google (similaire à XML, JSON). ProtoBuf peut sérialiser les données et est largement utilisé dans le stockage de données, les protocoles de communication, etc.

• Prise en charge multilingue

  gRPC prend en charge plusieurs langues et peut générer automatiquement des bibliothèques de fonctions client et serveur basées sur la langue. Actuellement, la version C grpc, la version Java grpc-java et la version Go grpc-go sont fournies. Parmi elles, grpc prend en charge C, C++, Node.js, Python, Ruby, Objective-C, PHP et C# et d'autres langages. grpc-java prend en charge le développement Android.

• HTTP2

  gRPC est conçu sur la base de la norme HTTP2 et apporte des fonctionnalités plus puissantes, telles que le streaming bidirectionnel, la compression d'en-tête, les requêtes de multiplexage, etc. Ces fonctionnalités apportent des avantages significatifs tels que des économies de bande passante, des temps de liaison TCP réduits, des économies d'utilisation du processeur et une durée de vie prolongée de la batterie. Dans le même temps, gRPC peut également améliorer les performances des services cloud et des applications Web. gRPC peut être appliqué à la fois côté client et côté serveur, permettant ainsi une communication client-serveur de manière transparente et simplifiant la construction de systèmes de communication.

Pourquoi utilisons-nous grpc

• Bonne écologie : soutenue par Google. Par exemple, nginx prend également en charge grpc, lien de référence

• Cross-lingual : multilingue et génère automatiquement un sdk

• Hautes performances : par exemple, les performances de protobuf sont supérieures à celles de json, par exemple http2. 0 est supérieur à http1. 1

• Saisie forte : le compilateur résout de nombreux problèmes pour vous

• Traitement du streaming (basé sur http2.0) : prend en charge le streaming client, le streaming serveur et le streaming bidirectionnel

Comment les avantages de grpc sont-ils réalisés ?

1. Pourquoi protobuf est-il meilleur que json ?

1) Qu'est-ce que protobuf ?

• Protobuf est un format binaire développé par Google pour sérialiser les données entre différents services. C'est un langage IDL (langage de description d'interface)

2) À quel point est-il plus rapide que json ?

• Six fois plus rapide, Lien de référence

3) Pourquoi protobuf est-il plus rapide que json ?

• Le flux de données binaires et le flux de données json de protobuf sont comme indiqué ci-dessous

• En comparant les formats de données json et protobuf, nous pouvons savoir que
• Petite taille - aucun délimiteur requis : la méthode de stockage TLV ne nécessite pas de délimiteurs (virgules, guillemets doubles, etc.) pour séparer les champs, réduisant ainsi la utilisation de délimiteurs
• Petite taille - champs vides omis : Si le champ n'a aucune valeur de champ définie, alors les données lorsque le champ est sérialisé n'existent pas du tout, c'est-à-dire qu'aucun encodage n'est requis et json transmettra le key et la valeur de la valeur vide
• Petite taille - Représentation binaire de la balise : Il utilise la valeur numérique du champ puis la convertit en binaire pour la représentation. Elle est plus peu encombrante que la représentation sous forme de chaîne de la clé json.
• Encodage et décodage rapides : Le type du champ est stocké dans la balise, vous pouvez connaître directement la longueur de la valeur, ou lorsque la valeur est une chaîne, la longueur est utilisée pour stocker la longueur. octets après length pour obtenir la valeur de value. Si vous ne connaissez pas la longueur de value, nous devons faire une correspondance de chaîne
• Pour en savoir plus sur l'encodage protobuf, vous pouvez aller sur  : méthodes d'encodage varint et zigzag

2. Hautes performances de grpc : Pourquoi http2.0 est-il plus performant que http1.1 ?

1) Multiplexage

• http2.0 et http 1.* et comparaison de http1.1pipling

  Schéma schématique

• http/1. * : Une requête, une réponse, une connexion est établie et fermée après utilisation. Chaque requête doit établir une connexion
• pipeling http1.1 : la solution de pipeline consiste à mettre en file d'attente plusieurs requêtes pour un traitement sérialisé monothread, puis la requête attend. le retour de la requête précédente pour avoir la possibilité de s'exécuter. Une fois qu'une requête expire, les requêtes suivantes ne peuvent être bloquées, et il n'y a aucun moyen. C'est ce que les gens appellent souvent le blocage en tête de ligne
• http2 : Plusieurs requêtes peuvent être traitées en même temps Exécutées en parallèle sur une seule connexion. Une certaine tâche de requête prend beaucoup de temps et n'affectera pas l'exécution normale des autres connexions. Quels sont les autres avantages du multiplexage grpc ? Il réduit les connexions TCP et réduit les besoins en mémoire et en CPU du serveur et du client. attendre
• réduit les connexions TCP et garantit que le rétablissement de TCP n'est pas déclenché fréquemment, de sorte que les démarrages lents ne se produisent pas fréquemment réduit les connexions TCP et améliore la congestion du réseau
• Pourquoi le multiplexage http/1.1 ne peut pas être réalisé mais http2. 0 peut ?
• Parce que http/1.1 utilise du texte pour la transmission, tandis que http2.0 utilise une transmission de trame binaire
2) Compression d'en-tête

 : http peut être associé à http Le corps est gzip compressé, ce qui peut économiser de la bande passante. Cependant, il existe également de nombreux champs dans l'en-tête du message qui ne sont pas compressés, tels que les cookies et l'acceptation de l'agent utilisateur. Ceux-ci doivent être compressés

 : Il y en a beaucoup. les demandes et les réponses dans le message. De nombreuses valeurs de champ sont répétées, il est donc nécessaire d'éviter la duplication
• Amélioration de l'encodage
 : Les champs sont codés en ascii, ce qui est inefficace. Le passage au codage binaire peut s'améliorer
• Ce qui précède est. implémenté via l'algorithme HPACK
. L'algorithme comprend principalement trois parties
• Dictionnaire statique : organisez les champs d'en-tête couramment utilisés dans un dictionnaire, tel que {":method":"GET"}, qui peut être représenté par un seul nombre. 2
• Dictionnaire dynamique : certains en-têtes qui ne sont pas dans le dictionnaire statique Champ, utilisez un dictionnaire dynamique Encodage Huffman : encodage par compression
• 3) Cadrage binaire
Sur la couche de cadrage binaire, HTTP 2.0 divisera toutes les informations transmises dans des messages et des trames plus petits, et les coder au format binaire, où les informations d'en-tête de HTTP1.x seront encapsulées dans la trame d'en-têtes et le corps de notre requête sera encapsulé dans la trame de données.

Après avoir été encadrés de cette manière, ces cadres peuvent être envoyés dans le désordre, puis assemblés en fonction de l'identifiant de flux dans l'en-tête de chaque cadre

Parce qu'il est basé sur du texte et utilise des sauts de ligne. pour séparer chaque clé : valeur. Les problèmes suivants :
• Une seule demande ou réponse peut être traitée à la fois, car ce type de données qui sépare les messages par des délimiteurs ne peut pas arrêter l'analyse avant qu'elle ne soit terminée
• Il est impossible de prédire combien de mémoire est nécessaire pour analyser ce type de données, ce qui causera beaucoup de problèmes au serveur Grande pression
• 4) Le serveur pousse activement les ressources
• • Étant donné que le serveur est pris en charge pour pousser activement les ressources, certaines requêtes peuvent être omises. Par exemple, si vous avez besoin de deux fichiers 1.html et 1.css, s'il s'agit de http1.0, vous devez le demander deux fois et le serveur le renverra deux fois. Mais http2.0 permet au client de demander une fois, puis le serveur répond directement deux fois

  Pour plus de connaissances sur la programmation, veuillez visiter : Introduction à la programmation ! !

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!