Was ist gRPC?

Erfahren Sie, wie F5 diese Herausforderung löst

Google Remote Procedure Call (gRPC) ist ein leistungsstarkes Open-Source-Framework zur Implementierung von APIs über HTTP/2. Es soll Entwicklern die Erstellung verteilter Anwendungen erleichtern, insbesondere wenn der Code auf verschiedenen Rechnern ausgeführt wird.

gRPC wurde ursprünglich von Google als Technologie zur Implementierung von Remote Procedure Calls (RPCs) entwickelt. Heute ist gRPC ein Inkubationsprojekt der Cloud Native Computing Foundation, was bedeutet, dass es produktiv eingesetzt und von einer großen Zahl aktiver Mitwirkender unterstützt wird.

Warum wurde gRPC entwickelt?

Um zu verstehen, warum Google gRPC entwickelt hat, werfen wir einen kurzen Blick auf die Entwicklung des API-Designs.

RPC ist eine der ältesten Methoden zum Entwerfen und Erstellen einer API. Mit RPCs können Sie Code so schreiben, als würde er auf einem lokalen Computer ausgeführt, obwohl Sie möglicherweise tatsächlich einen Dienst aufrufen, der auf einem anderen Rechner läuft (normalerweise in Ihrem lokalen Netzwerk).

In der Praxis können Entwickler dadurch direkte Aktionen (wie SendUserMessages, addEntry usw.) verwenden, ohne Netzwerkdetails berücksichtigen zu müssen. RPC-Nachrichten sind schlank und effizient, aber auch eng an das zugrunde liegende System gekoppelt. Dadurch lassen sie sich nur schwer integrieren und ändern und geben mit höherer Wahrscheinlichkeit Details über das System preis.

Mit der Einführung der REST-API-Architektur wurden einige dieser Herausforderungen gelöst, indem ein einheitlicher Zugriff auf Daten und Ressourcen über allgemeine HTTP-Methoden wie GET, POST, PUT und DELETE ermöglicht wurde. REST vereinfacht zwar den Datenzugriff, doch die API gibt häufig mehr Metadaten zurück als benötigt. REST-APIs erfordern außerdem mehr Informationen über das Netzwerk (etwa darüber, wohin eine Anfrage gesendet werden soll), weshalb sie weniger schlank und effizient als RPCs sind.

Welche Vorteile bietet gRPC?

Durch den Einsatz neuerer Technologien modernisiert gRPC die ältere RPC-Methode und macht sie interoperabel und effizienter. Daher ist gRPC heute eine attraktive Wahl bei der Entwicklung von APIs für Microservices-Architekturen.

Zu den Vorteilen von gRPC gehören:

Leistung – gRPC verwendet HTTP/2 als Transportprotokoll und standardmäßig Protocol Buffers, wodurch eine höhere Leistung als bei der Kommunikation über REST und JSON erzielt werden kann.
Streaming – gRPC unterstützt Datenstreaming für ereignisgesteuerte Architekturen, beispielsweise serverseitiges Streaming, clientseitiges Streaming und bidirektionales Streaming, um Clientanfragen und Serverantworten gleichzeitig zu senden.
Interoperabilität – gRPC unterstützt eine Vielzahl von Programmiersprachen mit integrierter Codegenerierung, darunter C++, Java, Python, PHP, Go, Ruby, C#, Node.js und weitere.
Sicherheit – gRPC bietet austauschbare Authentifizierungs- und Tracing-Mechanismen, Lastverteilung, sowie Integritätsprüfungen zur Verbesserung von Sicherheit und Ausfallsicherheit.
Cloud-nativ – gRPC eignet sich gut für containerbasierte Bereitstellungen und ist mit modernen cloudbasierten Technologien wie Kubernetes und Docker kompatibel.

Insgesamt bietet gRPC ein leistungsstarkes, flexibles Framework, das sich ideal für die Kommunikation zwischen Diensten in hochgradig verteilten Microservices-Architekturen eignet.

gRPC verstehen: Grundlegende Konzepte

Die Vorzüge und Vorteile von gRPC ergeben sich größtenteils aus dem Einsatz zweier Technologien:

Protocol Buffers zur Strukturierung von Nachrichten
HTTP/2 als Transportschicht

Protocol Buffers zur Strukturierung von Nachrichten

gRPC verwendet Protocol Buffers (oder Protobufs) anstelle von XML oder JSON, um Dienste und Nachrichten zu definieren. Dabei handelt es sich um einen sprachunabhängigen Mechanismus zur Serialisierung strukturierter Nachrichten, die von den Diensten untereinander ausgetauscht werden.

Ähnlich wie beim Konzept der OpenAPI-Spezifikation für REST-APIs wird der API-Vertrag in gRPC in einer .proto-Textdatei implementiert, in der Entwickler festlegen, wie die Daten strukturiert sein sollen. Anschließend kompiliert ein protoc-Compiler die .proto-Textdatei automatisch in jede unterstützte Sprache. Zur Laufzeit werden die Nachrichten komprimiert und im Binärformat gesendet.

Dies bietet zwei wesentliche Vorteile:

gRPC beansprucht die CPU weniger stark, da die Daten im Binärformat dargestellt werden, wodurch sich die Größe der Nachrichten verringert.
Das Schema ist klar definiert, um einen reibungslosen Nachrichtenaustausch zwischen Client und Server zu gewährleisten und Fehler zu reduzieren.

HTTP/2 als Transportschicht

Traditionell verwendeten REST-APIs HTTP/1.1 als Transportschicht. REST-APIs können zwar auch über HTTP/2 bereitgestellt werden, doch die ausschließliche Verwendung von HTTP/2 durch gRPC bietet einige entscheidende Vorteile. Einer davon ist die Möglichkeit, Daten binär zu übertragen. Darüber hinaus ermöglicht HTTP/2 die parallele Verarbeitung mehrerer Anfragen, anstatt jeweils nur eine Anfrage zu bearbeiten. Die Kommunikation erfolgt außerdem bidirektional, sodass über eine einzige Verbindung gleichzeitig sowohl Anfragen als auch Antworten gesendet werden können.

Insgesamt verbessert dies die Leistung und reduziert die Netzwerkauslastung, was insbesondere in einer stark ausgelasteten Microservices-Architektur von Vorteil sein kann. Allerdings gibt es einige Einschränkungen. HTTP/2 wird von modernen Webbrowsern im Allgemeinen nicht unterstützt, sodass Sie möglicherweise einen Reverse-Proxy wie NGINX verwenden müssen, um die Anwendung bereitzustellen.

gRPC vs. REST: Ein Vergleich

REST ist heute der vorherrschende Architekturstil für APIs und bietet daher einen nützlichen Bezugspunkt für den Vergleich mit gRPC. Sowohl REST als auch gRPC sind geeignete Ansätze für die Entwicklung von APIs für Webanwendungen und Microservices, wobei keiner der beiden zwangsläufig besser ist als der andere. Dennoch ist es hilfreich, die wesentlichen Unterschiede zu kennen, um das für den jeweiligen Zweck am besten geeignete Werkzeug auszuwählen.

Einige der wichtigsten Unterschiede zwischen gRPC und REST lassen sich in folgende Kategorien einteilen:

Protokoll
Datenformat
Streaming
API-Design
Leistung
Fehlerbehandlung
Sprachunterstützung

Protokoll

REST-APIs können zwar die Vorteile von HTTP/2 nutzen, RESTful-Dienste verwenden jedoch traditionell das textbasierte HTTP/1.1 als Transportschicht. gRPC nutzt ausschließlich HTTP/2, ein effizienteres Binärprotokoll, das Funktionen wie Header-Komprimierung und Multiplexing über eine einzige TCP-Verbindung ermöglicht.

Datenformat

REST-APIs verwenden in der Regel JSON als Datenformat zum Senden und Empfangen von Daten. JSON ist textbasiert, leicht zu lesen und zu schreiben und wird umfassend unterstützt. gRPC-APIs verwenden Protobufs, ein Binärformat, das kleinere Nutzdaten und eine schnellere Interaktion ermöglicht. Protobufs sind jedoch für sich genommen nicht ohne Weiteres lesbar.

Streaming

REST-APIs unterstützen ein Anfrage-Antwort-Modell mit eingeschränkter Streaming-Unterstützung. Im Gegensatz dazu werden gRPC-APIs über HTTP/2 bereitgestellt und unterstützen mehrere Kommunikationsmuster, darunter unäre Kommunikation (Anfrage-Antwort), Server-Streaming, Client-Streaming und bidirektionales Streaming.

API-Design

REST ist ein ressourcenzentriertes Modell, das Standard-HTTP-Methoden wie GET, POST, PUT und DELETE unterstützt. Jede Anfrage muss alle für ihre Verarbeitung erforderlichen Informationen enthalten. Darüber hinaus wird der API-Vertrag üblicherweise mithilfe der OpenAPI-Spezifikation beschrieben, wobei die Implementierung von Client und Server als separater Schritt erfolgt. Im Gegensatz dazu ist gRPC ein servicezentriertes Modell, bei dem Nachrichten und Services in der .proto-Datei definiert werden. Mithilfe dieser Datei lässt sich Code sowohl für den API-Client als auch für den Server generieren.

Leistung

REST kann aufgrund der textbasierten Datenübertragung über HTTP/1.1 langsamer sein. Jede Anfrage erfordert einen TCP-Handshake, der zu einer gewissen Latenz führen kann. gRPC unterstützt mehrere Streams über HTTP/2, sodass mehrere Clients gleichzeitig mehrere Anfragen senden können, ohne eine neue TCP-Verbindung herzustellen. Zudem nutzt es HTTP/2-Funktionen wie die Header-Komprimierung.

Fehlerbehandlung

REST verwendet standardmäßige HTTP-Statuscodes für die Fehlerbehandlung. Im Gegensatz dazu bietet gRPC eine wesentlich feinere Abstufung bei der Definition von Fehlerstatuscodes und stellt deren Konsistenz sicher. Standardmäßig ist das gRPC-Modell recht eingeschränkt, wird jedoch meist durch ein umfassenderes von Google entwickeltes Fehlermodell erweitert.

Sprachunterstützung

REST wird von praktisch jeder Programmiersprache umfassend unterstützt, bietet jedoch keine integrierten Funktionen zur Codegenerierung. Die Implementierung bleibt vollständig dem Entwickler überlassen. Mit seinem protoc-Compiler ermöglicht gRPC die native Codegenerierung für mehrere Programmiersprachen.

Sollten Sie gRPC anstelle von REST verwenden?

Zusammenfassend lässt sich sagen, dass die Wahl zwischen gRPC und REST davon abhängt, was Sie erreichen möchten. gRPC bietet eine effiziente, leistungsstarke Methode für die Kommunikation zwischen Diensten in einer verteilten Anwendung. Allerdings kann es von Webbrowsern und anderen Clients nicht direkt verarbeitet werden und erfordert ein API-Gateway oder einen Reverse-Proxy wie NGINX, um mit Frontend-Clients zu interagieren. Es ist eine ausgezeichnete Option für interne APIs, die Teil einer ereignisgesteuerten Microservices-Architektur sind.

REST hingegen ist weit verbreitet und wird von praktisch jeder Programmiersprache unterstützt. Da Daten über JSON oder XML ausgetauscht werden, sind sie sowohl für Menschen als auch für Maschinen lesbar. Zudem ist der Einstieg wesentlich einfacher, und REST wird von vielen Webbrowsern unterstützt, wodurch es sich ideal für öffentlich zugängliche APIs eignet.

gRPC-Microservices-Architektur

gRPC ist eine der besten Optionen für die Kommunikation in einer Microservices-Architektur. Das liegt zum Teil an der hohen Leistung, aber auch an der flexiblen Unterstützung verschiedener Programmiersprachen. Entwickler können problemlos gRPC-Clients und -Server erstellen und generieren, die in der von ihnen bevorzugten Sprache ausgeführt werden. Da gRPC den API-Vertrag in einem Binärformat beschreibt, können Microservices unabhängig von den für ihre Entwicklung verwendeten Sprachen miteinander kommunizieren.

Eine der gängigsten gRPC-basierten Microservices-Architekturen besteht darin, den Microservices ein API-Gateway vorzuschalten und anschließend die gesamte interne Kommunikation über gRPC abzuwickeln. Das API-Gateway verarbeitet eingehende Anfragen über HTTP/1.1 und leitet sie als gRPC-Anfragen über HTTP/2 an die Microservices weiter.

Sicherheitsbedenken bei gRPC

Da sich gRPC immer weiter verbreitet, müssen Entwickler und Security-Operations-Teams sicherstellen, dass wirksame Sicherheitslösungen vorhanden sind. Da gRPC-Nachrichten im Binärformat vorliegen, kann es bei Geräten und Tools, die eine ASCII-basierte Kommunikation erwarten, zu Problemen kommen.

gRPC-APIs sind ebenfalls anfällig für viele der häufigsten Sicherheitsbedrohungen für APIs. Gängige API-Sicherheitsmaßnahmen wie Zugriffskontrolle, Verschlüsselung und Laufzeitschutz sind in gRPC-basierten Architekturen ebenso wichtig.

Empfehlungen zur gRPC-Sicherheit

Die Sicherheit von gRPC-Anwendungen und -APIs erfordert einen ganzheitlichen Ansatz. Zu den Best Practices für die Absicherung von gRPC gehören:

Schemavalidierung – Blockieren Sie bösartige Angriffe, indem Sie überprüfen, ob jedes Feld in der gRPC-Nachricht den richtigen Typ und den erwarteten Inhalt aufweist.
Datenmaskierung – Verhindern Sie durch Maskieren oder Blockieren, dass sensible Daten wie Kreditkarten- und Sozialversicherungsnummern das System verlassen.
Ratenbegrenzungen – Legen Sie strenge Grenzwerte für die Größe und Anzahl von Anfragen fest, um DoS-Angriffe durch Ressourcenerschöpfung zu verhindern.
Zugriffskontrolle – Erzwingen Sie Authentifizierung und Autorisierung, bevor Sie dem Client Zugriff auf den Dienst gewähren.
Verschlüsselung – Sichern Sie Nachrichten während der Übertragung mithilfe von Transport Layer Security (TLS).

Letztendlich sollten Sie überprüfen, ob Ihr API-Gateway, Ihre Web Application Firewall (WAF) und Ihre anderen API-Management- und Sicherheitstools in der Lage sind, Ihre gRPC-Anwendungen und APIs im Produktivbetrieb zu schützen. Sie sollten die .proto-Datei für jeden Dienst importieren und damit Sicherheitsmaßnahmen für die gRPC-Anwendung und die APIs anwenden können.

Zusammenfassung

gRPC erfreut sich als beliebte Alternative für den Einsatz in Microservice-Architekturen bei Entwicklern und großen Unternehmen wie Netflix und Lyft zunehmender Beliebtheit. Allerdings ist gRPC weder ein Ersatz für REST-APIs noch grundsätzlich die bessere Methode zur Entwicklung von APIs. gRPC ist lediglich eine Alternative, die Sie in Betracht ziehen sollten, wenn Sie APIs hauptsächlich für eine interne Microservice-Umgebung entwickeln und eine effiziente Echtzeitkommunikation benötigen.

Mit Blick auf die Zukunft wird gRPC aufgrund seiner Leistungsvorteile und der einfachen Entwicklung bei Cloud-nativen Anwendungen wahrscheinlich weiter an Bedeutung gewinnen. Entwickler, die APIs öffentlich zugänglich machen müssen, werden in ihren Anwendungen hingegen weiterhin REST verwenden. Auch in Cloud-nativen Umgebungen wird REST dank seiner Abwärtskompatibilität und der tiefen Integration in bestehende API-Infrastrukturen und -Betriebsabläufe weiterhin eine Rolle spielen.

Ähnliche Inhalte