Google Remote Procedure Call (gRPC) ist ein leistungsstarkes Open-Source-Framework für die 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. gRPC ist heute ein inkubiertes Projekt der Cloud Native Computing Foundation, d. h. es wird in der Produktion eingesetzt und von einer großen Zahl von Mitwirkenden unterstützt.
Um zu verstehen, warum Google gRPC entwickelt hat, sollten wir uns kurz den zeitlichen Ablauf des API-Designs ansehen.
RPC ist eine der ältesten Methoden, eine API zu entwerfen und zu erstellen. RPCs ermöglichen es Ihnen, Code so zu schreiben, als würde er auf einem lokalen Computer ausgeführt werden, obwohl Sie in Wirklichkeit einen Dienst aufrufen, der auf einem anderen Rechner ausgeführt wird (normalerweise in Ihrem lokalen Netzwerk).
In der Praxis ermöglicht dies Entwicklern die Verwendung direkter Aktionen (wie SendUserMessages, addEntry usw.), ohne auf Netzwerkdetails Rücksicht nehmen zu müssen. RPC-Nachrichten sind schlank und effizient, aber sie sind auch eng mit dem zugrunde liegenden System gekoppelt, was ihre Integration und Änderung erschwert und die Wahrscheinlichkeit erhöht, dass sie Details über das System preisgeben.
Als die REST-API-Architektur eingeführt wurde, löste sie einige dieser Herausforderungen, indem sie eine einheitliche Methode für den Zugriff auf Daten und Ressourcen mit generischen HTTP-Methoden wie GET, POST, PUT und DELETE bereitstellte. Obwohl REST den Datenzugriff vereinfacht, gibt die API oft mehr Metadaten zurück, als benötigt werden. REST-APIs erfordern auch mehr Informationen über das Netzwerk (z. B. wohin eine Anforderung gesendet werden soll), sodass sie nicht so schlank und effizient sind wie RPCs.
Durch die Übernahme neuerer Technologien aktualisiert gRPC die ältere RPC-Methode, um sie dialogfähig und effizienter zu machen. Dies ist heute eine attraktive Wahl bei der Entwicklung von APIs für Microservices-Architekturen.
Einige der Vorteile von gRPC sind:
Insgesamt bietet gRPC ein leistungsstarkes, flexibles Framework, das sich ideal für die Kommunikation zwischen Diensten in hochgradig verteilten Microservices-Architekturen eignet.
Die Vorteile und der Nutzen von gRPC ergeben sich im Wesentlichen aus der Anwendung von zwei Technologien:
gRPC verwendet Protocol Buffer (oder Protobufs) zur Definition von Diensten und Nachrichten anstelle von XML oder JSON. gRPC ist ein sprachneutraler Mechanismus zur Serialisierung strukturierter Nachrichten, die sich die Dienste gegenseitig zusenden.
Ähnlich dem Konzept der OpenAPI-Spezifikation für REST-APIs wird der API-Vertrag in gRPC in einer .proto-Textdatei implementiert, in der der Entwickler definiert, wie die Daten strukturiert werden sollen. Anschließend kompiliert ein Protoc-Compiler die .proto-Textdatei automatisch in jede unterstützte Sprache. Zur Laufzeit werden die Nachrichten komprimiert und in einem Binärformat gesendet.
Dies bietet zwei entscheidende Vorteile:
Üblicherweise 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 bringt einige entscheidende Vorteile mit sich. Einer dieser Vorteile ist die Möglichkeit, Kommunikation im Binärformat zu senden. Darüber hinaus unterstützt HTTP/2 die Möglichkeit, mehrere parallele Anforderungen zu verarbeiten, anstatt nur eine Anforderung auf einmal zu bearbeiten. Die Kommunikation ist außerdem bidirektional, was bedeutet, dass eine einzelne Verbindung sowohl Anforderungen als auch Antworten gleichzeitig senden kann.
Insgesamt wird dadurch die Leistung verbessert und die Netzwerkauslastung reduziert, was besonders in einer stark ausgelasteten Microservices-Architektur von Vorteil sein kann. Es gibt jedoch einige Einschränkungen: HTTP/2 wird von modernen Webbrowsern nicht generell unterstützt, sodass Sie möglicherweise einen Reverse Proxy wie NGINX verwenden müssen, um die Anwendung bereitzustellen.
Heutzutage ist REST der vorherrschende API-Designstil und bietet daher einen nützlichen Referenzpunkt für den Vergleich mit gRPC. Sowohl REST als auch gRPC sind gültige Ansätze für die Erstellung von APIs für Webanwendungen und Microservices, und der eine ist nicht unbedingt besser als der andere. Dennoch ist es nützlich, die wichtigsten Unterschiede zu kennen, um das beste Tool für die Tätigkeit auszuwählen.
Einige der wichtigsten Unterschiede zwischen gRPC und REST fallen unter diese Kategorien:
Während REST-APIs die Vorteile von HTTP/2 nutzen können, verwenden RESTful-Dienste üblicherweise das textbasierte HTTP/1.1 als Transportschicht. gRPC verwendet ausschließlich HTTP/2, ein binäres Protokoll, das effizienter ist und Funktionen wie Header-Komprimierung und Multiplexing über eine einzige TCP-Verbindung ermöglicht.
REST-APIs verwenden in der Regel JSON als Datenformat für das Senden und Empfangen von Daten. JSON ist textbasiert, leicht zu lesen und zu schreiben und wird weithin unterstützt. gRPC-APIs verwenden Protobufs, die in einem Binärformat vorliegen, das eine kleinere Nutzlast und eine schnellere Interaktion ermöglicht. Protobufs können jedoch nicht ohne Weiteres allein gelesen werden.
REST-APIs unterstützen ein Anforderung-Antwort-Modell mit begrenzter Unterstützung für Streaming. gRPC-APIs werden dagegen über HTTP/2 bereitgestellt und unterstützen mehrere Kommunikationsmuster, darunter Unary (Anforderung-Antwort), Server-Streaming, Client-Streaming und bidirektionales Streaming.
REST ist ein ressourcenzentriertes Modell, das Standard-HTTP-Methoden wie GET, POST, PUT und DELETE unterstützt. Jede Anforderung muss alle Informationen enthalten, die für ihre Bearbeitung erforderlich sind. Außerdem wird der API-Vertrag in der Regel unter Verwendung der OpenAPI-Spezifikation geschrieben, wobei die Codierung von Client und Server als separater Schritt behandelt wird. Im Gegensatz dazu ist gRPC ein dienstzentriertes Modell, bei dem Nachrichten und Dienste in der .proto-Datei definiert werden. Die Datei kann verwendet werden, um Code sowohl für den API-Client als auch für den Server zu generieren.
REST kann aufgrund der textbasierten Datenübertragung über HTTP/1.1 langsamer sein. Jede Anforderung erfordert einen TCP-Handschlag, was zu einer gewissen Latenz führen kann. gRPC unterstützt mehrere Streams über HTTP/2, sodass mehrere Clients gleichzeitig mehrere Anforderungen senden können, ohne eine neue TCP-Verbindung aufbauen zu müssen. Es nutzt auch HTTP/2-Funktionen wie Header-Komprimierung.
REST verwendet Standard-HTTP-Statuscodes für die Fehlerbehandlung. gRPC bietet dagegen eine viel größere Granularität, um Fehlerstatuscodes zu definieren und sicherzustellen, dass sie konsistent sind. Standardmäßig ist das gRPC-Modell recht begrenzt, wird aber meist durch ein von Google entwickeltes umfassenderes Fehlermodell erweitert.
REST wird von praktisch allen Sprachen unterstützt, bietet jedoch keine integrierten Funktionen für die Codegenerierung. Die Implementierung bleibt ganz dem Entwickler überlassen. gRPC bietet mit seinem protoc-Compiler native Codegenerierung für mehrere Programmiersprachen.
Zusammenfassend lässt sich sagen, dass die Entscheidung zwischen gRPC und REST davon abhängt, was Sie erreichen möchten. gRPC bietet eine effiziente, leistungsstarke Methode für die Kommunikation von Diensten in einer verteilten Anwendung. Allerdings kann es nicht direkt von Webbrowsern und anderen Clients gelesen werden und erfordert ein API-Gateway oder einen Reverse Proxy wie NGINX, um mit Front-End-Clients zu interagieren. Es ist eine hervorragende Option für interne APIs, die Teil einer ereignisgesteuerten Microservices-Architektur sind.
REST hingegen ist weit verbreitet und wird in praktisch jeder Sprache unterstützt. Es ist sowohl für Menschen als auch für Maschinen lesbar, da die Daten in JSON oder XML ausgetauscht werden. Außerdem ist die Lernkurve für den Einstieg wesentlich niedriger und wird von vielen Webbrowsern unterstützt, was es ideal für öffentlich zugängliche APIs macht.
gRPC ist eine der besten Optionen für die Kommunikation in einer Microservices-Architektur. Das liegt zum Teil an der Leistung, aber auch an der flexiblen Sprachunterstützung. Entwickler können gRPC-Clients und -Server, die in ihrer bevorzugten Sprache ausgeführt werden, leicht erstellen und generieren. Da gRPC den API-Vertrag in einem binären Format beschreibt, können Microservices unabhängig von den Sprachen, in denen sie erstellt wurden, kommunizieren.
Eine der gängigsten gRPC-basierten Microservices-Architekturen besteht darin, den Microservices ein API-Gateway vorzuschalten und dann die gesamte interne Kommunikation über gRPC abzuwickeln. Das API-Gateway verarbeitet eingehende Anforderungen, die über HTTP/1.1 eingehen, und leitet sie als gRPC-Anforderungen über HTTP/2 an die Microservices weiter.
Mit der zunehmenden Verbreitung von gRPC müssen Entwickler und Sicherheitsteams sicherstellen, dass wirksame Sicherheitslösungen vorhanden sind. Da gRPC-Nachrichten im Binärformat vorliegen, können bei Geräten und Tools, die eine ASCII-basierte Kommunikation erwarten, Probleme auftreten.
gRPC-APIs sind auch anfällig für viele der häufigsten API-Sicherheitsbedrohungen. Standard-API-Sicherheitspraktiken wie Zugriffskontrolle, Verschlüsselung und Laufzeitschutz sind in gRPC-basierten Architekturen ebenso wichtig.
gRPC-Anwendungen und APIs erfordern ein ganzheitliches Sicherheitskonzept. Einige der bewährten Praktiken zur Sicherung von gRPCs sind:
Letztendlich sollten Sie überprüfen, ob Ihr API-Gateway, Ihre Web Application Firewall (WAF) und andere API-Verwaltungs- und Sicherheitstools der Aufgabe gewachsen sind, Ihre gRPC-Anwendungen und APIs in der Produktion zu schützen. Sie sollten in der Lage sein, die .proto-Datei für jeden Dienst zu importieren und sie zu verwenden, um Sicherheitsschutz für die gRPC-Anwendung und APIs anzuwenden.
gRPC gewinnt als beliebte Alternative für Entwickler und große Unternehmen wie Netflix und Lyft, die es in Microservices-Architekturen einsetzen, immer mehr an Bedeutung. gRPC ist jedoch weder ein Ersatz für REST-APIs noch eine von Natur aus bessere Methode zur Erstellung von APIs. gRPC ist einfach eine Alternative, die Sie in Betracht ziehen sollten, wenn Sie hauptsächlich APIs für eine interne Microservices-Umgebung erstellen und effiziente Echtzeitkommunikation benötigen.
Mit Blick auf die Zukunft wird gRPC aufgrund seiner Leistungsvorteile und der einfachen Entwicklung wahrscheinlich weiter an Bedeutung für Cloud-native Anwendungen gewinnen. In der Zwischenzeit werden Entwickler, die APIs öffentlich zugänglich machen müssen, weiterhin REST in ihren Anwendungen verwenden. REST wird aufgrund seiner Abwärtskompatibilität und der tiefen Integration mit der bestehenden API-Infrastruktur und -Operationen auch in Cloud-nativen Umgebungen weiter bestehen.
NGINX bietet eine Vielzahl kostenloser Ressourcen, die Sie an jedem Punkt Ihrer gRPC-Reise unterstützen.