Was ist gRPC?

RPC (Remote Procedure Call) ist ein Kommunikationsmodell für die Client/Server-Interaktion, das es ermöglicht, dass Remote-Aufrufe als lokale Aufrufe angezeigt und ausgeführt werden. Es handelt sich um eine ältere Technik, die konzeptionell bis in die 1970er Jahre zurückreicht. Erste Anwendungen wurden in bahnbrechenden Computerprojekten wie ARPANET und Xerox PARC gefunden.

In einem RPC interagiert der Client mit einer Darstellung des Servers, die lokal erscheint, aber in Wirklichkeit ein Vermittler ist. Dieser Vermittler wird üblicherweise als Stub bezeichnet, der die Marshalling- und Unmarshalling-Daten verarbeitet (d. h. die Daten in ein geeignetes Format für die Übertragung umwandelt und die vom Server empfangenen Ergebnisse wieder in das ursprüngliche Format zurückwandelt). Da es sich um einen Architekturstil für die Client/Server-Kommunikation handelt, wird er häufig im API-Design verwendet.

Es gibt viele verschiedene Arten von RPC-Frameworks, darunter XML-RPC und JSON-RPC. Diese Implementierungen verwenden HTTP als Transportprotokoll und unterscheiden sich hauptsächlich im Formattyp. Diese Implementierungen stammen aus den 1990er und 2000er Jahren und zeigten die Stärken von RPC: Sie vereinfachten die Entwicklung, abstrahierten die Komplexität der Netzwerkkommunikation, waren leichtgewichtig, relativ einfach zu verwenden und für Menschen lesbar.

Viele moderne Umgebungen – insbesondere solche, die Microservice-Architekturen, polyglotte Umgebungen und Systeme mit hohen Datenlasten verwenden – erfordern jedoch ein schnelleres, leistungsfähiges Framework zur Verbindung verteilter Anwendungen. Im Idealfall ermöglicht dieses Framework eine effizientere, Echtzeit-Datenübertragung zwischen Services, die in verschiedenen Umgebungen und Rechenzentren ausgeführt werden.

gRPC wurde für diesen Bedarf entwickelt und bietet geringe Latenz und hohen Durchsatz durch Datenserialisierung und Verwendung des HTTP/2-Protokolls, bidirektionale Streaming-Funktionen, Codegenerierung und mehr.

gRPC wurde ursprünglich im Jahr 2015 veröffentlicht, im selben Jahr wie HTTP/2. Es beseitigt die Einschränkungen älterer RPC-Implementierungen vor allem durch die Verwendung von Protokollpuffern oder Protobuf, seiner Schnittstellendefinitionssprache (IDL). Protobuf serialisiert und kodiert strukturierte Daten in Binärdaten. Dadurch werden die Daten kompakter und ermöglichen eine schnellere Übertragung und eine höhere Leistung.

Protobuf ermöglicht auch Änderungen an Datenfeldern ohne Unterbrechung des Codes. Dies trägt dazu bei, Fehler zu reduzieren und den Austausch und die Verarbeitung von Daten in Echtzeit zu ermöglichen. Diese Funktionen machen APIs, die mit gRPC erstellt wurden, zu einer starken Option für moderne, verteilte Umgebungen, Microservice-Architekturen, Streaming-Anwendungen und für die Verbindung von Systemen und Geräten des Internets der Dinge.

Es wäre logisch, wenn gRPC für „Google Remote Procedure Call“ stünde. Das gRPC-Team von grpc.io behauptet jedoch augenzwinkernd, dass es für „gRPC Remote Procedure Call“ steht. Auf GitHub wird darauf hingewiesen, dass das "g" bei jeder Version für etwas anderes steht (von „gesellig“ über „Gans“ bis hin zu „Guadalupe River Park Conservancy“). Auf jeden Fall hat Google gRPC entwickelt und 2015 als Open-Source-Projekt veröffentlicht.

gRPC präsentiert eine moderne, aktualisierte Version von RPC mit Unterstützung für moderne Sprachen und zusätzlichen Funktionen und Optimierungen. Zu den Merkmalen gehören:

• Eine Schnittstellendesignsprache (IDL) namens Protocol Buffers
• Verwendung von HTTP/2 für die Datenübertragung
• Bidirektionales Streaming
• Codegenerierung
• Vier Methodentypen
• Integration mit TLS-basierter Sicherheit
• Interceptor-Unterstützung für Protokollierung, Tracing, Authentifizierung und mehr

Protocol Buffers, allgemein bekannt als Protobuf, ist ein plattformübergreifendes Datenformat, das von Google entwickelt wurde und zur Serialisierung strukturierter Daten verwendet wird. Es dient als leistungsfähiger Vermittler zwischen Client und Server, der Anfragen für die Übertragung in Binärcode serialisiert.

Dieser Mechanismus ist flexibel und effizient und ermöglicht gleichzeitig eine Unabhängigkeit von der Programmiersprache, eine geringere Nachrichtengröße sowie eine schnellere Analyse und Übertragung. Eine Anwendung, die Java verwendet, kann mit einer Anwendung kommunizieren, die Python verwendet, da die Anfrage in die Lingua Franca der Binärdatei umgewandelt wird. Obwohl sie von Menschen nicht gelesen werden kann, lassen sich Binärdateien mit Computern schneller übertragen und dekodieren als ein textbasiertes Format wie JSON.

Im Wesentlichen erstellen Entwickler eine Textdatei mit dem Suffix „.proto“, das alle Informationen über die Datenstruktur enthält. Diese Informationen sind schemabasiert, d. h. sie definieren Parameter, Methoden und mögliche Ausgaben – also eine Beschreibung der Struktur der Daten. Beispielsweise könnte es einen Eintrag für „Benutzer“ geben, in dem vermerkt ist, dass diese Daten „Name“, „E-Mail-Adresse“ und „Lieblings-Pizza-Belag“ umfassen.

Laut der Protobuf-Dokumentation ist es wie XML, „nur kleiner, schneller und einfacher. Man legt fest, wie seine Daten strukturiert sein sollen, und kann dann einen speziell generierten Quellcode verwenden, um seine strukturierten Daten einfach in eine Vielzahl von Datenströmen und in einer Vielzahl von Sprachen zu schreiben und zu lesen.“ Als Vermittler ermöglicht Protobuf auch die Installation verschiedener Authentifizierungs- und Sicherheitsmaßnahmen.

Entwickler können einen Compiler namens Protoc verwenden, um Code in einer von mehreren unterstützten Sprachen zu generieren, darunter C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python und Ruby. Dieser Code erfüllt viele Funktionen: Er enthält in der Regel Klassen oder Module, behandelt die Serialisierung in Binärdateien und die Deserialisierung aus Binärdateien und abstrahiert die Komplexität des Datenaustauschs. Entwickler müssen sich nicht um Netzwerkpakete, Marshalling, Kompatibilitätsaktualisierungen und Implementierungen kümmern. Protobuf übernimmt alles.

Das schemabasierte Design von Protobuf ermöglicht es Entwicklern, neue Datenfelder zu bestehenden Strukturen hinzuzufügen, ohne das gesamte System zu beschädigen. Außerdem wird der Aufwand für die Aktualisierung, Wartung und die Abwicklung mühsamer API-bezogener Aufgaben, wie z. B. das Anpassen des vorherigen Codes nach dem Hinzufügen neuer Datenfelder, erheblich reduziert. Allerdings kann die Einrichtung von .proto-Dateien zunächst einige Zeit und Mühe kosten.

HTTP/2 ist ein Transportprotokoll – eine Methode, die Computer und Server zum Austausch von Informationen verwenden –, die ein Binärformat zum Senden von Nachrichten verwendet, TCP-Verbindungen reduziert und Header-Komprimierung verwendet, was alles dazu beiträgt, dass es schneller und effizienter als sein Vorgänger ist ( HTTP/1.1). Es ermöglicht auch Multiplexing, d. h. die Möglichkeit, mehrere gleichzeitige Streams über eine einzige Verbindung zu senden; gRPC verwendet sogenannte Kanäle, um mehrere Streams über diese verschiedenen Verbindungen zu ermöglichen. Nachrichten werden als HTTP/2-Datenrahmen gesendet, von denen jeder mehrere gRPC-Nachrichten enthalten kann.

gRPC bietet bidirektionales Streaming, bei dem sowohl der Client als auch der Server unabhängig voneinander Nachrichten in einem Lese-/Schreibstream senden können. Diese Methode ermöglicht alle Arten von Flexibilität: Ein Server und ein Client können nacheinander Antworten austauschen, oder ein Server kann warten, bis alle Nachrichten des Clients empfangen wurden, bevor er antwortet. Diese Funktion kann je nach Anwendung angepasst werden.

gRPC verwendet ein Compiler-Tool namens protoc, um automatisch sowohl Client- als auch Servercode in verschiedenen Sprachen auf der Grundlage von Service-Definitionen und Nachrichtenstrukturen zu generieren, die in einer .proto-Datei definiert sind. Mithilfe von Plug-ins kann die Unterstützung auf viele weitere Sprachen erweitert werden.

Protoc generiert Klassen für den Datenzugriff in der Sprache, die in der Proto-Definition definiert ist. Diese Klassen bieten einfache Zugriffsfunktionen für Felder wie [Name] sowie Methoden zum Serialisieren und Parsen der Struktur in und aus unaufbereiteten Bytes.¹

gRPC unterstützt vier verschiedene Methodentypen für die Datenübertragung: unäres, clientseitiges Streaming, serverseitiges Streaming und bidirektionales Streaming.

gRPC verfügt über eine eingebaute Integration in TLS (Transport Layer Security), das den Datenaustausch zwischen Client und Server verschlüsselt und Benutzern sichere Verbindungen ermöglicht.

gRPC unterstützt integrierbare Authentifizierung, Tracing, Protokollierung, Metriken, Lastausgleich, Zustand und mehr. 

gRPC verfügt über vier verschiedene Arten von Methoden, die angeben, wie eine Nachricht von einem gRPC-Client und einem gRPC-Server gesendet und empfangen wird. Diese Typen sind:

Unär: Ein einfacher Aufruf, bei dem ein Client eine einzelne Anfrage sendet und ein Server mit einer einzigen Antwort antwortet.

Serverseitiges Streaming: Ein Aufruf, bei dem ein Client eine Anforderung sendet, der Server jedoch mit mehreren Antworten antwortet.

Clientseitiges Streaming: Ein Aufruf, bei dem ein Client mehrere Anfragen sendet und ein Server mit einer einzigen Antwort antwortet. Der Server kann warten, bis der gesamte Strom von Clientanfragen beendet ist, bevor er verarbeitet und antwortet.

Bidirektionales Streaming: Der Client und der Server senden beide mehrere Anrufe gleichzeitig hin und her, was eine Kommunikation in Echtzeit ermöglicht.

Sowohl gRPC als auch REST sind Architekturstile, die häufig im API-Design verwendet werden. Sie haben viele Ähnlichkeiten; beide folgen einer Client/Server-Architektur, basieren auf HTTP-basierter Kommunikation, sind statusunabhängig und sprachunabhängig. Aber sie unterscheiden sich auch in wesentlichen Punkten, wodurch sie sich ideal für verschiedene Anwendungsfälle eignen.

Datenformat: REST-APIs verwenden Nur-Text-Formate wie JSON und XML. gRPC verwendet Protobuf, um Daten in Binärdateien zu codieren.

Kommunikationsmuster: gRPC unterstützt vier Methoden: unär, Server-Streaming, Client-Streaming und bidirektionales Streaming. REST verwendet ein einheitliches System aus Anfrage und Antwort.

Codegenerierung: gRPC bietet eine integrierte Codegenerierung; REST tut dies nicht, jedoch sind Plug-ins dafür verfügbar.

Entwurfsmuster: gRPC hat ein serviceorientiertes Design, bei dem aufrufbare Serveroperationen als Dienste oder Funktionen definiert werden. Bei REST orientiert sich das Design an Ressourcen, wobei HTTP-Methoden verwendet werden, um über Endgeräte, die durch URLs definiert sind, auf Serverressourcen zuzugreifen.

Protokoll: gRPC verwendet HTTP/2, REST hingegen basiert auf HTTP/1.1.

Kopplung: Der Client und der Server von gRPC sind eng miteinander verknüpft, was bedeutet, dass sowohl der Client als auch der Server Zugriff auf dieselbe Middleware-Proto-Datei haben müssen. Jede Änderung in dem einen erfordert eine Änderung in dem anderen. REST ist lose gekoppelt. Diese Unabhängigkeit bedeutet, dass Änderungen an einer Komponente keine Auswirkungen auf die andere haben.

gRPC wird häufig für komplexe APIs verwendet, die mehrere Services in einer verteilten Umgebung miteinander verbinden. Aufgrund seiner Echtzeit-Streaming-Fähigkeit und seiner hohen Leistung eignet sich gRPC gut für verschiedene Anwendungsfälle, darunter Microservices, Streaming und das Verbinden von Internet-der-Dinge-Clients.

Aufgrund seiner hohen Leistung, der geringen Latenz, der Fähigkeit, große Datenmengen zu verarbeiten, und der Funktionen zum bidirektionalen Streaming in Echtzeit, wird gRPC häufig zur Erstellung von APIs für Microservices verwendet.

Da gRPC sprachunabhängig ist, kann es die Kommunikation zwischen Diensten ermöglichen, die in verschiedenen Programmiersprachen geschrieben wurden. Darüber hinaus bieten die Protobuf-Definitionen ein stark typisiertes Schema, das zur Sicherung der Datenunversehrtheit des Microservice beiträgt.

Die bidirektionalen Streaming-Funktionen von gRPC bedeuten, dass Daten über eine einzige Netzwerkverbindung gleichzeitig in beide Richtungen zwischen Client und Server gestreamt werden können. Diese Funktion macht gRPC ideal für laufende Prozesse wie Videokonferenzen oder wenn ein Benutzer einen Teil eines Datensatzes verwenden möchte, während andere Daten übertragen werden.

Das Internet der Dinge bezieht sich auf ein Netzwerk verbundener Geräte oder Clients. Zu den IoT-Geräten – sie werden auch als „Smart-Objekte“ bezeichnet – können einfache „Smart-Home-Geräte“ wie intelligente Thermostate, Wearables wie Smartwatches und RFID-fähige Kleidung sowie komplexe Industriemaschinen und Transportsysteme gehören.² gRPC-APIs werden häufig verwendet, um den konsistenten Datenaustausch zwischen diesen Geräten zu erleichtern.

Mit seiner bidirektionalen Streaming-Unterstützung und microservicefreundlichen Funktionen (und seinem Status als CNCF-Projekt) wird gRPC zunehmend für cloudnative APIs verwendet.

gRPC wird verwendet, um Client-Bibliotheken in vielen verschiedenen Programmiersprachen zu generieren. Diese Bibliotheken werden auf Basis der in .proto-Dateien bereitgestellten Dienstdefinition generiert; sobald der Dienst definiert ist, generiert gRPC automatisch Clientcode in einer gewählten Programmiersprache.

Diese Funktion erleichtert die Arbeit der Entwickler, da sie sich auf die Anwendung konzentrieren können, anstatt auf den Code der Low-Level-Kommunikation.

gRPC bietet viele Nutzen für Unternehmen und Entwickler, die APIs mit hohen Leistungsanforderungen entwickeln. Zu diesen Vorteilen gehören:

Schnellere und effizientere Übertragung: Es gibt mehrere Faktoren, die zur hohen Leistung von gRPC beitragen. Zum einen reduziert die Protobuf-Serialisierung die Nachrichtengröße und kleinere Pakete können schneller übertragen werden. Binärdateien werden zudem effizienter analysiert als Klartextformate wie JSON oder XML.

Darüber hinaus nutzt gRPC HTTP/2, das schneller und effizienter als HTTP/1.1 ist, wodurch Latenz und Bandbreitennutzung weiter reduziert werden.

Größere Portabilität: Da gRPC Protokollpuffer (ein sprach- und plattformunabhängiger Serialisierungsmechanismus) zur Beschreibung von Datenstrukturen und RPC-Schnittstellen verwendet, kann es die Kommunikation zwischen Diensten ermöglichen, die in verschiedenen Sprachen auf verschiedenen Plattformen geschrieben sind.

Reduzierte Laufzeitfehler: Protobuf bietet eine starke Typisierung, d. h. es erzwingt eine feste, explizit definierte Datenstruktur. Eine starke Eingabe fördert die Konsistenz und eine frühere Fehlererkennung und verringert die Wahrscheinlichkeit von Fehlern zur Laufzeit.

Flexible Anpassung: Die integrierte Unterstützung für Middleware ermöglicht die Anpassung und das Hinzufügen von Funktionen wie Sicherheits- und Authentifizierungsmaßnahmen oder Analysetools.

Obwohl gRPC viele Vorteile hat, ist es nicht ohne Herausforderungen. In einigen Fällen – z. B. bei öffentlich zugänglichen APIs mit einfachen Datenquellen, bei denen die Benutzerfreundlichkeit im Vordergrund steht – kann die durch gRPC eingeführte Komplexität unnötig sein. Zu den Herausforderungen von gRPC gehören:

Komplexität: Die Definition von Nachrichtenstrukturen und Diensten in .proto-Dateien, wie sie gRPC erfordert, kann schwieriger sein als die Arbeit mit textbasierten Formaten wie XML und JSON.

Benutzerfreundlichkeit: gRPC, Protokollpuffer und HTTP/2 können für Entwickler, die an die Arbeit mit REST gewöhnt sind, eine steile Lernkurve darstellen.

Debugging: Es kann schwierig sein, gRPC-Anwendungen zu überprüfen, zu debuggen und zu protokollieren, da das Binärformat nicht für Menschen lesbar ist. Es gibt Tools, die Binärdateien konvertieren können, erfordern jedoch im Vergleich zu XML oder JSON einen zusätzlichen Schritt.

Aktualität und Unterstützung: gRPC ist nicht so alt wie andere beliebte Architekturstile wie REST und verfügt nicht über eine so große Community oder so viel Unterstützung für Plug-ins und Dokumentation. Da es sich um ein neueres Framework handelt, stehen für gRPC weniger Tools (z. B. Sicherheitsscanner-Tools) zur Verfügung als für einige etabliertere Modelle.

Mangelnde Browserunterstützung: Da Webbrowser das gRPC-Protokoll nicht nativ unterstützen, ist es nicht möglich, einen gRPC-Dienst direkt von einer browserbasierten Anwendung aus aufzurufen. Eine Möglichkeit, dieses Problem zu umgehen, ist die Verwendung eines Proxys wie gRPC-Web. gRPC-Web fungiert im Wesentlichen als Übersetzungsschicht zwischen dem HTTP- und dem gRPC-Protokoll eines Browsers.

Die Anwendung initiiert einen gRPC-Aufruf mithilfe der gRPC-Web-JavaScript-Clientbibliothek, um eine gRPC-Anforderung zu senden, die für die Browserkompatibilität angepasst wurde. Die Anforderung wird an einen Proxy-Server gesendet, der die Anforderung in eine standardmäßige gRPC-Anforderung umwandelt und an den gRPC-Backend-Server weiterleitet. Der gRPC-Server verarbeitet die Anforderung, sendet eine Antwort an den Proxy-Server zurück, und der Proxy konvertiert die Antwort erneut in das gRPC-Web-Format, bevor er sie an den Client zurückgibt.