web-dev-qa-db-fra.com

protobuf vs gRPC

J'essaie de comprendre protobuf et gRPC et comment utiliser les deux. Pourriez-vous m'aider à comprendre ce qui suit:

  • En considérant le modèle OSI, que fait-on, par exemple, Protobuf est-il au niveau 4?
  • En réfléchissant à un transfert de message, quel est le "flux", que fait gRPC, que manque-t-il à Protobuf?
  • Si l'expéditeur utilise protobuf, le serveur peut-il utiliser gRPC ou est-ce que gRPC ajoute quelque chose que seul un client gRPC peut fournir?
  • Si gRPC peut rendre la communication synchrone et asynchrone possible, Protobuf est juste pour le marshalling et n'a donc rien à voir avec l'état - vrai ou faux?
  • Puis-je utiliser gRPC dans une application frontale communiquant au lieu de REST ou GraphQL?)

Je sais déjà - ou suppose que je le sais - que:

Protobuf

  • Protocole binaire pour l'échange de données
  • Conçu par Google
  • Utilise la "structure" générée telle que la description sur le client et le serveur pour désarchiver le message -/- marshall

gRPC

  • Utilise protobuf (v3)
  • Encore de Google
  • Cadre pour les appels RPC
  • Utilise aussi HTTP/2
  • Communication synchrone et asynchrone possible

Je suppose encore une fois que c'est une question facile pour quelqu'un qui utilise déjà la technologie. Je voudrais quand même vous remercier d'être patient avec moi et de m'aider. Je serais également très reconnaissant pour toute analyse approfondie des technologies par réseau.

networkingprotocol-buffersgrpc
45
lony

Tampons de protocole est une bibliothèque de langages de définition d’interface et de sérialisation:

  • Vous définissez vos structures de données dans son IDL, c'est-à-dire décrivez les objets de données que vous souhaitez utiliser.
  • Il fournit des routines pour traduire vos objets de données en binaire, par exemple. pour écrire/lire des données à partir du disque

gRPC utilise le même IDL mais ajoute la syntaxe "rpc" qui vous permet de définir les signatures de méthode d'appel de procédure distante à l'aide des structures de données Protobuf en tant que types de données:

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

En réponse aux questions:

  1. le gRPC fonctionne aux couches 5, 6 et 7. Protobuf fonctionne à la couche 6.
  2. Lorsque vous dites "transfert de message", Protobuf n'est pas concerné par le transfert lui-même. Cela ne fonctionne qu'aux deux extrémités d'un transfert de données, transformant des octets en objets
  3. Utiliser par défaut gRPC signifie vous utilisez Protobuf. Vous pouvez écrire votre propre client qui utilise Protobuf mais pas gRPC pour interagir avec gRPC, ou branchez d'autres sérialiseurs à gRPC - mais utiliser gRPC serait plus facile.
  4. Vrai
  5. Oui, vous pouvez
43
Peter Wishart

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

  • le gRPC gère la façon dont un client et un serveur peuvent interagir (comme un client/serveur Web avec une API REST)).
  • protobuf est juste un outil de sérialisation/désérialisation (comme JSON)

le gRPC a 2 côtés: un côté serveur et un côté client, qui peut appeler un serveur. Le serveur expose les RPC (c'est-à-dire les fonctions que vous pouvez appeler à distance). Et vous disposez de nombreuses options: vous pouvez sécuriser la communication (avec TLS), ajouter une couche d’authentification (avec des intercepteurs), ...

Vous pouvez utiliser protobuf dans n’importe quel programme qui n’a pas besoin d’être client/serveur. Si vous souhaitez échanger des données et que vous souhaitez qu'elles soient fortement typées, protobuf est une option intéressante (rapide et fiable).

Cela dit, vous pouvez combiner les deux pour créer un système client/serveur Nice: gRPC sera votre code client/serveur et protobuf votre protocole de données.

PS: J'ai écrit ceci papier pour montrer comment construire un client/serveur avec gRPC et protobuf en utilisant Go, étape par étape.

43
chilladx

grpc est un framework créé par google et utilisé dans les projets de production à partir de google même. #HyperledgerFabric est construit avec grpc. Il existe de nombreuses applications opensource construites avec grpc.

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

grpc

  • gRPC est un framework open-source développé par Google
  • Cela nous permet de créer une demande et une réponse pour RPC et de gérer le repos par la structure
  • REST est orienté CRUD mais grpc est orienté API (aucune contrainte)
  • Construire sur HTTP/2
  • Fournit >>>>> Auth, Loadbalancing, Monitoring, logging
  • [HTTP/2]
    • HTTP1.1 est sorti en 1997 il y a longtemps
    • HTTP1 ouvre une nouvelle connexion TCP) à un serveur à chaque demande
    • Il ne compresse pas les en-têtes
    • AUCUN serveur Push, cela fonctionne simplement avec Req, Res
    • HTTP2 publié en 2015 (SPDY)
    • Prend en charge le multiplexage
    • le client et le serveur peuvent envoyer des messages en parallèle sur le même TCP connexion
    • Réduit considérablement la latence
    • HTTP2 prend en charge la compression d'en-tête
    • HTTP2 est binaire
      • proto buff est binaire, donc c'est un bon match pour HTTP2
  • [LES TYPES]
    • Unaire
    • streaming client
    • serveur en streaming
    • Streaming bi-directionnel
    • les serveurs grpc sont asynchrones par défaut
    • les clients grpc peuvent être synchronisés ou asynchrones

protobuff

  • Les tampons de protocole sont indépendants de la langue
  • L'analyse des tampons de protocole (format binaire) nécessite moins de ressources en ressources processeur
  • [Appellation]
    • Utiliser une casse de chameau pour les noms de message
    • underscore_seperated pour les champs
    • Utilisez camelcase pour Enums et CAPITAL_WITH_UNDERSCORE pour les noms de valeur
  • [Commentaires]
    • Soutien //
    • Soutien /* */
  • [Avantages]
    • Les données sont entièrement dactylographiées
    • Les données sont entièrement compressées (moins d'utilisation du processeur)
    • Un schéma (message) est nécessaire pour générer du code et le lire.
    • La documentation peut être incorporée dans le schéma
    • Les données peuvent être lues dans n'importe quelle langue
    • Le schéma peut évoluer à tout moment de manière sécurisée
    • plus rapide que XML
    • le code est généré automatiquement pour vous
    • Google a inventé le proto buff, il utilise 48 000 messages protobuf et 12000.proto.
    • De nombreux frameworks RPC, y compris grpc, utilisent des tampons de protocole pour échanger des données
0
Narendranath Reddy