gRPC und Protocol Buffers

Die wichtigsten Befehle zum Merken

• grpcurl … list — angebotene Dienstnamen entdecken.
• grpcurl … describe — reflektierte Dienst- und Nachrichtendefinitionen lesen.

Befehle und Optionen

Option oder Argument	Bedeutung
-plaintext	Unverschlüsseltes HTTP/2 nur für dieses lokale Lab verwenden; normalerweise erwartet grpcurl TLS.
-max-time 5	Die Operation auf fünf Sekunden begrenzen.
localhost:50051	Vorhandener lokaler gRPC-Endpunkt.
list / describe	Symbole abfragen / deren Definitionen per Reflection ausgeben.

Reflection muss aktiviert sein. Nicht jeder Produktionsdienst bietet sie an. Es wird kein fachlicher RPC aufgerufen.

Die entscheidenden Konzepte

1. Ein RPC beschreibt entfernte Operationen durch einen Vertrag

gRPC erlaubt Methodenaufrufe auf entfernten Diensten anhand eines expliziten Vertrags. Generierte Stubs lassen den Aufruf lokal wirken. Das Netzwerk bringt trotzdem Latenz, Abbrüche und ungewisse Ergebnisse mit.

Der Vertrag benennt Dienste und Methoden und beschreibt Anfrage- sowie Antwortnachrichten. Ein Methodenname definiert keine Autorisierung oder Fachbedeutung. Beide Seiten müssen Schema und Verhalten gemeinsam verstehen.

2. Protocol Buffers definieren strukturierte Nachrichten

Protocol Buffers beschreiben Nachrichten durch typisierte, nummerierte Felder und bieten binäre Kodierung. Feldnummern identifizieren Daten auf der Leitung. Alte Nummern für neue Bedeutungen wiederzuverwenden kann Kompatibilität brechen.

Das von grpcurl gezeigte JSON ist eine Darstellung für Menschen, kein Beweis für JSON auf der Leitung. Schemaentwicklung braucht Disziplin: Kompatible Ergänzungen unterscheiden sich von geänderter Bedeutung oder neuen Anforderungen an alte Clients.

3. Aufrufe können einzelne Nachrichten oder Streams übertragen

gRPC unterstützt Unary, Server Streaming, Client Streaming und bidirektionales Streaming. Ein Stream transportiert eine Nachrichtenfolge statt eines grenzenlosen Datenblocks. Beide Seiten müssen Tempo, Abbruch und Teilfortschritt behandeln.

Der übliche Transport verwendet HTTP/2. Eine gelungene HTTP-Verbindung beweist keinen Methodenerfolg. gRPC-Status und Metadaten, häufig in Trailern, beschreiben das RPC-Ergebnis. HTTP 200 allein genügt nicht.

4. Deadlines begrenzen entferntes Warten

Eine Deadline begrenzt, wie lange der Client warten möchte. Cancellation signalisiert fehlendes Interesse am Ergebnis. Anwendung und nachgelagerte Arbeit müssen aber mitwirken, um Verarbeitung zu beenden.

Deadline Exceeded beweist nicht, dass der Server keine Seiteneffekte erzeugt hat. Wiederholte Änderungen können ohne Idempotenzstrategie doppelte Arbeit auslösen. Entfernte Aufrufe benötigen ausdrückliche Fehlersemantik.

Ein kleines Beispiel

Optional: Verwende das vorhandene lokale Lab mit Reflection. Die Befehle installieren oder starten keinen Server.

grpcurl -plaintext -max-time 5 localhost:50051 list
grpcurl -plaintext -max-time 5 localhost:50051 describe

Der erste Befehl listet Dienstnamen. Der zweite zeigt Definitionen mit RPC-Signaturen und Nachrichtenfeldern. Unterscheide Feldnummern und Typen von der Anzeigereihenfolge.

Fehlende Reflection bedeutet nicht zwingend defekte normale RPCs. Connection Refused betrifft den lokalen Endpunkt; TLS-Fehler können einen Transportwiderspruch zeigen. Verwende Klartext nicht für entfernte Dienste mit Zugangsdaten.

Das untersucht nur den Vertrag, nicht Autorisierung, Streaming oder fachlichen Erfolg. Dateien und Serverzustand bleiben unverändert. Aufräumen ist nicht erforderlich.

Merke dir: Der gRPC-Vertrag beschreibt Nachrichten und Methoden. Netzwerkfehler, Deadlines und fachliche Effekte brauchen eigene Behandlung.