Freigeben über

Vergleich von gRPC-Diensten mit HTTP-APIs

  • Artikel

Hinweis

Dies ist nicht die neueste Version dieses Artikels. Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.

Warnung

Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Supportrichtlinie für .NET und .NET Core. Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.

Wichtig

Diese Informationen beziehen sich auf ein Vorabversionsprodukt, das vor der kommerziellen Freigabe möglicherweise noch wesentlichen Änderungen unterliegt. Microsoft gibt keine Garantie, weder ausdrücklich noch impliziert, hinsichtlich der hier bereitgestellten Informationen.

Informationen zum aktuellen Release finden Sie in der .NET 8-Version dieses Artikels.

Von James Newton-King

In diesem Artikel wird der Vergleich von gRPC-Diensten mit HTTP-APIs mit JSON (einschließlich ASP.NET Core-Web-APIs) erläutert. Die Technologie, mit der eine API für Ihre App bereitgestellt wird, ist eine wichtige Wahl, und gRPC bietet im Vergleich zu HTTP-APIs besondere Vorteile. In diesem Artikel werden die Stärken und Schwächen von gRPC erläutert und Szenarien empfohlen, in denen gRPC gegenüber anderen Technologien bevorzugt zu verwenden ist.

Allgemeiner Vergleich

Die folgende Tabelle bietet einen allgemeinen Vergleich der Features von gRPC und HTTP-APIs mit JSON.

Funktion gRPC HTTP-APIs mit JSON
Vertrag Erforderlich (.proto) Optional (OpenAPI)
Protokoll HTTP/2 HTTP
Payload Protobuf (klein, binär) JSON (groß, für Menschen lesbar)
Präskriptivität Strikte Spezifikation Locker. Jedes HTTP ist gültig.
Streaming Client, Server, bidirektional Client, Server
Browserunterstützung Nein (erfordert grpc-web) Ja
Sicherheit Transport (TLS) Transport (TLS)
Clientcodegenerierung Ja OpenAPI + Tools von Drittanbietern

gRPC-Stärken

Leistung

gRPC-Nachrichten werden mit Protobuf serialisiert, einem effizienten binären Nachrichtenformat. Protobuf wird sehr schnell auf dem Server und dem Client serialisiert. Die Protobuf-Serialisierung führt zu kleinen Nachrichtennutzlasten, was in Szenarien mit begrenzter Bandbreite wichtig ist, z. B. bei mobilen Apps.

gRPC wurde für HTTP/2 konzipiert, eine umfassende Überarbeitung von HTTP, die erhebliche Leistungsvorteile gegenüber HTTP 1.x bietet:

  • Binäre Rahmen und Komprimierung. Das HTTP/2-Protokoll ist sowohl beim Senden als auch beim Empfangen kompakt und effizient.
  • Multiplexing mehrerer HTTP/2-Aufrufe über eine einzelne TCP-Verbindung. Durch Multiplexing werden Head-of-Line-Blockierungen beseitigt.

HTTP/2 ist nicht exklusiv für GrpC. Viele Anforderungstypen, einschließlich HTTP-APIs mit JSON, können HTTP/2 verwenden und von dessen Leistungsverbesserungen profitieren.

Codeerzeugung

Alle gRPC-Frameworks bieten erstklassige Unterstützung für die Codegenerierung. Eine grundlegende Datei für die gRPC-Entwicklung ist die .proto-Datei, die den Vertrag der gRPC-Dienste und -Nachrichten definiert. Aus dieser Datei generieren die gRPC-Frameworks eine Dienstbasisklasse, Nachrichten und einen vollständigen Client.

Durch die Freigabe der .proto-Datei zwischen dem Server und dem Client können Nachrichten und Clientcode von Ende zu Ende generiert werden. Die Codegenerierung des Clients verhindert die Duplizierung von Nachrichten auf dem Client und dem Server und erstellt einen stark typisierten Client für Sie. Wenn Sie keinen Client schreiben müssen, sparen Sie bei Anwendungen mit vielen Diensten erheblich an Entwicklungszeit.

Strikte Spezifikation

Eine formale Spezifikation für die HTTP-API mit JSON existiert nicht. Entwickler diskutieren über das beste Format für URLs, HTTP-Verben und Antwortcodes.

Die gRPC-Spezifikation gibt vor, welchem Format ein gRPC-Dienst folgen muss. gRPC macht Diskussionen überflüssig und spart Entwicklern Zeit, da gRPC über Plattformen und Implementierungen hinweg konsistent ist.

Streaming

HTTP/2 bietet eine Grundlage für langlebige Echtzeitkommunikationsdatenströme. gRPC bietet erstklassige Unterstützung für das Streaming über HTTP/2.

Ein gRPC-Dienst unterstützt alle Streamingkombinationen:

  • Unär (kein Streaming)
  • Streaming vom Server zum Client
  • Streaming vom Client zum Server
  • Bidirektionales Streaming

Stichtag/Zeitlimits und Abbruch

Mit gRPC können Clients angeben, wie lange sie bereit sind, auf den RPC-Abschluss zu warten. Der Stichtag wird an den Server gesendet, und der Server kann entscheiden, welche Aktion bei einer Überschreitung der Frist durchgeführt werden soll. Der Server kann z. B. in Bearbeitung befindliche gRPC-/HTTP-/Datenbankanforderungen bei einem Timeout abbrechen.

Die Weitergabe des Stichtags und des Abbruchs durch untergeordnete gRPC-Aufrufe hilft bei der Durchsetzung der Ressourcennutzungslimits.

gRPC ist für die folgenden Szenarien besonders geeignet:

  • Microservices: gRPC ist für kurze Wartezeiten und Kommunikation mit hohem Durchsatz konzipiert. gRPC eignet sich hervorragend für einfache Microservices, bei denen die Effizienz entscheidend ist.
  • Punkt-zu-Punkt-Echtzeitkommunikation: gRPC weist eine ausgezeichnete Unterstützung für bidirektionales Streaming auf. gRPC-Dienste können Nachrichten in Echtzeit und ohne Abrufen bereitstellen.
  • Mehrsprachige Umgebungen: gRPC-Tools unterstützen alle gängigen Entwicklungssprachen, was gRPC zu einer guten Wahl für mehrsprachige Umgebungen macht.
  • Umgebungen mit Netzwerkbeschränkungen: gRPC-Nachrichten werden mit Protobuf serialisiert, einem einfachen Nachrichtenformat. Eine gRPC-Nachricht ist immer kleiner als eine entsprechende JSON-Nachricht.
  • Inter-Process Communication (IPC) : IPC-Transporte (z. B. UNIX-Domänensockets und Named Pipes) können mit gRPC für die Kommunikation zwischen Apps auf demselben Computer verwendet werden. Weitere Informationen finden Sie unter Inter-Process Communication mit gRPC.

Schwächen von gRPC

Eingeschränkte Browserunterstützung

Es ist heute unmöglich, einen gRPC-Dienst direkt von einem Browser aus aufzurufen. gRPC nutzt in hohem Maße HTTP/2-Features, und kein Browser bietet das für die Unterstützung eines gRPC-Clients erforderliche Maß an Kontrolle über Webanforderungen. Browser gestatten es einem Aufrufer z. B. nicht, die Verwendung von HTTP/2 zu erfordern oder den Zugriff auf zugrunde liegende HTTP/2-Frames zu ermöglichen.

gRPC für ASP.NET Core bietet zwei browserkompatible Lösungen:

  • Mit gRPC-Web können Browser-Apps gRPC-Dienste mithilfe des gRPC-Web-Clients und von Protobuf aufrufen. gRPC-Web fordert von der Browser-App das Generieren eines einen gRPC-Clients. Mit gRPC-Web können Browser-Apps von der Hochleistung und geringen Netzwerkauslastung von gRPC profitieren.

    .NET bietet integrierte Unterstützung für gRPC-Web. Weitere Informationen finden Sie unter gRPC-Web in ASP.NET Core gRPC-Apps.

  • Die gRPC JSON-Transcodierung ermöglicht es Browser-Apps, gRPC-Dienste so aufzurufen, als wären es RESTful-APIs mit JSON. Die Browser-App muss keinen gRPC-Client generieren und benötigt keine Informationen zu gRPC. RESTful-APIs können automatisch aus gRPC-Diensten erstellt werden, indem die Datei .proto mit HTTP-Metadaten ergänzt wird. Durch Transcodierung kann eine App sowohl gRPC- als auch JSON-Web-APIs unterstützen, ohne den Aufwand für die Entwicklung separater Dienste für beides zu verdoppeln.

    .NET bietet integrierte Unterstützung für das Erstellen von JSON-Web-APIs aus gRPC-Diensten. Weitere Informationen finden Sie unter gRPC JSON-Transcodierung in ASP.NET Core gRPC-Apps.

Hinweis

Die gRPC JSON-Transcodierung erfordert .NET 7 oder höher.

Nicht für Menschen lesbar

HTTP-API-Anforderungen werden als Text gesendet und können von Menschen gelesen und erstellt werden.

gRPC-Nachrichten werden standardmäßig mit Protobuf codiert. Obwohl Protobuf effizient zu senden und zu empfangen ist, ist sein binäres Format nicht für Menschen lesbar. Protobuf benötigt für eine ordnungsgemäße Deserialisierung die in der .proto-Datei angegebene Schnittstellenbeschreibung der Nachricht. Zusätzliche Tools sind erforderlich, um die Protobuf-Nutzlasten im Netzwerk zu analysieren und Anforderungen manuell zusammenzustellen.

Es gibt Features wie Serverreflexion und das gRPC-Befehlszeilentool, die bei binären Protobuf-Nachrichten helfen. Außerdem unterstützen Protobuf-Nachrichten die Konvertierung zu und von JSON. Die integrierte JSON-Konvertierung bietet eine effiziente Möglichkeit, Protobuf-Nachrichten beim Debuggen in und aus der für Menschen lesbaren Form zu konvertieren.

Alternative Frameworkszenarien

In den folgenden Szenarien werden andere Frameworks als gRPC empfohlen:

  • Über Browser zugängliche APIs: gRPC wird im Browser nicht vollständig unterstützt. gRPC-Web kann eine Browserunterstützung bieten, hat aber Einschränkungen und führt einen Serverproxy ein.
  • Übertragung von Echtzeitkommunikation: gRPC unterstützt Echtzeitkommunikation per Streaming, das Konzept der Übertragung einer Nachricht an registrierte Verbindungen existiert allerdings nicht. In einem Chatraum-Szenario, in dem z. B. neue Chatnachrichten an alle Clients im Chatraum gesendet werden sollen, ist jeder gRPC-Aufruf erforderlich, um neue Chatnachrichten einzeln an den Client zu senden. SignalR ist ein hilfreiches Framework für dieses Szenario. SignalR weist das Konzept der dauerhaften Verbindungen und der integrierten Unterstützung für das Senden von Nachrichten auf.

Zusätzliche Ressourcen