gRPC

Tipp

Diese Inhalte sind ein Auszug aus dem E-Book „Architecting Cloud Native .NET Applications for Azure“, verfügbar in der .NET-Dokumentation oder als kostenlos herunterladbare PDF-Datei, die offline gelesen werden kann.

PDF herunterladen

Bisher haben wir uns in diesem Buch auf die REST-basierte Kommunikation konzentriert. Wir haben gesehen, dass REST ein flexibler Architekturstil ist, der CRUD-basierte Vorgänge für Entitätsressourcen definiert. Clients interagieren über HTTP über ein Anforderungs-Antwort-Kommunikationsmodell mit Ressourcen. Auch wenn REST weit verbreitet ist, hat eine neuere Kommunikationstechnologie, gRPC, in der cloudnativen Community enormes Interesse geweckt.

Was ist gRPC?

gRPC ist ein modernes, leistungsstarkes Framework, das basierend auf dem uralten RPC-Protokoll (Remote Procedure Call) weiterentwickelt wurde. Auf Anwendungsebene optimiert gRPC das Messaging zwischen Clients und Back-End-Diensten. gRPC stammt von Google und ist Open Source und Teil des CNCF-Ökosystems (Cloud Native Computing Foundation) mit cloudnativen Angeboten. CNCF betrachtet gRPC als Projekt in der Inkubationsphase. Inkubation bedeutet, dass Endbenutzer*innen die Technologie bereits in Produktionsanwendungen verwenden und dass das Projekt über eine ausreichende Anzahl von Mitwirkenden verfügt.

Eine typische gRPC-Client-App macht eine lokale In-Process-Funktion verfügbar, die einen Geschäftsvorgang implementiert. Im Hintergrund ruft diese lokale Funktion eine andere Funktion auf einem Remotecomputer auf. Was wie ein lokaler Aufruf aussieht, ist im Wesentlichen ein transparenter Out-of-Process-Aufruf eines Remotediensts. Die RPC-Verbindung abstrahiert die Point-to-Point-Netzwerkkommunikation, Serialisierung und Ausführung zwischen Computern.

In cloudnativen Anwendungen arbeiten Entwickler*innen häufig mit verschiedenen Programmiersprachen, Frameworks und Technologien. Diese Interoperabilität erschwert Nachrichtenverträge und die für die plattformübergreifende Kommunikation erforderlichen Verbindungen. gRPC bietet eine „einheitliche horizontale Schicht“, um diese Herausforderungen zu abstrahieren. Die Entwickler*innen können auf ihrer nativen Plattform programmieren und sich auf die Geschäftsfunktionalität konzentrieren, während gRPC für die Kommunikationsverbindungen sorgt.

gRPC bietet umfassende Unterstützung für die meisten gängigen Entwicklungsstapel, einschließlich Java, JavaScript, C#, Go, Swift und Node.js.

Vorteile von gRPC

gRPC verwendet als Transportprotokoll HTTP/2. HTTP/2 ist zwar mit HTTP 1.1 kompatibel, bietet jedoch viele erweiterte Funktionen:

• Ein binäres Rahmenprotokoll für den Datentransport – im Gegensatz zu HTTP 1.1, das textbasiert ist
• Multiplexingunterstützung für das Senden mehrerer paralleler Anforderungen über dieselbe Verbindung – HTTP 1.1 schränkt die Verarbeitung auf jeweils eine Anforderungs-/Antwortnachricht ein
• Bidirektionale Vollduplexkommunikation zum gleichzeitigen Senden von Clientanforderungen und Serverantworten
• Integriertes asynchrones Streaming großer Datasets in Anforderungen und Antworten
• Headerkomprimierung zur Reduzierung der Netzwerknutzung

gRPC ist ressourcenschonend und extrem leistungsstark. Es kann bis zu 8-mal schneller als die JSON-Serialisierung sein und dabei 60–80 % kleinere Nachrichten generieren. Im Sprachgebrauch der Microsoft Windows Communication Foundation (WCF) übertrifft gRPC die Geschwindigkeit und Effizienz von hochoptimierten NetTCP-Bindungen. Im Gegensatz zu NetTCP, das den Microsoft-Stapel bevorzugt, ist gRPC plattformübergreifend.

Protokollpuffer

gRPC nutzt eine Open-Source-Technologie namens Protokollpuffer. Zusammen bieten sie ein hocheffizientes und plattformunabhängiges Serialisierungsformat zum Serialisieren strukturierter Nachrichten, die Dienste untereinander senden. Mithilfe einer plattformübergreifenden IDL (Interface Definition Language) definieren Entwickler*innen einen Dienstvertrag für jeden Microservice. Der Vertrag, der als textbasierte .proto-Datei implementiert ist, beschreibt die Methoden, Eingaben und Ausgaben für jeden Dienst. Eine solche Vertragsdatei kann für gRPC-Clients und -Dienste gleichermaßen verwendet werden, selbst wenn diese auf verschiedenen Entwicklungsplattformen basieren.

Mithilfe der PROTO-Datei generiert der Protobuf-Compiler protoc sowohl Client- als auch Dienstcode für Ihre Zielplattform. Der Code umfasst die folgenden Komponenten:

• Stark typisierte Objekte, die vom Client und Dienst gemeinsam genutzt werden und die Dienstvorgänge und Datenelemente für eine Nachricht darstellen
• Eine stark typisierte Basisklasse mit den erforderlichen Netzwerkverbindungen, die vom Remote-gRPC-Dienst geerbt und erweitert werden kann
• Ein Clientstub mit den zum Aufrufen des Remote-gRPC-Diensts erforderlichen Verbindungen

Zur Laufzeit wird jede Nachricht als Protobuf-Standarddarstellung serialisiert und zwischen dem Client und dem Remotedienst ausgetauscht. Im Gegensatz zu JSON oder XML werden Protobuf-Nachrichten als kompilierte Binärbytes serialisiert.

gRPC-Unterstützung in .NET

gRPC ist im .NET Core 3.0 SDK und höher integriert. Es wird von den folgenden Tools unterstützt:

• Visual Studio 2022 mit ASP.NET und installierter Webentwicklungsworkload
• Visual Studio Code
• Die dotnet-CLI

Das SDK umfasst Tools für Endpunktrouting, integrierte IoC und Protokollierung. Der Kestrel-Open-Source-Webserver unterstützt HTTP/2-Verbindungen. Abbildung 4-20 zeigt eine Visual Studio 2022-Vorlage, die ein Rahmenprojekt für einen gRPC-Dienst einrichtet. Beachten Sie, dass .NET Windows, Linux und macOS vollständig unterstützt.

Abbildung 4-20: gRPC-Unterstützung in Visual Studio 2022

Abbildung 4-21 zeigt das Gerüst des gRPC-Diensts, das aus dem integrierten Gerüst in Visual Studio 2022 generiert wurde.

Abbildung 4-21: gRPC-Projekt in Visual Studio 2022

Beachten Sie in der obigen Abbildung die PROTO-Beschreibungsdatei und den Dienstcode. Wie Sie in Kürze sehen werden, generiert Visual Studio zusätzliche Konfigurationen sowohl in der Startup-Klasse als auch in der zugrunde liegenden Projektdatei.

Verwenden von gRPC

Verwenden Sie gRPC in folgenden Szenarien:

• Synchrone Back-End-Kommunikation zwischen Microservices, bei der eine sofortige Antwort erforderlich ist, um die Verarbeitung fortzusetzen
• Umgebungen mit unterschiedlichen Sprachen, in denen verschiedene Programmierplattformen unterstützt werden müssen
• Kommunikation mit niedriger Latenz und hohem Durchsatz, wenn die Leistung von entscheidender Bedeutung ist
• Point-to-Point-Echtzeitkommunikation: gRPC kann Nachrichten ohne Abruf in Echtzeit pushen und bietet hervorragende Unterstützung für bidirektionales Streaming.
• Eingeschränkte Netzwerkumgebungen: Binäre gRPC-Nachrichten sind immer kleiner als entsprechende JSON-Nachrichten im Textformat.

Zum Zeitpunkt der Erstellung dieses Dokuments wird gRPC hauptsächlich mit Back-End-Diensten verwendet. Moderne Browser können nicht den Grad an HTTP/2-Steuerung bereitstellen, der zur Unterstützung eines Front-End-gRPC-Clients erforderlich ist. Allerdings gibt es Unterstützung für gRPC-Web mit .NET, durch die gRPC-Kommunikation von browserbasierten Apps ermöglicht wird, die mit JavaScript oder Blazor WebAssembly-Technologien erstellt wurden. gRPC-Web ermöglicht einer ASP.NET Core-gRPC-App die Unterstützung von gRPC-Features in Browser-Apps:

• Stark typisierte, codegenerierte Clients
• Kompakte Protobuf-Nachrichten
• Serverstreaming

Implementieren von gRPC

Die Microservice-Referenzarchitektur eShop on Containers von Microsoft veranschaulicht, wie gRPC-Dienste in .NET-Anwendungen implementiert werden. In Abbildung 4-22 ist die Back-End-Architektur dargestellt.

Abbildung 4-22. Back-End-Architektur für „eShop on Containers“

Beachten Sie in der obigen Abbildung, dass eShop das BFF-Muster (Back-End für Front-Ends) umsetzt, indem mehrere API-Gateways verfügbar gemacht werden. Das BFF-Muster wurde bereits weiter oben in diesem Kapitel erläutert. Achten Sie genau auf den Aggregator-Microservice (grau), der sich zwischen dem API-Gateway „Web-Shopping“ und den Shopping-Microservices am Back-End befindet. Der Aggregator empfängt eine Anforderung von einem Client, leitet sie an verschiedene Microservices weiter, aggregiert die Ergebnisse und sendet diese zurück an den anfordernden Client. Damit bei solchen Vorgängen eine sofortige Antwort möglich ist, erfordern sie in der Regel die synchrone Kommunikation. Bei eShop werden Back-End-Aufrufe vom Aggregator mithilfe von gRPC ausgeführt, wie in Abbildung 4-23 dargestellt.

Abbildung 4-23. gRPC in „eShop on Containers“

Die gRPC-Kommunikation erfordert sowohl Client- als auch Serverkomponenten. Beachten Sie in der vorherigen Abbildung, dass der Shopping-Aggregator einen gRPC-Client implementiert. Der Client führt synchrone gRPC-Aufrufe (rot) an Back-End-Microservices aus, die jeweils einen gRPC-Server implementieren. Sowohl der Client als auch der Server nutzen die integrierten gRPC-Verbindungen vom .NET SDK. Clientseitige Stubs stellen die Verbindungen zum Auslösen von gRPC-Remoteaufrufen bereit. Die serverseitigen Komponenten stellen gRPC-Verbindungen bereit, die von den benutzerdefinierten Dienstklassen geerbt und verwendet werden können.

Microservices, die sowohl eine RESTful-API als auch gRPC-Kommunikation verfügbar machen, benötigen für die Verwaltung des Datenverkehrs mehrere Endpunkte. Sie würden einen Endpunkt öffnen, der auf HTTP-Datenverkehr für die RESTful-Aufrufe lauscht, und einen weiteren für gRPC-Aufrufe. Der gRPC-Endpunkt muss für das HTTP/2-Protokoll konfiguriert werden, das für die gRPC-Kommunikation erforderlich ist.

Obwohl versucht wird, Microservices von asynchronen Kommunikationsmustern zu entkoppeln, erfordern einige Vorgänge direkte Aufrufe. gRPC sollte jedoch die primäre Wahl für die direkte synchrone Kommunikation zwischen Microservices sein. Das leistungsstarke Kommunikationsprotokoll auf Basis von HTTP/2 und Protokollpuffern macht es zur perfekten Wahl.

Blick in die Zukunft

Es ist davon auszugehen, dass gRPC für cloudnative Systeme in Zukunft weiter an Bedeutung gewinnen wird. Die Leistungsvorteile und die einfache Entwicklung sind überzeugend. REST wird jedoch wahrscheinlich noch lange Zeit bleiben. Es zeichnet sich durch öffentlich zugängliche APIs aus und ist aus Gründen der Abwärtskompatibilität notwendig.

ZurückWeiter