Die Netzwerktechnologie entwickelt sich rasant weiter. Um den immer anspruchsvolleren Anforderungen verteilter Computersysteme gerecht zu werden, wurde ein neues System namens gRPC für Remote Procedure Calls oder Remote Procedure Calls entwickelt. Das? G? Es ist von Google, da das Unternehmen eine entscheidende Rolle bei der Entwicklung des Systems gespielt hat. Wir erklären, was gRPC ist, wie es funktioniert und wo es verwendet wird.

1. Was ist gRPC?
2. So funktioniert gRPC: mehrsprachig und effizient dank Protokollpuffern und HTTP / 2
3. Der gRPC-Workflow und die ersten Schritte mit Protokollpuffern
4. HTTP / 2: Optimiertes Streaming
5. Vor- und Nachteile von gRPC
6. Vergleich zwischen gRPC und REST
7. In welchen Fällen wird gRPC verwendet?

gRPC ist ein modernes Remote Procedure Call-System, das dank innovativer Verfahrenstechnik die Kommunikation in verteilten Client-Server-Strukturen besonders effizient verarbeitet. Es arbeitet auf Prozessebene wie sein Vorgänger, das RPC-System. Ein charakteristisches Element der prozessübergreifenden Kommunikation mit gRPC ist das Prinzip der Transparenz : Die Zusammenarbeit zwischen (teilweise sehr) entfernten Instanzen ist so eng und einfach, dass im Vergleich zu einer lokalen Kommunikation zwischen internen Prozessen einer Maschine kein Unterschied wahrgenommen wird.

Die Cloud Native Computing Foundation wurde 2015 von Google entwickelt und ist heute für deren Vertrieb und Entwicklung verantwortlich. gRPC ist ein Open-Source- Element , dh der Quellcode ist für andere Entwickler zugänglich, um Änderungen vorzunehmen und an seiner Entwicklung teilzunehmen.

Standardmäßig führt gRPC den Transport von Datenflüssen zwischen Remotecomputern mithilfe von HTTP / 2 aus und verwaltet die Struktur und Verteilung der Daten mithilfe der von Google entwickelten Protokollpuffer. Letztere werden als Nur- Text-Dateien mit der Erweiterung .proto gespeichert .

GRPC wird oft als eine Art  Framework definiert . Eines der herausragenden Merkmale von Frameworks ist, dass sie Entwicklern ein Programmierframework bieten, um Zeit und Arbeit zu sparen. Die standardisierte gRPC-Struktur enthält bereits verschiedene Funktionen und Elemente, die nicht bei jedem Bedarf immer wieder neu programmiert werden müssen. Das gRPC-Framework definiert auch standardisierte Schnittstellen für den Zugriff auf bestimmte Quellen (z. B. Datenbanken).

Protokollpuffer (Protobuf) erfüllen im gRPC-System mehrere Funktionen: Sie dienen als Schnittstellenbeschreibungssprache (Interface Definition Language, IDL) und beschreiben eine Schnittstelle unabhängig von einer Sprache, dh sie sind nicht mit einer Programmiersprache verknüpft spezifisch (zB Java oder C). Sie definieren auch die zu verwendenden Dienste und die verfügbaren Funktionen. Für jede Funktion können Sie angeben, welche Parameter mit einer Abfrage gesendet werden und welcher Antwortwert zu erwarten ist.

Aus einer entfernten Perspektive dienen Protokollpuffer als zugrunde liegendes Nachrichtenaustauschformat , das die Strukturen, Typen und Objekte von Nachrichten bestimmt. Sind die Elemente, die den Client und den Server ausmachen? Verstehen? und dass sie als funktionale Einheit und so effizient wie möglich funktionieren, auch aus großer Entfernung.

GRPC eine Anfrage im Fall einer Datenbankabfrage bearbeiten (? .. Eg Suche Lager ? Für einen Artikel im Laden) ist wie folgt:

• Bevor die Suche durchgeführt werden kann, müssen bestimmte Vorbereitungen getroffen werden. Auf der Serverseite werden zunächst ein gRPC-Dienst und ein Server auf Basis von Protokollpuffern implementiert. Der Client, der seinerseits die Abfrage durchführt, generiert den entsprechenden Stub . Falls verfügbar, ruft die Client – Anwendung die entsprechende Funktion (? Abfrage Suchen Stock eines Artikel?) Auf dem Stummel .
• Die Abfrage wird dann über das Netzwerk an den Server gesendet. Sobald die Abfrage mit Hilfe einer geeigneten Serviceschnittstelle empfangen wurde, startet der gRPC-Server die eigentliche Suche nach dem Produkt in der Datenbank.
• Der Server sendet dann eine Antwort an den Stub des Clients, der seinerseits den Antwortwert an die ursprüngliche Abfrageinstanz übergibt (z. B. “Anzahl der gefundenen Artikel”).

Sowohl clientseitige als auch serverseitige Anwendungen können in verschiedenen Programmiersprachen geschrieben werden. gRPC kann diese Barrieren durch Schnittstellen und spezielle Übersetzungsmechanismen überwinden.

Für den Roundtrip-Transport von Datenflüssen zwischen Maschinen (Proto Request und Proto Response) ist HTTP / 2 in bestimmte Netzwerkprotokolle wie TCP / IP oder UDP / IP integriert. Streams übertragen kompakte Binärdaten, die beim typischen Marshalling von Remoteprozeduraufrufen entstehen. Um diese vollständig abstrakten Datenstrukturen zu verarbeiten, wird in den nächsten Schritten auf der Serverseite und auf der Clientseite der gestreamte Inhalt erneut deserialisiert ( Unmarshalling ).

Der gRPC-Workflow ist in vier Schritte unterteilt:

1. Definition des Servicevertrags für die prozessübergreifende Kommunikation: Die anzuwendenden Services sowie die grundlegenden Antworttypen und Parameter, auf die remote zugegriffen werden kann, werden festgelegt.
2. Generierung des GRPC-Codes der Datei .proto : Spezielle Compiler (? Tools-Befehlszeile namens protoc) generieren den Betriebscode mit den entsprechenden Klassen für ein sprachlich gewünschtes Ziel (z. B. C ++, Java ..) gespeicherte .proto- Dateien .
3. Serverimplementierung in der gewünschten Sprache.
4. Erstellung des Stubs des Clients , der den Dienst aufruft; Die Abfragen werden dann zwischen dem Server und dem Client verarbeitet.

Bei einer Datenbankabfrage zur Ermittlung des Bestands eines Artikels in einem Lager ( Inventar ) sind die ersten Schritte in der aktuellen Protokollpuffersyntax (Version: proto3) die folgenden:

In diesem Beispiel verwendet die Datenbankabfrage? Wrapper-Bibliotheken? Besonderheiten des gRPC- Frameworks , die standardmäßig bereits relevante Übersetzungsprozesse verfügbar machen und beim Start importiert werden. In mehrsprachigen und ungleichen Client-Server-Strukturen ermöglichen diese Bibliotheken die Kommunikation von Schnittstellen, die im Prinzip nicht kompatibel sind. So werden sie erzeugt, p. zB die Klassen, die zum Lesen und Schreiben von Nachrichten benötigt werden.

Die folgende Grafik zeigt, wie die Service-Definition ( inventar.proto ) die Abfrage einer Datenbank in einer Client-Server-Struktur regelt:

HTTP / 2 spielt eine entscheidende Rolle für gRPC und ermöglicht die Übertragung kompakter Binärdaten, um den Austausch von Nachrichten und Daten effizienter zu gestalten. Das Protokoll bietet vier Varianten für Remoteprozeduraufrufe:

1. Unäre RPCs stellen das einfachste gRPC-Muster dar, bei dem der Client eine einzelne Anforderung an den Server sendet und wie ein normaler Funktionsaufruf nur eine Antwort erhält.

Beispiel: rpc SayHello (HelloRequest) antwortet (HelloResponse)

2. Server- Streaming- RPCs ermöglichen einen komplexeren Nachrichtenaustausch innerhalb eines einzelnen RPC-Aufrufs. Zunächst sendet der Client eine Anfrage an den Server. Dann empfängt es als Antwort einen Thread ( Stream ) mit einer langen Folge von Nachrichten (effiziente Anforderung von Nachrichten innerhalb eines einzelnen RPC-Aufrufs). Der Client liest dann den Thread, bis keine Nachrichten mehr vorhanden sind.

Beispiel: rpc LotsOfReplies (HelloRequest) antwortet (Stream HelloResponse)

3. Client- Streaming- RPCs kehren den Prozess um: Der Client schreibt eine Folge von Nachrichten und sendet sie per Stream an den Server . Sobald der Client die Nachrichten vorbereitet hat, wartet er darauf, dass der Server sie liest und darauf antwortet. In diesem Fall erfolgt die Nachrichtenanforderung auch innerhalb eines einzelnen RPC-Aufrufs.

Beispiel: rpc LotsOfGreetings (Stream HelloRequest) antwortet (HelloResponse)

4. Zweiwege- Streaming- RPCs stellen die komplexeste Form der Kommunikation dar, bei der beide Seiten eine Folge von Nachrichten senden. Beiden Datenströme arbeiten unabhängig voneinander, so dass der Client und der Server können unabhängig von der Reihenfolge lesen und schreiben. Auf diese Weise kann der Server warten, bis alle Nachrichten vom Client eingegangen sind, bevor er seine Antworten verfasst, aber er kann auch abwechselnd Nachrichten schreiben und lesen. Jede andere Kombination von Lese- und Schreibprozessen ist ebenfalls zulässig.

Zum Beispiel: rpc BidiHello (Stream HelloRequest) antwortet (Stream HelloResponse)

Dank verschachtelter Anforderungen ermöglichen die Varianten 2 bis 4 ein besonders effizientes Multiplexing, bei dem mehrere Signale zu einer einzigen TCP-Verbindung zusammengefasst und gleichzeitig über das Netzwerk übertragen werden können. Datenverkehrsblöcke werden vom leistungsstarken HTTP / 2-Protokoll umgangen.

gRPC hat viele Vorteile: Die Technologie ist einfach anzuwenden, da beim Erstellen von .proto- Dateien eine einfache, leicht zu erlernende IDL verwendet wird . Damit können auch veraltete Programme mit einer leistungsstarken gRPC-Schnittstelle erweitert werden, so dass sie große Dateien deutlich schneller übertragen können.

gRPC wurde mehrfach getestet und ist leicht skalierbar, sodass es auch in komplexeren und umfangreicheren Kommunikationen angewendet werden kann, z. Zum Beispiel in Client-Server-Strukturen, die auf globaler Ebene miteinander verbunden sind. Hier erhöht HTTP / 2 nicht nur die Effizienz dank Multiplexing und bidirektionalem Streaming , sondern ermöglicht auch die Komprimierung von Headern , um das Datenvolumen von Anforderungen und Antworten im Netzwerk erheblich zu reduzieren.

Die hoch standardisierte Schichtstruktur des gRPC- Frameworks ermöglicht einen geringeren Programmieraufwand. Auf diese Weise können Entwickler ihre volle Aufmerksamkeit auf die Anwendung der Methoden richten. Wenn Anpassungen erforderlich sind, können Programmierer und Systementwickler den freien Zugriff auf den Quellcode nutzen.

Darüber hinaus ermöglichen Protokollpuffer und Protobuf-Compiler grenzüberschreitende Kommunikation: Unterschiedliche Betriebssysteme, unterschiedliche Komponenten von Client-Server-Frameworks und unterschiedliche Programmiersprachen sind kein Problem mehr. So kann in C geschriebene Software beispielsweise mit Java-Software kommunizieren. Heute sind Protobuf-Compiler für eine große Anzahl von Sprachen verfügbar, z. ZB für C #, C ++, Go, Objective-C, Java, Python, Node.js, Android Java, Swift, Ruby und PHP.

Die Flexibilität von gRPC ist ein weiterer Vorteil. Es kann auch für den Datenaustausch von Microservices oder mobilen Anwendungen verwendet werden, die ihre Daten mit Servern teilen. Weitere Vorteile: Das Protokoll ermöglicht die Anwendung moderner Sicherheitstechnologien. gRPC verfügt über eine integrierte Authentifizierung und empfiehlt die Verwendung von SSL / TLS zur Authentifizierung und Verschlüsselung des Austauschs.

Auf der anderen Seite der Medaille gibt es beim Testen der gRPC-Schnittstellen derzeit noch viel Raum für Verbesserungen. Protobuf-codierte gRPC-Nachrichten können ohne technische Unterstützung nicht gelesen werden. Daher müssen bei der Analyse des Datenverkehrs und vor allem bei der Fehlerbehebung ( Debugging ) zusätzliche Instanzen verwendet werden, um den Code leserlich zu übertragen und Fehler zu erkennen. Die Verbindung verteilter Client-Server-Strukturen bringt weitere Nachteile mit sich. Beim Verbinden von Computern über große Entfernungen ist gRPC viel exponierter als ein lokales System . Es hängt von einem stabilen und leistungsstarken Netzwerk ab, dass das Netzwerk, der Datenverkehr, die Übertragungsprotokolle sowie der Client und der Server für Hacker keine leichte Beute werden . Ein weiterer Nachteil ist, dass gRPC Multicasting nicht unterstützt.

Aufgrund seiner Vorteile stellt gRPC eine kompetente Alternative zu  REST  (Representational State Transfer) dar. REST eignet sich besonders für einfachere Services, während gRPC sein volles Potenzial in komplexen Schnittstellen (APIs) entfaltet. In der Regel verwendet REST für den Datenaustausch zwischen Anwendungen das JSON-Datenformat, ein textbasiertes Format, das die Netzwerkressourcen stark belastet.

Das gRPC-System hingegen kann dank der Protokollpuffer und HTTP / 2 einen wesentlich kompakteren Datenfluss organisieren. Auf diese Weise wird der für die Serialisierung und Binarisierung erforderliche Speicherplatz im Vergleich zum Beispiel zum JSON-System um fast 70 Prozent reduziert. Darüber hinaus bietet bidirektionales Streaming , das den Datenaustausch nicht blockiert, im Vergleich zu REST enorme Vorteile in Bezug auf Leistung und Geschwindigkeit.

Derzeit lässt ihre Zusammenarbeit mit Webanwendungen immer noch zu wünschen übrig, da sie normalerweise nicht für die Verwendung von Protokollpuffern optimiert sind, dem Paradigma “Vertrag zuerst”. Merkmal von gRPC, für das die Contract First-APIs des gRPC- Frameworks optimiert sind. Eines der großen Probleme bei der Zusammenarbeit mit Webanwendungen besteht darin, dass es noch nicht möglich ist, direkt über einen Browser auf einen gRPC-Dienst zuzugreifen . REST hat diese Nachteile nicht, da HTTP im Gegensatz zum moderneren HTTP / 2-Protokoll mit allen Browsern kompatibel ist, obwohl dieser Rückschlag mit akzeptablem Aufwand ausgeglichen werden kann, damit er verwendet werden kann der gleiche Dienst für eine Webanwendung und für eine mobile Anwendung. Eine praktikable Option in diesem Bereich ist gRPC-Web. GRPC-Entwickler arbeiten weiterhin daran, weitere Lösungen zu finden, die die Zusammenarbeit von gRPC mit webbasierten Tools erleichtern.

Das gRPC-System eignet sich besonders für die effiziente Kommunikation zwischen Prozessen in verteilten Client-Server-Strukturen, die eine geringe Latenz und einen hohen Daten- und Nachrichtenfluss anstreben. gRPC wird häufig in und zwischen Remote-Rechenzentren verwendet, um Dienste oder Mikrodienste miteinander zu verbinden. Da gRPC-Tools mit den gängigsten Entwicklungssprachen kompatibel sind, werden sie sehr häufig in mehrsprachigen Umgebungen verwendet .

Geschwindigkeit, Effizienz und Mehrsprachigkeit begünstigen den Einsatz von gRPC in der mobilen Umgebung und die Kommunikation mit Anwendungen. Der gRPC regelt vor allem den letzten Teil der verteilten Datenverarbeitung, da er Geräte, mobile Anwendungen und Browser mit Backend-Diensten verbindet .

Das leistungsstarke Streaming über HTTP / 2 prädestiniert es außerdem für die Punkt-zu-Punkt-Kommunikation in Echtzeit . Das Internet der Dinge und die Hausautomation profitieren von diesem ressourcenschonenden Verfahren, da es sich zunehmend mit einkommensschwacher Kundenkommunikation befasst. Aufgrund ihrer Leistungsfähigkeit und ihrer einfachen Entwicklung könnte diese Kommunikationstechnologie in Zukunft eine herausragende Rolle in der Cloud spielen und damit der aktuellen Hegemonie von REST entgegenwirken. Heute wird gRPC auch als Alternative zu XML (Extensible Markup Language) verwendet.