wake-up-neo.com

protobuf vs gRPC

Ich versuche protobuf und gRPC zu verstehen und wie ich beides nutzen kann. Könnten Sie mir helfen, Folgendes zu verstehen:

  • Betrachtet man das OSI-Modell, wie sieht es zum Beispiel mit Protobuf auf Schicht 4 aus?
  • Überlegen Sie sich eine Nachrichtenübermittlung, wie fließt sie? Was macht gRPC, was protobuf vermisst?
  • Wenn der Absender protobuf verwendet, kann der Server gRPC verwenden oder fügt gRPC etwas hinzu, das nur ein gRPC-Client liefern kann?
  • Wenn gRPC eine synchrone und asynchrone Kommunikation ermöglichen kann, dient Protobuf nur dem Marshalling und hat daher nichts mit state zu tun - true oder false?
  • Kann ich gRPC in einer Frontend-Anwendung verwenden, die anstelle von REST oder GraphQL kommuniziert?

Ich weiß - oder nehme an, ich weiß - dass:

Protobuf

  • Binärprotokoll für den Datenaustausch
  • Entworfen von Google
  • Verwendet generierte "Struct" -Beschreibungen auf Client und Server, um die Marshall-Meldung zu entfernen

gRPC

  • Verwendet protobuf (v3)
  • Wieder von Google
  • Framework für RPC-Aufrufe
  • Verwendet auch HTTP/2
  • Synchrone und asynchrone Kommunikation möglich

Ich gehe wieder davon aus, dass es für jemanden, der die Technologie bereits einsetzt, eine einfache Frage ist. Ich würde mich immer noch bei dir bedanken, dass du geduldig mit mir bist und mir hilfst. Ich wäre auch sehr dankbar für jeden Netzwerk-Deep-Dive der Technologien.

networkingprotocol-buffersgrpc
45
lony

Protokollpuffer ist (sind?) Eine Interface Definition Language und eine Serialisierungsbibliothek:

  • Sie definieren Ihre Datenstrukturen in ihrer IDL, d. H. Beschreiben die Datenobjekte, die Sie verwenden möchten
  • Es bietet Routinen zum Übersetzen Ihrer Datenobjekte in und aus Binärdateien, z. zum Schreiben/Lesen von Daten von der Festplatte

gRPC verwendet dieselbe IDL, fügt jedoch die Syntax "rpc" hinzu, mit der Sie Remote Procedure Call-Methodensignaturen mithilfe der Protobuf-Datenstrukturen als Datentypen definieren können:

  • Sie definieren Ihre Datenstrukturen
  • Sie fügen Ihre RPC-Methodendefinitionen hinzu
  • Es bietet Code zum Bereitstellen und Aufrufen der Methodensignaturen über ein Netzwerk
  • Sie können die Datenobjekte bei Bedarf weiterhin manuell mit Protobuf serialisieren

Zur Beantwortung der Fragen:

  1. gRPC funktioniert auf den Ebenen 5, 6 und 7. Protobuf funktioniert auf der Ebene 6.
  2. Wenn Sie "Nachrichtenübertragung" sagen, ist Protobuf nicht mit der Übertragung selbst befasst. Es funktioniert nur an beiden Enden einer Datenübertragung und verwandelt Bytes in Objekte
  3. Die Verwendung von gRPC bedeutet standardmäßig Sie verwenden Protobuf. Sie könnten Ihren eigenen Client schreiben, der Protobuf, aber nicht gRPC für die Interoperabilität mit gRPC verwendet, oder andere Serializer in gRPC einbinden - die Verwendung von gRPC wäre jedoch einfacher
  4. Wahr
  5. Ja, du kannst
43
Peter Wishart

Eigentlich sind gRPC und Protobuf zwei völlig verschiedene Dinge. Lassen Sie mich vereinfachen:

  • gRPC verwaltet die Art und Weise, wie ein Client und ein Server interagieren können (genau wie ein Web-Client/Server mit einer REST API)
  • protobuf ist nur ein Serialisierungs-/Deserialisierungs-Tool (genau wie JSON)

gRPC hat zwei Seiten: eine Serverseite und eine Clientseite, die einen Server anwählen kann. Der Server macht RPCs verfügbar (dh Funktionen, die Sie remote aufrufen können). Und Sie haben dort viele Möglichkeiten: Sie können die Kommunikation sichern (mit TLS), eine Authentifizierungsebene hinzufügen (mit Interceptors), ...

Sie können protobuf in jedem Programm verwenden, das nicht unbedingt Client/Server sein muss. Wenn Sie Daten austauschen müssen und eine starke Typisierung wünschen, ist protobuf eine gute Option (schnell und zuverlässig).

Davon abgesehen können Sie beide kombinieren, um ein Nizza-Client/Server-System zu erstellen: gRPC ist Ihr Client/Server-Code und protobuf Ihr Datenprotokoll.

PS: Ich habe dieses Papier geschrieben, um zu zeigen, wie man mit Go Schritt für Schritt einen Client/Server mit gRPC und protobuf erstellen kann.

43
chilladx

grpc ist ein Framework, das von Google erstellt wurde und in Produktionsprojekten von Google selbst verwendet wird. #HyperledgerFabric wurde mit grpc erstellt. Es gibt viele OpenSource-Anwendungen, die mit grpc erstellt wurden

protobuff ist eine datenrepräsentation wie json das ist auch bei google in der tat sie haben einige tausende protodateien in ihren produktionsprojekten erzeugt

grpc

  • gRPC ist ein Open-Source-Framework, das von Google entwickelt wurde
  • Es ermöglicht uns, Request & Response für RPC zu erstellen und Rest durch das Framework zu behandeln
  • REST ist CRUD-orientiert, aber grpc ist API-orientiert (keine Einschränkungen)
  • Bauen Sie auf HTTP/2 auf
  • Bietet >>>>> Auth, Loadbalancing, Überwachung, Protokollierung
  • [HTTP/2]
    • HTTP1.1 wurde 1997 vor langer Zeit veröffentlicht
    • HTTP1 öffnet bei jeder Anforderung eine neue TCP Verbindung zu einem Server
    • Header werden nicht komprimiert
    • KEIN Server Push, es funktioniert nur mit Req, Res
    • HTTP2 veröffentlicht im Jahr 2015 (SPDY)
    • Unterstützt Multiplexing
    • client & Server können Nachrichten parallel über dieselbe TCP Verbindung übertragen
    • Reduziert die Latenz erheblich
    • HTTP2 unterstützt die Header-Komprimierung
    • HTTP2 ist binär
      • der Protobuff ist binär und passt daher hervorragend zu HTTP2
  • [TYPEN]
    • Unär
    • client-Streaming
    • server-Streaming
    • Bidirektionales Streaming
    • grpc-Server sind standardmäßig asynchron
    • grpc-Clients können synchronisiert oder asynchronisiert sein

protobuff

  • Protokollpuffer sind sprachunabhängig
  • Das Parsing von Protokollpuffern (Binärformat) ist weniger CPU-intensiv
  • [Benennung]
    • Verwenden Sie Kamelkasten für Nachrichtennamen
    • underscore_seperated für felder
    • Verwenden Sie camelcase für Enums und CAPITAL_WITH_UNDERSCORE für Wertnamen
  • [Bemerkungen]
    • Unterstützung //
    • Unterstützung /* */
  • [Vorteile]
    • Die Daten sind vollständig eingegeben
    • Daten sind vollständig komprimiert (weniger CPU-Auslastung)
    • Schema (Nachricht) wird benötigt, um Code zu generieren und den Code zu lesen
    • Die Dokumentation kann in das Schema eingebettet werden
    • Daten können in jeder Sprache gelesen werden
    • Schema kann jederzeit auf sichere Weise weiterentwickelt werden
    • schneller als XML
    • code wird automatisch für Sie generiert
    • Google hat den Protobuff erfunden, sie verwenden 48000 Protobuf-Nachrichten und 12000.proto-Dateien
    • Viele RPC-Frameworks, einschließlich grpc, verwenden Protokollpuffer, um Daten auszutauschen
0
Narendranath Reddy