protobuf vs gRPC

Ich versuche Protobuf und gRPC zu verstehen und wie ich beide verwenden kann. Können Sie mir helfen, Folgendes zu verstehen:

• In Anbetracht des OSI-Modells, wo befindet sich beispielsweise Protobuf auf Schicht 4?
• Wenn Sie eine Nachrichtenübertragung durchdenken, wie ist der "Fluss", 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, ist Protobuf nur für das Marshalling gedacht und hat daher nichts mit dem Status zu tun - wahr oder falsch?
• Kann ich gRPC in einer Frontend-Anwendung verwenden, die anstelle von REST oder GraphQL kommuniziert?

Ich weiß bereits - oder gehe davon aus -:

Protobuf

• Binäres Protokoll für den Datenaustausch
• Entworfen von Google
• Verwendet die generierte "Struct" -ähnliche Beschreibung auf Client und Server, um die Marshall-Nachricht 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 eine einfache Frage für jemanden ist, der die Technologie bereits nutzt. Ich würde Ihnen trotzdem danken, geduldig mit mir zu sein und mir zu helfen. Ich wäre auch sehr dankbar für jeden tiefen Einblick in die Technologien.

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

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

gRPC verwendet dieselbe IDL, fügt jedoch die Syntax "rpc" hinzu, mit der Sie Signaturen für Remote Procedure Call-Methoden unter Verwendung 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 arbeitet in den Schichten 5, 6 und 7. Protobuf arbeitet in den Schichten 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. Wenn Sie gRPC standardmäßig verwenden, verwenden Sie Protobuf . Sie könnten Ihren eigenen Client schreiben, der Protobuf verwendet, aber nicht gRPC, um mit gRPC zusammenzuarbeiten, oder andere Serializer an gRPC anschließen - aber die Verwendung von gRPC wäre einfacher
4. Wahr
5. Ja, du kannst

Tatsächlich 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 Webclient / Server mit einer REST-API).
• protobuf ist nur ein Serialisierungs- / Deserialisierungswerkzeug (genau wie JSON)

gRPC hat zwei Seiten: eine Serverseite und eine Clientseite, die einen Server wählen können. 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 (mithilfe von TLS), eine Authentifizierungsschicht hinzufügen (mithilfe von Interceptors), ...

Sie können protobuf in jedem Programm verwenden, für das kein Client / Server erforderlich ist. Wenn Sie Daten austauschen müssen und möchten, dass sie stark typisiert werden, ist protobuf eine gute Option (schnell und zuverlässig).

Davon abgesehen können Sie beides kombinieren, um ein nettes 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.

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

Protobuff ist eine Datendarstellung wie json. Dies ist auch von Google. Tatsächlich werden in ihren Produktionsprojekten einige Tausend Protodateien generiert

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 erledigen
• REST ist CRUD-orientiert, aber grpc ist API-orientiert (keine Einschränkungen)
• Bauen Sie auf HTTP / 2 auf
• Bietet >>>>> Authentifizierung, Lastausgleich, Überwachung und 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 im Jahr 2015 veröffentlicht (SPDY)
  • Unterstützt Multiplexing
  • Client und Server können Nachrichten parallel über dieselbe TCP-Verbindung senden
  • Reduziert die Latenz erheblich
  • HTTP2 unterstützt die Header-Komprimierung
  • HTTP2 ist binär
    • Proto Buff ist binär, daher passt es hervorragend zu HTTP2
• [TYPEN]
  • Einstellig
  • Client-Streaming
  • Server-Streaming
  • Bidirektionales Streaming
  • GRPC-Server sind standardmäßig asynchron
  • grpc-Clients können synchron oder asynchron sein

Protobuff

• Protokollpuffer sind sprachunabhängig
• Das Parsen von Protokollpuffern (Binärformat) ist weniger CPU-intensiv
• [Benennung]
  • Verwenden Sie Kameletui 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 Bandbreitennutzung)
  • 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
  • Das Schema kann jederzeit auf sichere Weise weiterentwickelt werden
  • schneller als XML
  • Code wird automatisch für Sie generiert
  • Google hat den Proto-Buff erfunden. Er verwendet 48000 Protobuf-Nachrichten und 12000.proto-Dateien
  • Viele RPC-Frameworks, einschließlich grpc, verwenden Protokollpuffer, um Daten auszutauschen