Grundlegendes Verständnis von gRPC-Konzepte, Anwendungsfällen und besten Praktiken

Während wir mit der Anwendungsentwicklung vorankommen, gibt es unter vielen Dingen eines, worüber wir weniger besorgt sind: Rechenleistung. Dank der Erscheinung von Cloud-Anbietern machen wir uns weniger Sorgen über die Verwaltung von Rechenzentren. Alles ist innerhalb von Sekunden auf Anfrage verfügbar. Dies führt auch zu einer Vergrößerung der Datenmenge. Große Daten werden mit verschiedenen Medien in einzelnen Anfragen erzeugt und übertragen.

Mit der Zunahme der Datenmenge kommen Aktivitäten wie Serialisierung, Deserialisierung und Transportkosten hinzu. Obwohl wir uns nicht um Rechenressourcen sorgen, wird die Latenz zu einer Belastung. Wir müssen auf den Transport verzichten. In der Vergangenheit wurden viele Nachrichtenprotokolle entwickelt, um dies zu adressieren. SOAP war umfangreich und REST ist eine abgespeckte Version, aber wir benötigen ein noch effizienteres Framework. Und genau da kommt Remote Procedure Calls — RPC — ins Spiel.

In diesem Artikel werden wir verstehen, was RPC ist, und die verschiedenen Implementierungen von RPC, mit einem Schwerpunkt auf gRPC, der Implementierung von RPC von Google. Wir werden auch REST mit RPC vergleichen und verschiedene Aspekte von gRPC verstehen, einschließlich Sicherheit, Tooling und vieles mehr.

Was ist RPC?

RPC steht für Remote Procedure Calls. Die Definition steckt bereits im Namen. Verfahrensanrufe bedeuten einfach Funktions-/Methodenaufrufe; es ist das Wort „Remote“, das den Unterschied ausmacht. Was, wenn wir eine Funktion remote aufrufen könnten?

Einfach ausgedrückt: Wenn eine Funktion auf einem Server liegt und von der Client-Seite aufgerufen werden soll, können wir es dann so einfach gestalten wie einen Methoden-/Funktionsaufruf? Im Kern bietet eine RPC (Remote Procedure Call) dem Client die Illusion, eine lokale Methode aufzurufen, während tatsächlich eine Methode auf einem entfernten Computer ausgeführt wird, der die Netzwerkschichtaufgaben abstrahiert. Das Schöne daran ist, dass der Vertrag sehr streng und transparent gehalten wird (wir werden dies später im Artikel diskutieren).

Schritte bei einem RPC-Aufruf:

RPC-Sequenzfluss

So sieht ein typischer REST-Prozess aus:

RPCs reduzieren den Prozess auf Folgendes:

Dies liegt daran, dass alle mit der Anforderung verbundenen Komplikationen nun von uns abstrahiert sind (wir werden dies bei der Codegenerierung diskutieren). Sollten wir uns nur noch um die Daten und die Logik kümmern.

gRPC: Was, Warum und Wie es funktioniert

Bisher haben wir über RPC gesprochen, was im Wesentlichen bedeutet, Funktions-/Methodenaufrufe remote durchzuführen — und uns so Vorteile wie „strenge Vertragserklärung,“ „Abstraktion der Übertragung und Konvertierung von Daten,“ „Reduzierung der Latenz“ und so weiter bietet, über die wir in diesem Beitrag weitere Erörterungen führen werden. Wir möchten wirklich tief in eine der Implementierungen von RPC eintauchen. RPC ist ein Konzept und gRPC ist ein auf ihm basierendes Framework.

Es gibt verschiedene Implementierungen von RPCs. Sie sind:

• gRPC (google)

• Thrift (Facebook)

• Finalge (Twitter)

Die von Google entwickelte RPC-Version wird als gRPC bezeichnet. Sie wurde 2015 eingeführt und hat seitdem an Bedeutung gewonnen. Es ist eine der am häufigsten gewählten Kommunikationsmechanismen in einer Microservice-Architektur.

gRPC verwendet Protokoll-Puffer (eine quelloffene Nachrichtenformat) als Standardmethode der Kommunikation zwischen Client und Server. Darüber hinaus nutzt gRPC HTTP/2 als Standardprotokoll. Es gibt vier Arten von Kommunikation, die gRPC unterstützt:

• Unär [typische Client-Server-Kommunikation]

• Client-seitiges Streaming 

• Server-seitiges Streaming

• Bidirektionales Streaming

Kommen wir nun zum Nachrichtenformat, das in gRPC weit verbreitet ist — Protokollbuffers, auch bekannt als Protobufs. Ein Protobuf-Nachricht sieht ungefähr so aus:

Hier ist ‘Person’ die Nachricht, die wir übertragen möchten (als Teil von Anfrage/Antwort) und die die Felder ‘name’ (String-Typ), ‘id’ (String-Typ) und ‘email’ (String-Typ) hat. Die Zahlen 1,2,3 stellen die Position der Daten (wie bei ‘name’, ‘id’ und ‘email’) dar, wenn sie in binäre Form serialisiert werden.

Sobald der Entwickler die Protokoll-Buffer-Datei(en) mit allen Nachrichten erstellt hat, können wir einen Protokoll-Buffer-Compiler (eine Binärdatei) verwenden, um die geschriebene Protokoll-Buffer-Datei zu kompilieren, was alle Hilfsklassen und Methoden generiert, die zum Arbeiten mit der Nachricht benötigt werden. Zum Beispiel sieht der generierte Code (abhängig von der gewählten Sprache) wie hier aus, so.

Wie definieren wir Dienste?

Wir müssen Dienste definieren, die die oben genannten Nachrichten zum Senden/Empfangen verwenden.

Nach dem Schreiben der notwendigen Anforderungs- und Antwortnachrichtentypen ist der nächste Schritt das Schreiben des Dienstes selbst.

gRPC-Dienste werden auch in Protocol Buffers definiert und verwenden die Schlüsselwörter „service“ und „RPC“ zur Definition eines Dienstes.

Schauen Sie sich den Inhalt der folgenden proto-Datei an:

Hier sind HelloRequest und HelloResponse die Nachrichten und HelloService stellt einen unären RPC namens SayHello bereit, der HelloRequest als Eingabe verwendet und HelloResponse als Ausgabe liefert.

Wie erwähnt, enthält HelloService derzeit eine einzige unäre RPC. Es könnte jedoch mehr als eine RPC enthalten. Auch kann es eine Vielzahl von RPCs (unär/clientseitiges Streaming/serverseitiges Streaming/Bidirektional) enthalten.

Um eine Streaming-RPC zu definieren, müssen Sie lediglich „stream“ vor das Anforderungs-/Antwortargument setzen, Streaming RPCs Prototypendefinitionen und generierter Code.

Im oben genannten Code-Basis-Link:

• streaming.proto: Diese Datei ist vom Benutzer definiert

• streaming.pb.go & streaming_grpc.pb.go: Diese Dateien werden automatisch generiert, wenn der Proto-Compiler Befehl ausgeführt wird.

gRPC Vs. REST

Wir haben gRPC ausführlich besprochen. Auch wurde REST erwähnt. Was wir nicht diskutiert haben, ist der Unterschied. Ich meine, da wir bereits ein etabliertes, leichtgewichtiges Kommunikationsframework in Form von REST haben, warum gab es dann den Bedarf, nach einem anderen Kommunikationsframework zu suchen? Lassen Sie uns mehr über gRPC im Vergleich zu REST verstehen, zusammen mit den Vor- und Nachteilen von jedem davon.

Um einen Vergleich anzustellen, benötigen wir Parameter. Also lasst uns den Vergleich in folgende Parameter aufteilen:

• Nachrichtenformat: Protocol Buffers vs. JSON

  • Die Geschwindigkeit von Serialisierung und Deserialisierung ist bei Protocol Buffers im Vergleich zu JSON bei allen Datengrößen (klein/mittel/groß) deutlich besser. Benchmark-Test-Ergebnisse. 

  • Nach der Serialisierung ist JSON für Menschen lesbar, während Protobufs (in binärer Form) nicht lesbar sind. Es ist unklar, ob dies ein Nachteil ist oder nicht, da manchmal die Anforderungsdetails in den Google Developer Tools oder Kafka-Themen angezeigt werden möchten, und im Fall von Protobufs kann man nichts erkennen. 

• Kommunikationsprotokoll: HTTP 1.1 vs. HTTP/2T

  • REST basiert auf HTTP 1.1; die Kommunikation zwischen einem REST-Client und -Server erfordert eine etablierte TCP-Verbindung, die wiederum eine 3-Wege-Handshake-Beteiligung hat. Wenn wir eine Antwort vom Server erhalten, nachdem wir eine Anfrage vom Client gesendet haben, existiert die TCP-Verbindung danach nicht mehr. Es muss eine neue TCP-Verbindung hergestellt werden, um eine weitere Anfrage zu bearbeiten. Diese Etablierung einer TCP-Verbindung bei jeder einzelnen Anfrage führt zu einer Latenz.

  • So hat gRPC, das auf HTTP 2 basiert, dieses Problem durch eine dauerhafte Verbindung gelöst. Wir müssen uns daran erinnern, dass dauerhafte Verbindungen in HTTP 2 sich von denen in WebSockets unterscheiden, bei denen eine TCP-Verbindung entwendet und der Datentransfer unüberwacht ist. In einer gRPC-Verbindung wird eine einmal etablierte TCP-Verbindung für mehrere Anfragen wiederverwendet. Alle Anfragen von der gleichen Client- und Server-Paarung werden auf die gleiche TCP-Verbindung multiplexed.

• Nur um die Daten und die Logik besorgt sein: Die Code-Generierung als erste Klasse

  • Code-Generierungsfunktionen sind in gRPC durch seinen integrierten protoc-Compiler nativ vorhanden. Bei REST-APIs ist es notwendig, ein Drittanbieter-Tool wie Swagger zu verwenden, um den Code für API-Aufrufe in verschiedenen Sprachen automatisch zu generieren.

  • Im Fall von gRPC wird der Prozess des Marshalling/Unmarshalling, das Einrichten einer Verbindung und das Senden/Empfangen von Nachrichten abstrahiert; worüber wir uns alle Sorgen zu machen brauchen, sind die Daten, die wir senden oder empfangen möchten, und die Logik.

• Übertragungsgeschwindigkeit

  • Da das binäre Format viel leichter ist als das JSON-Format, ist die Übertragungsgeschwindigkeit bei gRPC 7 bis 10 Mal schneller als bei REST.

Nochmals, vorerst unterstützt gRPC keine Browser-Unterstützung, da die meisten UI-Frameworks immer noch begrenzte oder keine Unterstützung für gRPC bieten. Obwohl gRPC in den meisten Fällen die automatische Wahl ist, wenn es um die Kommunikation zwischen internen Microservices geht, ist dies bei externer Kommunikation, die eine UI-Integration erfordert, nicht der Fall.

Nachdem wir nun einen Vergleich der beiden Frameworks: gRPC und REST durchgeführt haben. Welches sollte verwendet werden und wann?

• In einer Microservice-Architektur mit mehreren leichtgewichtigen Microservices, bei denen die Effizienz der Datenübertragung von höchster Bedeutung ist, wäre gRPC eine ideale Wahl.

• Wenn die Code-Generierung mit Mehrsprachunterstützung eine Anforderung ist, sollte gRPC das bevorzugte Framework sein.

• Mit den Streaming-Fähigkeiten von gRPC profitieren Echtzeit-Apps wie Trading oder OTT eher davon als von der Polling-Methode mit REST.

• Bei Engpässen im Bandbreitenbereich würde gRPC eine wesentlich geringere Latenz und Durchsatz bieten.

• Wenn eine schnellere Entwicklung und hochgeschwindigte Iteration gefordert ist, sollte REST die bevorzugte Option sein.

gRPC Konzepte

Lastverteilung

Obwohl die dauerhafte Verbindung das Latenzproblem löst, schafft sie ein neues Problem in Form der Lastverteilung. Da gRPC (oder HTTP2) dauerhafte Verbindungen herstellt, bildet der Client auch bei Anwesenheit eines Lastbalancers eine dauerhafte Verbindung mit dem Server, der sich hinter dem Lastbalancer befindet. Dies ist analog zu einer sitzungsbezogenen Lastverteilung.

Wir können das Problem oder die Herausforderung über eine Demo verstehen. Und der Code und die Bereitstellungsdateien befinden sich unter: https://github.com/infracloudio/grpc-blog/tree/master/grpc-loadbalancing.

Aus der oben genannten Demo-Codebasis können wir erkennen, dass die Verantwortung für die Lastverteilung beim Client liegt. Dies führt dazu, dass der Vorteil von gRPC, nämlich die dauerhafte Verbindung, bei dieser Änderung nicht mehr existiert. gRPC kann jedoch weiterhin wegen seiner anderen Vorteile verwendet werden.

Erfahren Sie mehr über Lastverteilung in gRPC.

In der oben genannten Demo-Codebasis wird nur eine Strategie der Lastverteilung namens Round-Robin verwendet/vorgestellt. gRPC unterstützt jedoch auch eine andere clientbasierte Lastverteilungsstrategie namens OOB, die als „pick-first“ bezeichnet wird.

Darüber hinaus wird auch benutzerdefinierte clientseitige Lastverteilung unterstützt.

Sauberes Vertragsmodell

In REST wird der Vertrag zwischen Client und Server dokumentiert, aber nicht streng. Wenn wir noch weiter zurück gehen zu SOAP, wurden Verträge über wsdl-Dateien veröffentlicht. In REST werden Verträge über Swagger und andere Vorschriften veröffentlicht. Die Strenge fehlt jedoch, wir können nicht mit Sicherheit wissen, ob der Vertrag auf der Serverseite geändert wurde, während der Client-Code entwickelt wird.

Mit gRPC teilt sich die Vertragspräsentation entweder über Proto-Dateien oder über generierte Stub-Dateien aus den Proto-Dateien sowohl auf Client- als auch auf Serverseite. Dies ist vergleichbar mit einer Funktionsaufruf, jedoch remote. Und da wir einen Funktionsaufruf tätigen, wissen wir genau, was wir senden müssen und was wir als Antwort erwarten. Die Komplexität der Verbindungsherstellung mit dem Client, die Betreuung der Sicherheit, Serialisierung-Deserialisierung usw. werden abstrahiert. Worauf es uns ankommt, ist die Daten.

Betrachten Sie den folgenden Code-Basis:

https://github.com/infracloudio/grpc-blog/tree/master/greet_app     

Der Client verwendet den Stub (generierter Code aus der Proto-Datei) zur Erstellung eines Client-Objekts und zur Ausführung eines entfernten Funktionsaufrufs: 

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



cc, err := grpc.Dial(“<server-address>”, opts)

if err != nil {

    log.Fatalf("could not connect: %v", err)

}



c := greetpb.NewGreetServiceClient(cc)



res, err := c.Greet(context.Background(), req)

if err != nil {

    log.Fatalf("error while calling greet rpc : %v", err)

}

```

Ebenso nutzt der Server auch denselben Stub (generierter Code aus der Proto-Datei), um das Anforderungsobjekt zu empfangen und das Antwortobjekt zu erstellen:  

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



func (*server) Greet(_ context.Context, req *greetpb.GreetingRequest) (*greetpb.GreetingResponse, error) {

 

  // etwas mit 'req' machen

 

   return &greetpb.GreetingResponse{

    Result: result,

      }, nil

}

```

Beide verwenden denselben aus der Proto-Datei generierten Stub, der hier liegt.

Und der Stumpf wurde mithilfe des folgenden Protokoll-Compiler-Befehls generiert. 

```sh

protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative internal/pkg/proto/*.proto

```

Sicherheit

gRPC-Authentifizierung und -Autorisierung funktionieren auf zwei Ebenen:

• Die Anrufebene-Authentifizierung/Autorisierung wird normalerweise durch Token behandelt, die bei der Anruferstellung in Metadaten angewendet werden. Beispiel für Token-basierte Authentifizierung.

• Die Kanal-Ebene-Authentifizierung verwendet ein Clientzertifikat, das auf der Verbindungsebene angewendet wird. Es kann auch Anrufebene-Authentifizierungs-/Autorisierungsberechtigungen enthalten, die automatisch auf jeden Anruf im Kanal angewendet werden. Beispiel für zertifikatbasierte Authentifizierung.

Beide oder beide dieser Mechanismen können verwendet werden, um Dienste zu sichern.

Middleware

In REST nutzen wir Middleware für verschiedene Zwecke wie:

• Geschwindigkeitsbegrenzung

• Vor-/Nachprüfung von Anfragen/Antworten

• Sicherheitsbedrohungen beheben

Dasselbe können wir auch mit gRPC erreichen. Der Fachbegriff ist in gRPC anders – sie werden als Interceptor bezeichnet, aber sie erfüllen ähnliche Funktionen.

Im Middleware-Zweig des ‚greet_app‘ Code-Basis haben wir Protokoll- und Prometheus-Interceptor integriert.

Schauen Sie, wie die Interceptor so konfiguriert sind, dass sie Prometheus und die Protokollierungs-Pakete verwenden hier.

Wir können jedoch auch andere Pakete zu Interceptor integrieren, um Zwecke wie das Verhindern von Panik und Wiederherstellung (zur Behandlung von Ausnahmen), Ablaufverfolgung, sogar Authentifizierung usw. zu erfüllen.

Unterstütztes Middleware durch das gRPC-Framework.

Verpacken, Versionsverwaltung und Kodierungsstandards von Proto-Dateien

Verpacken

Lassen Sie uns der Verpackungsabteilung folgen.

Beginnen Sie zunächst mit ‘Taskfile.yaml’, die Aufgabe ‘gen-pkg’ besagt ‘protoc –proto_path=packaging packaging/*.proto –go_out=packaging’. Dies bedeutet, dass ‘protoc’ (der Compiler) alle Dateien in ‘packaging/*.proto’ in ihre entsprechenden ‘go’-Dateien konvertiert, wie durch die Flagge ‘–go_out=packaging’ im ‘packaging’-Verzeichnis selbst angegeben.

Zweitens wurden im ‘processor.proto’-Datei zwei Nachrichten definiert, nämlich ‘CPU’ und ‘GPU’. Während CPU eine einfache Nachricht mit 3 Feldern von eingebauten Datentypen ist, verfügt GPU andererseits über einen benutzerdefinierten Datentyp namens ‘Memory’. ‘Memory’ ist eine separate Nachricht und wird in einer ganz anderen Datei definiert.

Wie verwenden Sie also die ‘Memory’-Nachricht in der ‘processor.proto’-Datei? Durch Verwendung von import.

Selbst wenn Sie versuchen, eine Proto-Datei durch Ausführen der Aufgabe ‘gen-pkg’ nach dem Erwähnen von import zu generieren, wird dies einen Fehler auslösen. Da ‘protoc’ standardmäßig davon ausgeht, dass beide Dateien ‘memory.proto’ und ‘processor.proto’ zu unterschiedlichen Paketen gehören. Sie müssen also in beiden Dateien den gleichen Paketnamen angeben.

Das optionale ‘go_package’ gibt dem Compiler an, ein Paket namens ‘pb’ für Go-Dateien zu erstellen. Wäre für Proto-Dateien in einer anderen Sprache das Paket ‘laptop_pkg’ zu erstellen.

Versionsverwaltung

• Es gibt zwei Arten von Änderungen in gRPC: Breaking- und Non-breaking-Änderungen.

• Non-breaking-Änderungen umfassen das Hinzufügen eines neuen Dienstes, das Hinzufügen einer neuen Methode zu einem Dienst, das Hinzufügen eines Feldes zur Anfrage oder Antwort-Proto und das Hinzufügen eines Werts zum Enum

• Breaking-Änderungen wie das Umbenennen eines Feldes, das Ändern des Feld-Datentyps, des Feldnummerns, das Umbenennen oder Entfernen eines Pakets, Dienstes oder Methoden erfordern die Versionskontrolle von Diensten

• Optional Verpackung.

Code-Praktiken 

• Die Anfrage-Nachricht muss mit „Request“ enden, z.B. `CreateUserRequest`

• Die Antwort-Nachricht muss mit „Response“ enden, z.B. `CreateUserResponse`

• Falls die Antwortnachricht leer ist, können Sie entweder ein leeres Objekt `CreateUserResponse` verwenden oder das `google.protobuf.Empty`.

• Der Paketname muss sinnvoll sein und muss versioniert werden, zum Beispiel: Paket `com.ic.internal_api.service1.v1`

Werkzeuge

Die gRPC-Ökosystem unterstützt eine Vielzahl von Werkzeugen, um das Leben bei nicht-entwicklungsbezogenen Aufgaben wie Dokumentation, REST-Gateway für einen gRPC-Server, Integration von benutzerdefinierten Validatoren, Linting usw. zu erleichtern. Hier sind einige Werkzeuge, die uns dabei helfen können:

• protoc-gen-grpc-gateway — Plugin zum Erstellen eines gRPC-REST-API-Gateways. Es ermöglicht gRPC-Endpunkte als REST-API-Endpunkte und führt die Übersetzung von JSON zu Proto aus. Grundsätzlich definieren Sie einen gRPC-Dienst mit einigen benutzerdefinierten Anmerkungen und es macht diese gRPC-Methoden über REST zugänglich, indem JSON-Anfragen verwendet werden.

• protoc-gen-swagger — ein Begleit-Plugin für grpc-gateway. Es kann ein swagger.json basierend auf den benutzerdefinierten Anmerkungen generieren, die für den gRPC-Gateway erforderlich sind. Sie können diese Datei dann in Ihren REST-Client Ihrer Wahl (zum Beispiel Postman) importieren und REST-API-Aufrufe an die von Ihnen freigegebenen Methoden durchführen.

• protoc-gen-grpc-web — ein Plugin, das es unserer Frontend-Anwendung ermöglicht, mit dem Backend mithilfe von gRPC-Aufrufen zu kommunizieren. Ein separates Blog-Posting zu diesem Thema wird in der Zukunft erscheinen.

• protoc-gen-go-validators — ein Plugin, das die Definition von Validierungsregeln für Proto-Nachrichtenfelder ermöglicht. Es generiert eine Validate() error Methode für Proto-Nachrichten, die Sie in GoLang aufrufen können, um zu überprüfen, ob die Nachricht Ihren vordefinierten Erwartungen entspricht.

• https://github.com/yoheimuta/protolint — ein Plugin zur Hinzufügung von Lint-Regeln zu Proto-Dateien

Tests mit POSTMAN

Im Gegensatz zu Tests von REST-APIs mit Postman oder äquivalenten Tools wie Insomnia, ist es nicht gerade komfortabel, gRPC-Dienste zu testen.

Hinweis: gRPC-Dienste können auch über die CLI mit Hilfsmitteln wie evans-cli getestet werden. Dafür müssen jedoch Reflexionen aktiviert sein (wenn nicht aktiviert, ist der Pfad zum Proto-Datei erforderlich). Änderungen müssen vorgenommen werden, um Reflexionen zu aktivieren und wie man in den evans-cli REPL-Modus eintreten kann. Nach dem Eintritt in den REPL-Modus von evans-cli können gRPC-Dienste direkt von der CLI getestet werden und der Prozess wird auf der GitHub-Seite von evans-cli beschrieben.

Postman bietet eine Beta-Version zur Testung von gRPC-Diensten.

Hier sind die Schritte, wie Sie dies tun können:

1. Postman öffnen

2. Zu ‘APIs’ in der linken Seitenleiste gehen

3. Auf das ‘+’-Zeichen klicken, um eine neue API zu erstellen:

4. Im Popup-Fenster den ‘Namen’, die ‘Version’ und die ‘Schemadetails’ eingeben und auf ‘Erstellen’ klicken [es sei denn, Sie müssen aus Quellen wie github/bitbucket importieren]. Dieser Schritt ist relevant, wenn Sie den Proto-Vertrag kopieren und einfügen möchten.

5. Ihre API wird wie unten gezeigt erstellt. Klicken Sie auf die Version ‘1.0.0’, gehen Sie zur Definition und geben Sie Ihren Proto-Vertrag ein.

6. Denken Sie daran, dass das Importieren hier nicht funktioniert, daher ist es besser, alle abhängigen Protos an einem Ort zu halten.

7. Die obigen Schritte helfen dabei, Verträge für die zukünftige Verwendung zu sichern.

8. Klicken Sie dann auf ‚Neu‘ und wählen Sie ‚gRPC-Anfrage‘:

9. Geben Sie die URI ein und wählen Sie das Proto aus der Liste der gespeicherten APIs:

10. Geben Sie Ihre Anfrage-Nachricht ein und ‚Ausführen‘:

In den oben genannten Schritten haben wir den Prozess verstanden, wie man gRPC-APIs mit POSTMAN testet. Der Prozess zum Testen von gRPC-Endpunkten unterscheidet sich von dem für REST-Endpunkte mit POSTMAN. Eine Sache zu beachten ist, dass beim Erstellen und Speichern des Proto-Vertrags wie in #5 alle Proto-Nachrichten und Dienstdefinitionen am gleichen Ort stehen müssen. Da es in POSTMAN keine Möglichkeit gibt, Proto-Nachrichten über Versionen hinweg zu nutzen.

Zusammenfassung

In diesem Beitrag haben wir uns eine Vorstellung von RPC gemacht, Parallelen zu REST gezogen und ihre Unterschiede diskutiert, dann gingen wir auf eine Implementierung von RPC ein, nämlich gRPC, die von Google entwickelt wurde. 

gRPC als Framework kann von entscheidender Bedeutung sein, insbesondere für die interne Kommunikation in einer auf Microservices basierenden Architektur. Es kann auch für externe Kommunikation verwendet werden, aber es wird eine REST-Gateway benötigen. gRPC ist ein Muss für Streaming- und Echtzeit-Apps. 

So wie Golang sich als serverseitige Skriptsprache beweist, tut es gRPC als de-facto Kommunikationsframework.