Definieren eines gRPC-Dienstes mit Protokollpuffern
Home » DE » Blog » Definieren eines gRPC-Dienstes mit Protokollpuffern
* Dieser Beitrag ist der dritte in der Reihe über gRPC
Der erste Schritt bei der Erstellung eines gRPC-Dienstes besteht darin, die Definition der Dienstschnittstelle mit den Methoden zu erstellen, die von diesem Dienst zusammen mit den Eingabeparametern und Rückgabetypen bereitgestellt werden.
Definieren eines gRPC-Dienstes mit Protokollpuffern
gRPC verwendet Protokollpuffer (Protokollpuffer oder Protobufs) als IDLs, um die Dienstschnittstelle zu definieren. Protokollpuffer sind ein erweiterbarer, sprach- und plattformunabhängiger Mechanismus zur Serialisierung strukturierter Daten. Die Definition der Serviceschnittstelle wird in einer Proto-Datei angegeben, die nichts anderes ist als eine einfache Textdatei mit der Erweiterung .proto. Die gRPC-Dienste werden in einem gewöhnlichen Protokollpufferformat definiert, wobei die RPC-Methodenparameter und Rückgabetypen als Protokollpuffermeldungen angegeben werden. Da die Dienstdefinition eine Erweiterung der Protokollpufferspezifikation ist, wird ein spezielles gRPC-Plug-in verwendet, um Code aus der .proto-Datei zu generieren.
❝ Eine Proto-Datei, die nichts anderes als eine einfache Textdatei mit der Erweiterung .proto ist, wird verwendet, um aus ihrer .proto-Datei Code zu erzeugen. ❞
Im Beispiel wird die DrinkInfo-Dienstschnittstelle mit der Bezeichnung DrinkService mit Hilfe von protobuf definiert, wie im folgenden Ausschnitt gezeigt. Der DrinkService besteht aus einer Definition der Serviceschnittstelle, in der wir die Remote-Methoden (addCreate und Get), ihre Eingabe- und Ausgabeparameter und die Definition des Typs (oder der Nachrichtenformate) dieser Parameter angeben.
syntax = "proto3";
message DrinkMessage {
string id = 1;
string name = 2;
string desc = 3;
}
message DrinkMessages {
repeated DrinkMessage drinks = 1;
}
message Empty {}
service DrinkService {
rpc addCreate (DrinkMessage) returns (DrinkMessage);
rpc Get (Empty) returns (DrinkMessages);
}Wie Sie sehen, ist ein Dienst eine Sammlung von Methoden (z. B. addProduct und getProduct), die per Fernzugriff aufgerufen werden können. Jede Methode hat Eingabeparameter und Rückgabetypen, die wir als Teil des Dienstes definieren oder die in die Protobuf-Definition importiert werden können.
Bei den Eingabe- und Rückgabeparametern kann es sich um einen benutzerdefinierten Typ (z. B. die Typen DrinkMessage und DrinkMessages) oder um einen Standarddatentyp wie String handeln. Diese Typen sind als Nachrichten strukturiert, wobei jede Nachricht eine kleine logische Aufzeichnung von Informationen ist, die eine Reihe von Name-Wert-Paaren enthält. Diese Felder sind Name-Wert-Paare mit eindeutigen Feldnummern (z. B. string id = 1), die zur Identifizierung ihrer Felder im Binärformat der Nachricht verwendet werden.
Diese Dienstdefinition wird verwendet, um die Server- und Client-Seite einer gRPC-Anwendung zu erstellen. Im nächsten Beitrag werde ich mehr Details zur Implementierung des gRPC-Servers geben.
Ich möchte diese Gelegenheit nutzen, um Ihnen einige Bücher zu empfehlen, die Sie interessieren könnten:
