protobuf vs gRPC

Question

J'essaie de comprendre protobuf et gRPC et comment je peux l'utiliser à la fois. Pourriez-vous m'aider à comprendre les éléments suivants:

• Considérant le modèle OSI qu'est-ce que, par exemple, est Protobuf à la couche 4?
• La pensée par le biais d'un transfert de message comment est le "flux" qu'est-ce que gRPC de faire ce que protobuf manque?
• Si l'expéditeur utilise protobuf peut l'utilisation du serveur de gRPC ou ne gRPC ajouter quelque chose gRPC client peut fournir?
• Si gRPC peut faire synchrone et asynchron de communication possible, Protobuf est juste pour le triage et à cet effet, n'a rien à voir avec l'état vrai ou faux?
• Puis-je utiliser gRPC dans une application frontend communication au lieu de REPOS ou de GraphQL?

Je sais déjà ou que je n' - que:

Protobuf

• Protocole binaire pour l'échange de données
• Conçu par Google
• Utilise des produits "Struct" comme la description au client et au serveur de l'onu-/-marshall message

gRPC

• Utilise protobuf (v3)
• Nouveau à partir de Google
• Cadre d'appels RPC
• Rend l'utilisation de HTTP/2 et
• Synchrone et asynchron communication possible

J'ai de nouveau assumer ses une question facile pour quelqu'un qui est déjà à l'aide de la technologie. Je voudrais vous remercier d'être patient avec moi et m'aider. Je serais vraiment reconnaissant pour tout réseau plongée profonde des technologies.

Answer 1

Protocol buffers est (sont?) un Langage de Définition d'Interface et la sérialisation de la bibliothèque:

• Vous définissez vos structures de données dans son IDL c'est à dire de décrire les objets de données que vous souhaitez utiliser
• Il fournit des routines de traduire vos objets de données vers et à partir de binaires, par exemple pour l'écriture/lecture de données à partir du disque

gRPC utilise le même IDL, mais ajoute à la syntaxe "rpc" qui permet de définir Appel de Procédure Distante signatures de méthode à l'aide de la Protobuf structures de données (types de données:

• Vous définissez vos structures de données
• Vous ajoutez votre rpc définitions de méthode
• Il fournit le code pour servir et appeler la méthode des signatures sur un réseau
• Vous pouvez toujours sérialiser les objets de données manuellement avec Protobuf si vous avez besoin de

En réponse aux questions:

1. gRPC travaille sur les couches 5, 6 et 7. Protobuf fonctionne au niveau de la couche 6.
2. Quand vous dites "transfert de message", Protobuf n'est pas concerné par le transfert lui-même. Il fonctionne uniquement à l'une des extrémités de transfert de données, en tournant octets dans les objets
3. À l'aide de gRPC par défaut signifie que vous utilisez Protobuf. Vous pouvez écrire votre propre client qui utilise Protobuf, mais pas gRPC pour interagir avec gRPC, ou un plugin d'autres sérialiseurs de gRPC - mais à l'aide de gRPC serait plus facile
4. Vrai
5. Oui, vous pouvez

Answer 2

En fait, gRPC et Protobuf sont 2 choses complètement différentes. Permettez-moi de simplifier:

• gRPC gère la façon dont un client et un serveur peut interagir (tout comme le web, client/serveur avec une API REST)
• protobuf est juste un de sérialisation/désérialisation de l'outil (tout comme JSON)

gRPC a 2 côtés: un côté serveur et côté client, qui est en mesure de composer un serveur. Le serveur expose Rpc (ie. fonctions que vous pouvez appeler à distance). Et vous avez beaucoup d'options: vous pouvez sécuriser la communication (à l'aide de TLS), ajouter de la couche d'authentification (à l'aide d'intercepteurs), ...

Vous pouvez utiliser protobuf à l'intérieur de n'importe quel programme, qui n'a pas besoin d'être client/serveur. Si vous avez besoin d'échanger des données, et que vous souhaitez être fortement typé, protobuf est une bonne option (rapide et fiable).

Cela étant dit, vous pouvez combiner les deux pour construire une belle client/serveur sytem: gRPC sera votre code de client/serveur, et protobuf vos données de protocole.

PS: j'ai écrit ce livre pour montrer comment on peut construire un client/serveur avec gRPC et protobuf utilisant Aller, étape par étape.

Answer 3

grpc est un cadre construit par google et il est utilisé dans les projets de production de google lui-même et #HyperledgerFabric est construit avec grpc il existe de nombreuses applications opensource construit avec grpc

protobuff est une représentation des données comme json c'est aussi par google en fait, ils ont quelques milliers de proto fichiers sont générés dans leurs projets de production

grpc

• gRPC est une structure open-source développé par google
• Il nous permet de créer de Demande et de Réponse pour le RPC et la poignée reste par le cadre
• Le REPOS est CRUD orienté, mais grpc est API orientée(pas de contraintes)
• Construire au-dessus de HTTP/2
• Offre >>>>> Auth, l'équilibrage de la charge, le Suivi, l'exploitation forestière
• [HTTP/2]
  • HTTP1.1 a publié, en 1997, il y a longtemps
  • HTTP1 ouvre une nouvelle connexion TCP vers un serveur à chaque requête
  • Il ne compresse pas les en-têtes
  • PAS de serveur push, il fonctionne avec Req, Res
  • HTTP2 publié en 2015 (SPDY)
  • Prend en charge le multiplexage
  • client et le serveur peuvent pousser des messages en parallèle sur la même connexion TCP
  • Considérablement réduit le temps de latence
  • HTTP2 supporte la compression d'en-tête
  • HTTP2 est binaire
    • proto buff est binaire, c'est donc un grand match pour HTTP2
• [TYPES]
  • Unaire
  • client de streaming
  • serveur de streaming
  • Bi directionnelle streaming
  • grpc serveurs sont Asynchrones par défaut
  • grpc, les clients peuvent être de synchronisation ou Asynchrone

protobuff

• Protocol buffers sont de langue agnostique
• L'analyse du protocole de tampons(format binaire) est moins consommateur d'UC
• [Indication]
  • L'utilisation de chameau cas pour les noms de message
  • underscore_seperated pour les champs
  • Utilisation camelcase pour les Énumérations et CAPITAL_WITH_UNDERSCORE pour les noms de valeur
• [Commentaires]
  • Support //
  • Support /* */
• [Avantages]
  • Les données sont entièrement Tapé
  • Les données sont compressées au maximum (moins de charge CPU)
  • Schéma(message) est nécessaire pour générer le code et lire le code
  • La Documentation peut être intégré dans le schéma
  • Les données peuvent être lues à travers n'importe quelle langue
  • Schéma peut évoluer à tout moment de façon sécuritaire
  • plus rapide que le XML
  • le code est généré automatiquement pour vous
  • Google a inventé proto buff, ils utilisent 48000 protobuf messages & 12000.proto fichiers
  • Beaucoup de RPC cadres, y compris grpc utiliser des tampons de protocole pour l'échange de données