[JAVA] gRPC auf Spring Boot mit grpc-spring-boot-Starter

Dieser Artikel ist der dritte Tag von BrainPad Adventskalender 2018.

Hallo [@ nissy0409240] ist (https://twitter.com/nissy0409240). Ich bin Ingenieur bei BrainPad. Es ist weniger als ein Monat im Jahr 2018 gewesen, Wie geht es allen.

Obwohl es eine private Angelegenheit ist Dieses Jahr durfte ich auf der PyCon 2018 die Bühne betreten Beobachten Sie den Hattrick von C. Ronaud bei der Weltmeisterschaft Ich hatte sowohl öffentlich als auch privat eine wertvolle Erfahrung.

Ende 2018 habe ich bei der Verwendung von gRPC, das nichts mit dem oben geschriebenen Inhalt in Spring Boot zu tun hat, etwas Außergewöhnliches und (weil die Anzahl der Sätze zu gering ist) gRPC hinzugefügt. Wir senden Ihnen diesen Eintrag.

Was ist gRPC?

Lassen Sie uns zunächst darüber sprechen, was gRPC ist. gRPC ist ein von Google erstelltes RPC-Framework. Dies allein ist ein "Was für ein Chaos" -Zustand, daher werde ich auch das RPC-Framework erläutern.

Der offizielle Name des RPC für das RPC-Framework lautet "Remote Procedure Call". Bei der Übersetzung wird es zum "Remote Procedure Call". Sie können die in einer Anwendung beschriebenen Methoden aufrufen, die auf einem anderen Server ausgeführt werden, als würden sie auf Ihrem Server ausgeführt.

Es ist schwierig, ein Bild nur mit den Buchstaben zu erhalten. Schauen wir uns also die Abbildung im Dokument der gPRC-Kopffamilie an.

Die obige Abbildung zeigt eine Situation, in der ein Ruby-Client und ein Java-Client einen in C ++ geschriebenen Dienst aufrufen.

Vorteile der Verwendung von gRPC

In gRPC wird durch Beschreiben der Implementierungsinhalte, die die Serviceseite in der Definitionsdatei mit dem Namen .proto file bereitstellen möchte, automatisch das Kooperationsmodul mit dem Namen stub generiert, das die Serviceimplementierung von der Clientseite aus aufruft. Infolgedessen spiegelt sich die in der API-Verknüpfung enthaltene Definitionsdatei für die Schnittstellenspezifikation immer in der Implementierung wider, sodass Sie die folgenden Vorteile nutzen können.

• Es ist möglich zu teilen, welche Art von Daten zwischen dem Anrufer und dem Angerufenen ausgetauscht wird.
• Da http2 + -Protokollpuffer verwendet werden, kann die Leistung durch API-Verknüpfung verbessert werden. ――Es ist möglich, mit dem Microservice fortzufahren, unabhängig von der vom Anrufer / Angerufenen verwendeten Sprache. --gRPC unterstützt verschiedene Sprachen, und die meisten der in der Webentwicklung verwendeten Hauptsprachen werden bereits unterstützt.

Verwendung von gRPC

Modul zur pom.xml hinzufügen

Ich möchte vorstellen, wie man gRPC benutzt. Es ist jedoch schwierig, nur die Buchstaben zu vermitteln, und es ist für jede Sprache unterschiedlich Dieses Mal werde ich Java 8 + Spring Boot verwenden und fortfahren, während ich meine Hände bewege.

Erstellen Sie zunächst ein Vorlagenprodukt mit Spring Initializer. Hier ist die Zusammensetzung der Vorlage, bevor sie erstellt wurde.

demo_protobuf

├── pom.xml
├── main
│   ├── java
│   │   └── com
│   │       └── example
│   │           └── demo_protobuf
│   │               └── DemoProtobufApplication.java
│   └── resources
│       └── application.properties
└── test
    └── java
        └── com
            └── example
                └── demo_protobuf
                    └── DemoProtobufApplicationTests.java

Dann habe ich pom.xml ein Modul hinzugefügt, was ein lächerlicher Teil war. Wir werden das Hinzufügen von Modulen später diskutieren, aber zuerst werden wir mit der Definitionsdatei fortfahren.

So erstellen Sie eine Definitionsdatei

Erstellen Sie eine Definitionsdatei, wenn die Ausführung abgeschlossen ist. Dieses Mal werde ich die Definition in die Datei src / main / proto / demo.proto schreiben. Die Zusammensetzung des Produkts ist zu diesem Zeitpunkt wie folgt.

demo_protobuf

.
├── mvnw
├── mvnw.cmd
├── pom.xml
└── src
    ├── main
    │   ├── java
    │   │   └── com
    │   │       └── example
    │   │           └── demo_protobuf
    │   │               └── DemoProtobufApplication.java
    │   │           
    │   ├── proto
    │   │   └── demo.proto
    │   └── resources
    │       └── application.properties
    └── test
        └── java
            └── com
                └── example
                    └── demo_protobuf
                        └── DemoProtobufApplicationTests.java

Schreiben Sie in der erstellten demo.proto wie folgt.

demo.proto

syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.example.fizzbuzz";
option java_outer_classname = "FizzBuzzProto";

package calc;

//Definiert eine Kombination aus Rückgabewerten und Argumenten für einen Dienst namens Math
service Math {
    rpc Math (MathRequest) returns (IntResponse);
}

//Definiert den Typ und die Anzahl der Rückgabewerte, wenn IntResponse ausgewählt ist
message IntResponse {
    int32 value = 1;
}

//Definiert den Typ und die Anzahl der Argumente beim Definieren von MathRequest
message MathRequest {
    int32 x = 1;
    int32 y = 2;
}

Ich bin sicher, einige von Ihnen haben es angeheftet, aber in der .proto-Datei "Welcher Dienst erhält welche Art von Anfrage und welche Art von Rückgabewert wird zurückgegeben" wird geschrieben. Es wird lediglich beschrieben, welche Art von Daten die .proto-Datei austauscht.

Führen Sie nach dem Schreiben mvn clean install aus. Nach der Ausführung wird der Quellcode wie folgt generiert. (Eigentlich wird mehr Code generiert, aber ich werde ihn hier weglassen)

.
├── mvnw
├── mvnw.cmd
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── com
│   │   │       └── example
│   │   │           └── demo_protobuf
│   │   │               └── DemoProtobufApplication.java
│   │   ├── proto
│   │   │   └── demo.proto
│   │   └── resources
│   │       └── application.properties
│   └── test
│       └── java
│           └── com
│               └── example
│                   └── demo_protobuf
│                       └── DemoProtobufApplicationTests.java
└── target
    └── generated-sources
        ├── annotations
        └── protobuf
            ├── grpc-java
            │   └── com
            │       └── example
            │           └── fizzbuzz
            │               └── MathGrpc.java
            └── java
                └── com
                    └── example
                        └── fizzbuzz
                            ├── FizzBuzzProto.java
                            ├── IntResponse.java
                            ├── IntResponseOrBuilder.java
                            ├── MathRequest.java
                            └── MathRequestOrBuilder.java

Code-Regeneration

Aber hier wurde mir klar, dass ich einen Fehler gemacht habe. Obwohl ich zuerst aufgehört habe, FizzBuzz zu versuchen, und zu Math gewechselt bin Ich habe mit FizzBuzz Code generiert. Möchten Sie das Repository verwerfen und neu erstellen? Das ist nicht wahr.

Schreiben Sie die erstellte demo.proto wie folgt um

demo.proto

syntax = "proto3";

option java_multiple_files = true;
option java_package = "com.example.math";
option java_outer_classname = "MathProto";

package calc;

//Definiert eine Kombination aus Rückgabewerten und Argumenten für einen Dienst namens Math
service Math {
    rpc Math (MathRequest) returns (IntResponse);
}

//Definiert den Typ und die Anzahl der Rückgabewerte, wenn IntResponse ausgewählt ist
message IntResponse {
    int32 value = 1;
}

//Definiert den Typ und die Anzahl der Argumente beim Definieren von MathRequest
message MathRequest {
    int32 x = 1;
    int32 y = 2;
}

Führen Sie mvn clean install aus.

.
├── mvnw
├── mvnw.cmd
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── com
│   │   │       └── example
│   │   │           └── demo_protobuf
│   │   │               └── DemoProtobufApplication.java
│   │   ├── proto
│   │   │   └── demo.proto
│   │   └── resources
│   │       └── application.properties
│   └── test
│       └── java
│           └── com
│               └── example
│                   └── demo_protobuf
│                       └── DemoProtobufApplicationTests.java
└── target
    └── generated-sources
        ├── annotations
        └── protobuf
            ├── grpc-java
            │   └── com
            │       └── example
            │           └── math
            │               └── MathGrpc.java
            └── java
                └── com
                    └── example
                        └── math
                            ├── MathProto.java
                            ├── IntResponse.java
                            ├── IntResponseOrBuilder.java
                            ├── MathRequest.java
                            └── MathRequestOrBuilder.java

Der Code unter Ziel wurde überarbeitet. Sie können auch sehen, dass diese Methode gut ist, wenn Sie demo.proto aktualisieren möchten.

Sie müssen lediglich den generierten Code erben und den Service und den Client erstellen.

Was ich beim Hinzufügen eines Moduls zu pom.xml stecken geblieben bin

Da ich eine Reihe von Flows angesprochen habe, möchte ich vorstellen, woran ich hier festgefahren bin. Einfach ausgedrückt: "Seien Sie vorsichtig, da sich die groupId des Moduls von dem Inhalt unterscheidet, der im Maven-Repository angezeigt wird."

Was ist das Maven Repository überhaupt? Wie viele von Ihnen vielleicht wissen, ist dies eine Site, die Ihnen sagen muss, was Sie beim Importieren von Middleware schreiben müssen. In anderen Sprachbeispielen ist Pythons PyPi ähnlich.

Und es gibt viele sogenannte Starter, All-in-One-Tools, die das Spring Boot-Framework unterstützen. Verwenden Sie beispielsweise Spring Boot Security Starter, wenn Sie ein Authentifizierungsmodul erstellen.

Bisher wurde bei Verwendung von gRPC mit Spring Boot wie folgt geschrieben.

pom.xml

<!-- https://mvnrepository.com/artifact/org.lognet/grpc-spring-boot-starter -->
<dependency>
    <groupId>org.lognet</groupId>
    <artifactId>grpc-spring-boot-starter</artifactId>
    <version>2.3.2</version>
</dependency>

Als jedoch die neueste Version dieses Moduls auf 3 Serien aktualisiert wurde, wurde die groupId von "org.lognet" in "org.github.lognet" geändert, sodass nicht nur die Version, sondern auch die groupId geändert werden musste. Ich tat.

Die gleichen Informationen wie oben finden Sie im Grpc-Spring-Boot-Starter-Repository.

Daher ist es von nun an notwendig, Folgendes zu beschreiben.

pomxml

<dependency>
    <groupId>io.github.lognet</groupId>
    <artifactId>grpc-spring-boot-starter</artifactId>
    <version>3.0.0</version>
</dependency>

Bitte beachten Sie, dass zum Zeitpunkt der "mvn-Installation" der folgende Fehler auftritt, wenn die groupId nicht korrigiert wird.

[ERROR] Failed to execute goal on project demo_protobuf: Could not resolve dependencies for project com.example:demo_protobuf:jar:1.16.1: Failure to find org.lognet:grpc-spring-boot-starter:jar:3.0.0 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException

Fazit

Obwohl die Struktur etwas seltsam ist, möchte ich diesen Eintrag durch die Hoffnung ersetzen, dass er denjenigen hilft, die süchtig danach sind, Informationen mit wenigen japanischen Einträgen zusammen mit einer Fehlermeldung zu veröffentlichen. Es tut mir leid, dass der Text unorganisiert war, aber ich danke Ihnen, dass Sie bis zum Ende bei uns geblieben sind.

Referenz

https://qiita.com/nozaq/items/9cd9bf7ee6118779bda9 http://redj.hatenablog.com/entry/2017/10/13/084423 https://github.com/LogNet/grpc-spring-boot-starter https://kengotoda.gitbooks.io/what-is-maven/primer/maven-repository.html