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 Maschinen ausgeführt werden kann.
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 in der Produktion verwendet und von einem großen Pool an Mitwirkenden unterstützt wird.
Um zu verstehen, warum Google gRPC entwickelt hat, werfen wir kurz einen Blick auf die Zeitleiste 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 tatsächlich einen Dienst aufrufen, der auf einem anderen Computer (normalerweise in Ihrem lokalen Netzwerk) ausgeführt wird.
In der Praxis ermöglicht dies Entwicklern, direkte Aktionen (wie SendUserMessages, addEntry usw.) zu verwenden, ohne Netzwerkdetails berücksichtigen zu müssen. RPC-Nachrichten sind leichtgewichtig und effizient, sie sind aber auch eng mit dem zugrunde liegenden System gekoppelt. Dadurch sind sie schwer zu integrieren und zu ändern und es besteht eine größere Wahrscheinlichkeit, dass Systemdetails preisgegeben werden.
Als die REST-API -Architektur eingeführt wurde, löste sie einige dieser Herausforderungen, indem sie eine einheitliche Möglichkeit für den Zugriff auf Daten und Ressourcen mithilfe generischer HTTP- Methoden wie GET, POST, PUT und DELETE bereitstellte. Obwohl REST den Datenzugriff vereinfacht, gibt die API oft mehr Metadaten zurück als nötig. REST-APIs erfordern außerdem mehr Informationen über das Netzwerk (z. B. wohin eine Anfrage gesendet werden soll), sodass sie nicht so leichtgewichtig und effizient sind wie RPCs.
Durch die Einführung neuerer Technologien aktualisiert gRPC die ältere RPC-Methode, um sie interoperabel und effizienter zu machen. Heutzutage ist dies eine attraktive Option bei der Entwicklung von APIs für Microservices -Architekturen.
Zu den Vorteilen von gRPC gehören unter anderem:
Insgesamt bietet gRPC ein leistungsstarkes, flexibles Framework, das sich ideal für die Kommunikation zwischen Diensten in stark verteilten Microservices-Architekturen eignet.
Die Vorteile und Nutzen von gRPC ergeben sich im Wesentlichen aus der Einführung zweier Technologien:
gRPC verwendet Protocol Buffers (oder Protobufs ), um Dienste und Nachrichten anstelle von XML oder JSON zu definieren. Es handelt sich dabei um einen sprachneutralen Mechanismus zur Serialisierung strukturierter Nachrichten, die die Dienste untereinander senden.
Ähnlich dem Konzept der OpenAPI-Spezifikation für REST-APIs wird der API-Vertrag in gRPC in einer .proto-Textdatei implementiert, in der ein Entwickler definiert, wie die Daten strukturiert werden sollen. Anschließend kompiliert ein Protokollcompiler die .proto-Textdatei automatisch in jede unterstützte Sprache. Zur Laufzeit werden die Nachrichten komprimiert und in einem Binärformat gesendet.
Dies bietet zwei wesentliche Vorteile:
Traditionell verwendeten REST-APIs HTTP/1.1 als Transportschicht. Obwohl REST-APIs auch über HTTP/2 bereitgestellt werden können, bietet die ausschließliche Verwendung von HTTP/2 durch gRPC einige entscheidende Vorteile. Einer dieser Vorteile ist die Möglichkeit, Nachrichten im Binärformat zu versenden. Darüber hinaus unterstützt HTTP/2 die Möglichkeit, mehrere Anfragen parallel zu verarbeiten, anstatt jeweils eine Anfrage nach der anderen zu bearbeiten. Die Kommunikation ist außerdem bidirektional, was bedeutet, dass eine einzelne Verbindung gleichzeitig Anfragen und Antworten senden kann.
Insgesamt wird dadurch die Leistung verbessert und die Netzwerkauslastung reduziert, was insbesondere in einer stark ausgelasteten Microservices-Architektur wertvoll sein kann. Es gibt jedoch einige Einschränkungen. HTTP/2 wird von modernen Webbrowsern im Allgemeinen nicht unterstützt, daher müssen Sie möglicherweise einen Reverse-Proxy wie NGINX verwenden, um die Anwendung bereitzustellen.
Heute ist REST der vorherrschende API-Designstil und stellt daher einen nützlichen Referenzpunkt für den Vergleich mit gRPC dar. Sowohl REST als auch gRPC sind gültige Ansätze zum Erstellen von APIs für Webanwendungen und Microservices, und keiner ist unbedingt besser als der andere. Dennoch ist es hilfreich, die wichtigsten Unterschiede zu kennen, um das beste Werkzeug für die jeweilige Aufgabe auszuwählen.
Einige der wichtigsten Unterschiede zwischen gRPC und REST fallen in diese Kategorien:
Während REST-APIs die Vorteile von HTTP/2 nutzen können, verwenden RESTful-Dienste traditionell 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 einzelne TCP-Verbindung ermöglicht.
REST-APIs verwenden normalerweise 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 eine geringere Nutzlast und schnellere Interaktion bietet. Allerdings können Protobufs nicht ohne weiteres eigenständig gelesen werden.
REST-APIs unterstützen ein Anforderungs-Antwort-Modell mit eingeschränkter Unterstützung für Streaming. Im Gegensatz dazu werden gRPC-APIs ü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 Anfrage muss alle für ihre Bearbeitung notwendigen Informationen enthalten. Darüber hinaus wird der API-Vertrag normalerweise unter Verwendung der OpenAPI-Spezifikation geschrieben, wobei die Codierung von Client und Server als separater Schritt behandelt wird. Im Gegensatz dazu ist gRPC ein servicezentriertes Modell, bei dem Nachrichten und Dienste in der .proto-Datei definiert werden. Die Datei kann zum Generieren von Code sowohl für den API-Client als auch für den API-Server verwendet werden.
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 mehrere Anfragen gleichzeitig senden können, ohne eine neue TCP-Verbindung herzustellen. Es nutzt auch HTTP/2-Funktionen wie die Header-Komprimierung.
REST verwendet standardmäßige HTTP-Statuscodes zur Fehlerbehandlung. Im Gegensatz dazu bietet gRPC eine viel größere Granularität bei der Definition von Fehlerstatuscodes und stellt sicher, dass diese konsistent sind. Standardmäßig ist das gRPC-Modell recht eingeschränkt, wird aber am häufigsten mithilfe eines umfangreicheren Fehlermodells erweitert, das von Google entwickelt wurde .
REST wird von nahezu allen Sprachen unterstützt, bietet jedoch keine integrierten Funktionen zur Codegenerierung. Die Implementierung bleibt vollständig dem Entwickler überlassen. Mit seinem Protokollcompiler ermöglicht gRPC native Codegenerierung für mehrere Programmiersprachen.
Zusammenfassend hängt die Wahl zwischen gRPC und REST davon ab, was Sie erreichen müssen. gRPC bietet eine effiziente und 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 zur Interaktion mit Front-End-Clients ein API-Gateway oder einen Reverse-Proxy wie NGINX. 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 für Menschen und Maschinen lesbar, da der Datenaustausch mithilfe von JSON oder XML erfolgt. Darüber hinaus ist der Lernaufwand für den Einstieg wesentlich geringer und es 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. Dies liegt teilweise an der Leistung, aber auch an der Flexibilität bei der Sprachunterstützung. Entwickler können problemlos gRPC-Clients und -Server erstellen und generieren, die in ihrer bevorzugten Sprache ausgeführt werden. Da gRPC den API-Vertrag in einem Binärformat beschreibt, können Microservices unabhängig von den Sprachen kommunizieren, die zu ihrer Erstellung verwendet wurden.
Eine der gängigsten gRPC-basierten Microservices-Architekturen besteht darin, den Microservices ein API-Gateway vorzusetzen und dann die gesamte interne Kommunikation über gRPC abzuwickeln. Das API-Gateway verarbeitet eingehende Anfragen von HTTP/1.1 und leitet sie als gRPC-Anfragen über HTTP/2 an die Microservices weiter.
Da die Verbreitung von gRPC weiter zunimmt, 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 ASCII-basierte Kommunikation erwarten, Probleme auftreten.
gRPC-APIs sind auch anfällig für viele der häufigsten API-Sicherheitsbedrohungen . Standardmäßige API-Sicherheitspraktiken wie Zugriffskontrolle, Verschlüsselung und Laufzeitschutz sind in gRPC-basierten Architekturen ebenso wichtig.
gRPC-Anwendungen und APIs erfordern einen ganzheitlichen Sicherheitsansatz. Zu den Best Practices zum Sichern von gRPCs gehören:
Abschließend 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 Sicherheitsvorkehrungen für die gRPC-Anwendung und APIs anzuwenden.
gRPC erfreut sich bei Entwicklern und großen Unternehmen wie Netflix und Lyft zunehmender Beliebtheit als beliebte Alternative zur Verwendung in Microservices-Architekturen. Allerdings ist gRPC weder ein Ersatz für REST-APIs noch grundsätzlich eine bessere Methode zum Erstellen von APIs. gRPC ist lediglich eine Alternative, die Sie in Betracht ziehen sollten, wenn Sie hauptsächlich APIs für eine interne Microservices-Umgebung erstellen und eine effiziente Echtzeitkommunikation benötigen.
Mit Blick auf die Zukunft dürfte gRPC aufgrund seiner Leistungsvorteile und der einfachen Entwicklung bei Cloud-nativen Anwendungen weiterhin an Bedeutung gewinnen. Entwickler, die APIs öffentlich zugänglich machen müssen, werden in der Zwischenzeit weiterhin REST in ihren Anwendungen verwenden. REST wird aufgrund seiner Abwärtskompatibilität und tiefen Integration mit der vorhandenen API-Infrastruktur und -Operationen auch weiterhin in Cloud-nativen Umgebungen existieren.
NGINX bietet eine Vielzahl kostenloser Ressourcen, die Sie an jedem Punkt Ihrer gRPC-Reise unterstützen.